Most do have them. The Nissan Leaf didn't have proper cooling and their batteries tended to die in hot climates and rapid charging was hard on them. Most other EVs have liquid cooled batteries. Tesla also has liquid cooling for the inverter and motor and I suspect many other EVs have a similar setup since even my old Prius had liquid cooling for the inverter and electric motor.
The all-wheel drive ones have less space in front, but considerably more than an ICE vehicle. For a truck this wouldn't be an issue since only one motor is needed though I suppose it could use two smaller ones and get rid of the differential. You can also get rid of the transmission, exhaust system, smog controls and a lot more. One thing Tesla is good at is a compact drive train. People often ask me where's the motor, especially when I pull up the cover in my trunk and expose the large storage space underneath it. Having a 416HP engine the size of a large watermelon helps.
My Tesla has maintenance done every year or 12.5K miles, and that isn't required to maintain the warranty. The big services happen every four years (50K miles) where they replace the brake fluid and coolant. The motor is lubricated for 12 years. The yearly maintenance includes replacing the cabin air filter, wiper blades, rotating the tires (which should be done more often), a wheel alignment as well as cleaning the car inside and out. They also check the brakes and other things and apply any fixes that are needed.
I don't have to get my oil changed, belts adjusted, spark plugs changed, air filter changed or get emission checks. There's no ignition system or fuel pump to fail, no belts or belt-driven accessories to fail (like AC compressor, power steering pump, alternator and water pump). The water pump is electric and a sealed unit as is the AC compressor. Sealed units tend to be more reliable since it's much less likely they'll develop a leak where the shaft pokes through.
The only major issue I've had with my car is in the last year I've had three rims destroyed due to our roads going to hell. I've since gotten higher profile wheels so hopefully this will no longer be a problem. My car is an early one too. The newer cars are much more reliable and better since they have learned a lot in the last 5 years. The things that caused me issues have been redesigned (i.e. the door handles).
Also if things do fail they're much easier to access since there isn't a big engine in the way. If they do need to access the drive train on my car it's *much* easier than an ICE vehicle. Similarly, the battery can be swapped very quickly.
Cooling big motors isn't a problem. The 416HP electric motor in my Tesla is water cooled. One thing is that they generate far less heat than the diesel engine they replace. There are electric motors in the tens of thousands of HP. Electric motors are easier to cool than an internal combustion engine. They don't need to warm up to their operating temperature. They can also have a smaller radiator.
My water is county and I have no complaints about it compared to when my water came from Citizens Utilities. After the county took over (and spent a fortune), the water became drinkable and no longer came out brown from the faucet. Additionally, the price of water dropped to a fraction of what it was when CU controlled it. The county water also sends me quarterly reports and the board members are elected so they answer to the voters. I wish our power were municipal. A nearby city has municipal power and their rates are a lot cheaper than PG&E and without the mismanaged criminal lack of maintenance either (i.e. the San Bruno explosion. It took years before PG&E would fix a gas leak at my parents house (even when you could see it bubbling though the ground when the sprinklers ran).
Actually it is fairly clear what happens behind the scenes if you know what you are doing. As I said, I had to debug at the assembly level so I got to see first hand exactly what the compiler did. It didn't take me long to understand how C++ code compiled. I also did not see a performance hit. The this pointer basically behaves like passing a pointer to a data structure containing all the data the function needs to work with as is common in C.
There is no inherent reason for C++ code to be any slower than C code.
If you are inexperienced with C++ I could see your complaint about not knowing what's going on behind the scenes.
Also, portability has greatly improved with C++. I have regularly updated C++ libraries without the need to recompile applications.
I found the same thing when I was handed a large project in C++. In this case it was a very complex kernel-level OS/2 device driver. It took me a while to adjust to C++ but once I did I certainly saw the advantages.
With C we're always reinventing the wheel and doing things the hard way. I say this as someone who works on bootloaders and has worked on a lot of device drivers and works close to the hardware. C++ requires more support than C to get basic functionality working, but once it's there a lot of code becomes simpler.
In the 1990s I worked on a complex device driver for OS/2 for ATM networking (asynchronous transfer mode). The driver was around 100K lines of C++ code however only a subset of C++ was used. Surprisingly the use of C++ worked out quite well. We had an equivalent driver for Windows NT that was written in C that was over 300K lines of code. The C++ codebase was a lot more reliable and easier to work on, despite all the work that was done to make C++ work in kernel mode under OS/2. The C++ driver actually had more functionality than the C driver and it was faster as well with a smaller binary. Also, as I said, it was a subset of C++, especially in the performance critical code. The driver in question included the entire ATM signalling stack and implemented full LAN emulation support with both Ethernet and Tokenring plus it could emulate multiple networks (ELANs, equivalent to VLANs) simultaneously. When I implemented multiple ELAN support I was afraid it was going to be a nightmare, but due to the way it was architected in C++ I ended up only having to change a few lines of code, changing a pointer to the LANE class to an array of pointers.
For the signalling stack and ILMI C++ worked out especially well due to the event and message based nature of it and the various state machines. For LAN emulation it made it easy to support both Ethernet and Tokenring by having a few virtual functions in the main LANE class.
There was no exception handling support and none of the more complex C++ features were not used. It used templates but that was also somewhat limited.
Having destructors was also quite nice, making it easy to clean up resources.
Despite being C++, debugging wasn't too bad though at the time the OS/2 kernel debugger basically ran at the assembly level.
If the infrastructure is in place I can certainly see using C++ in the kernel and device drivers.
Try doing that in a lot of places when they get home from work and the library is closed. In many rural places the library is a significant distance away.
It's one thing to make custom gear where humans generally need to be involved. Manufacturing today also needs more skills than it did in the past. If you're mass-producing something then automation becomes key. I have a friend who's family business is manufacturing. Their biggest problem is finding the skilled labor they need. Manufacturing used to use a lot of unskilled labor but that's going away.
I also toured the Tesla factory. Most of the work I saw was being done by robots, hundreds of them.
The labor that's needed today is for people who can program and maintain the robots. Another friend of mine is a machinist. His big skill is knowing how to clean up the programs that are fed to the CNC machines to account for differences from the CAD programs and the CNC machines.
My sister is in her 40s and the medicine that keeps her alive costs $5000/month. She too was very athletic. Between that disease (which turns out to be genetic and cropped up in her 30s) and a very bad bicycle accident she's in pretty bad shape now. There's no way she could afford insurance without the ACA. With the ACA her medication is covered as are all of her doctors visits. She too did bike racing. Now she can barely get on one.
I'm still using my 4M Plus PS 600. I just ordered a new kit to replace the rollers today. It still works great with Linux. I have the large capacity tray and the duplex unit as well.
It also depends on what group you were in terms of happiness. Blacks, for example, had it pretty tough in many parts of the country due to segregation and discrimination. You were basically happy if you were white and male. Women were expected to stay at home while the man worked. Generally women didn't go to college and there were few methods for women and minorities to get ahead.
One thing that drastically improved people's lives were labor unions for blue collar jobs. That's where things like the 40 hour work week, time and a half and many other benefits came from. Labor unions peaked in 1954 where almost 35% of all workers belonged to a union. The labor unions significantly improved the standard of living for all workers, even those who didn't belong to unions. Combine that with the 90% tax bracket and the fact that the pay difference between the CEO and the line worker was significantly lower than it is today. Back then you also got a pension plan from the company you worked for. Later, however, laws were relaxed and companies skimped on their pension contributions then switched everything over to 401Ks and IRAs.
Decades ago the tax system was also quite different. There was a 90% tax rate, for example. Also, https://en.wikipedia.org/wiki/...">historically the minimum wage was higher when one takes into account the purchasing power.
After World War II the GI bill sent millions of people to college which also significantly improved the lives of many people.
My grandparents, who sadly passed away around 2000 had gone through the great depression and world war 2. My grandfather was born in 1906. They said the "good old days" weren't that great.
I had a couple of encrypted partitions on my Linux setup that I rarely accessed that became inaccessible after a Linux update. In my case I did remember the password but Linux would not accept it. I eventually reformatted it and restored the data from a backup.
The chip is the one referred to in the article, and yes, it does have hundreds of gigabits of bandwidth to it as it says, especially when there are many 25GBps serdes.
The Itanium was quite different than the Pentium. Microsoft already supports two different architectures, X86 and X86-64. ARMv8 AArch64 is not that different than X86-64. While ARM can run either big or little-endian it typically runs little-endian, just like Intel. It also supports unaligned loads and stores like Intel. While hand-crafted assembly for certain things is different there really isn't used all that much any more. In most cases it's just a matter of recompiling. The fact that ARM standardized on UEFI makes things even easier.
The Itanium also suffered from the fact that it was very expensive and the instruction set was extremely complicated and the performance was often not very good except for specially profiled code that could take advantage of its capabilities.
ARM never really understood the server until recently. The lack of decent 64-bit support was a major hindrance and all of the emphasis was on the mobile market. There are some decent server oriented chips now. The problem was that Qualcomm and the other vendors didn't understand the server market and what is involved. AArch64 is not the old ARM. Once you ditch the ARMv7 and older baggage you have a very nice modern RISC processor without the major hindrances holding back performance. ARMv7 doesn't lend itself very well to superscalar or out-of-order execution all that well and the lack of general-purpose registers is similar to that of X86. ARMv8.1 helped address the scalability issues involved with a lot of cores by adding atomic instructions.
The older ARM chips contained a lot of cruft like thumb, predicated ALU instructions and having the PC as one of the general purpose registers. This really limited their performance and scalability.
The ARM chips typically lacked things needed for a server like being able to support a large amount of memory with high memory and I/O bandwidth.
The Cavium ARM chip I'm looking at nicely addresses this with a lot more cores than anything Intel has. The Cavium cores also ditch the ARMv7 32-bit ARM instructions, simplifying things a fair amount.
Intel has a lot of cruft as well that hinders them for backwards compatibility. It adds a lot of complexity to the chips and hinders performance. The latest Intel processor still boots up in real mode and has a very complex instruction decoder. For example, with Intel an instruction can span a page boundary and begin on any byte boundary and be variable length. There's support for real mode, 32-bit mode and 64-bit mode. There's still support in there for 80286 segmentation and the old 8087 math coprocessor instructions in addition to MMX and all the SSE variants. There's a fair amount of microcode as well in order to handle everything.
The new server ARM chips do away with all of that cruft. On the Cavium chip, for example, all of the legacy 32-bit instruction decoding is gone as is Thumb. The instruction encoding for AArch64 is completely different than previous generations, in a sense making it a new modern RISC instruction set by taking advantage of everything that has been learned in the last few decades. AMD did Intel a big favor by cleaning things up quite a bit for x86_64, but it still leaves much of the legacy stuff in place which consumes chip real-estate and power.
The Cavium chips handle multiple PCI-e 3.0 ports. Here's a brief on the I/O capabilities (though it doesn't go into much detail): http://cavium.com/ThunderX2_AR...
Though why just 10-gig-e? The ARM chips I'm working with support multiple integrated 40-gig-e ports and multiple PCIe gen 3 buses.
I have the data sheet for the chip being discussed in the article in front of me. While I can't go into details, it is no slouch and has a massive amount of memory and I/O bandwidth. 10G? That's nothing. I regularly deal with 80G (dual 40G XLAUI) with this chip. The ARM chips are a newer generation than this so the cores are faster.
Some of the ARM chips I work with have built-in RAID engines for offloading all of the RAID calculations as well as engines for a number of other things. Here is a link that shows the I/O oriented chips.
The processors being discussed are not the lean ARM processors you would find in a phone or tablet. These chips are designed for servers. The Cavium chips, for example, are designed to handle an insane amount of memory bandwidth with a lot of cores, far more cores than Intel offers.
The Cavium cores are lean in the sense that they do not support the older 32-bit ARM instructions or the baggage they bring, i.e. they only support AArch64, not ARMv7. The switch from 32-bit to 64-bit ARM is more radical than the change between X86 and X86-64. A lot of what made ARM 'ARM' is gone. AArch64 is basically a new modern RISC instruction set incorporating everything that has been learned in the last few decades while throwing out much of the cruft that holds back performance. While some things may have been a good idea at the time they later proved to be a hinderance. While many of the instructions may look similar (and even have the same mnemonic), the encoding is completely different. The register set is also completely different. Instead of 16 registers (where the PC was one of the registers) there are now 31 general purpose registers (R31 is always 0 (like MIPS R0) except when it is the stack pointer). See Wikipedia.
The problems with the 32-bit ARM instruction set that prevented out of order execution and issuing multiple instructions in parallel are pretty much gone. Conditional ALU instructions are gone (except branch instructions) and the PC is no longer a general purpose register. There are also now 31 general purpose registers with register r31 having special meaning. It is generally always zero, much like r0 on MIPS, though there are also special instructions so it can be used as a stack pointer. It also doubles the number of 128-bit NEON registers from 16 to 32.
There are other Cavium CPU chips that are targeted at high-speed network devices with a lot of built-in engines for things like networking (10 and 40Gbps networking is built-in), encryption, RAID, compression and a number of other interesting engines useful for big data.
The X86 platform has a lot of warts that make some things very expensive for backwards compatibility. I'm amazed that they get as much performance out of it as they do given how horrible the instruction set is.
These chips can handle Windows just fine.
Full disclosure: I work for Cavium though I'm primarily involved with their MIPS processors.
Slashdot Mirror
Most do have them. The Nissan Leaf didn't have proper cooling and their batteries tended to die in hot climates and rapid charging was hard on them. Most other EVs have liquid cooled batteries. Tesla also has liquid cooling for the inverter and motor and I suspect many other EVs have a similar setup since even my old Prius had liquid cooling for the inverter and electric motor.
The all-wheel drive ones have less space in front, but considerably more than an ICE vehicle. For a truck this wouldn't be an issue since only one motor is needed though I suppose it could use two smaller ones and get rid of the differential. You can also get rid of the transmission, exhaust system, smog controls and a lot more. One thing Tesla is good at is a compact drive train. People often ask me where's the motor, especially when I pull up the cover in my trunk and expose the large storage space underneath it. Having a 416HP engine the size of a large watermelon helps.
My Tesla has maintenance done every year or 12.5K miles, and that isn't required to maintain the warranty. The big services happen every four years (50K miles) where they replace the brake fluid and coolant. The motor is lubricated for 12 years. The yearly maintenance includes replacing the cabin air filter, wiper blades, rotating the tires (which should be done more often), a wheel alignment as well as cleaning the car inside and out. They also check the brakes and other things and apply any fixes that are needed.
I don't have to get my oil changed, belts adjusted, spark plugs changed, air filter changed or get emission checks. There's no ignition system or fuel pump to fail, no belts or belt-driven accessories to fail (like AC compressor, power steering pump, alternator and water pump). The water pump is electric and a sealed unit as is the AC compressor. Sealed units tend to be more reliable since it's much less likely they'll develop a leak where the shaft pokes through.
The only major issue I've had with my car is in the last year I've had three rims destroyed due to our roads going to hell. I've since gotten higher profile wheels so hopefully this will no longer be a problem. My car is an early one too. The newer cars are much more reliable and better since they have learned a lot in the last 5 years. The things that caused me issues have been redesigned (i.e. the door handles).
Also if things do fail they're much easier to access since there isn't a big engine in the way. If they do need to access the drive train on my car it's *much* easier than an ICE vehicle. Similarly, the battery can be swapped very quickly.
Cooling big motors isn't a problem. The 416HP electric motor in my Tesla is water cooled. One thing is that they generate far less heat than the diesel engine they replace. There are electric motors in the tens of thousands of HP. Electric motors are easier to cool than an internal combustion engine. They don't need to warm up to their operating temperature. They can also have a smaller radiator.
My water is county and I have no complaints about it compared to when my water came from Citizens Utilities. After the county took over (and spent a fortune), the water became drinkable and no longer came out brown from the faucet. Additionally, the price of water dropped to a fraction of what it was when CU controlled it. The county water also sends me quarterly reports and the board members are elected so they answer to the voters. I wish our power were municipal. A nearby city has municipal power and their rates are a lot cheaper than PG&E and without the mismanaged criminal lack of maintenance either (i.e. the San Bruno explosion. It took years before PG&E would fix a gas leak at my parents house (even when you could see it bubbling though the ground when the sprinklers ran).
Dump it in the great salt lake. I don't think anyone will notice.
Actually it is fairly clear what happens behind the scenes if you know what you are doing. As I said, I had to debug at the assembly level so I got to see first hand exactly what the compiler did. It didn't take me long to understand how C++ code compiled. I also did not see a performance hit. The this pointer basically behaves like passing a pointer to a data structure containing all the data the function needs to work with as is common in C.
There is no inherent reason for C++ code to be any slower than C code.
If you are inexperienced with C++ I could see your complaint about not knowing what's going on behind the scenes.
Also, portability has greatly improved with C++. I have regularly updated C++ libraries without the need to recompile applications.
I found the same thing when I was handed a large project in C++. In this case it was a very complex kernel-level OS/2 device driver. It took me a while to adjust to C++ but once I did I certainly saw the advantages.
With C we're always reinventing the wheel and doing things the hard way. I say this as someone who works on bootloaders and has worked on a lot of device drivers and works close to the hardware. C++ requires more support than C to get basic functionality working, but once it's there a lot of code becomes simpler.
In the 1990s I worked on a complex device driver for OS/2 for ATM networking (asynchronous transfer mode). The driver was around 100K lines of C++ code however only a subset of C++ was used. Surprisingly the use of C++ worked out quite well. We had an equivalent driver for Windows NT that was written in C that was over 300K lines of code. The C++ codebase was a lot more reliable and easier to work on, despite all the work that was done to make C++ work in kernel mode under OS/2. The C++ driver actually had more functionality than the C driver and it was faster as well with a smaller binary. Also, as I said, it was a subset of C++, especially in the performance critical code. The driver in question included the entire ATM signalling stack and implemented full LAN emulation support with both Ethernet and Tokenring plus it could emulate multiple networks (ELANs, equivalent to VLANs) simultaneously. When I implemented multiple ELAN support I was afraid it was going to be a nightmare, but due to the way it was architected in C++ I ended up only having to change a few lines of code, changing a pointer to the LANE class to an array of pointers.
For the signalling stack and ILMI C++ worked out especially well due to the event and message based nature of it and the various state machines. For LAN emulation it made it easy to support both Ethernet and Tokenring by having a few virtual functions in the main LANE class.
There was no exception handling support and none of the more complex C++ features were not used. It used templates but that was also somewhat limited.
Having destructors was also quite nice, making it easy to clean up resources.
Despite being C++, debugging wasn't too bad though at the time the OS/2 kernel debugger basically ran at the assembly level.
If the infrastructure is in place I can certainly see using C++ in the kernel and device drivers.
Try doing that in a lot of places when they get home from work and the library is closed. In many rural places the library is a significant distance away.
It's one thing to make custom gear where humans generally need to be involved. Manufacturing today also needs more skills than it did in the past. If you're mass-producing something then automation becomes key. I have a friend who's family business is manufacturing. Their biggest problem is finding the skilled labor they need. Manufacturing used to use a lot of unskilled labor but that's going away.
I also toured the Tesla factory. Most of the work I saw was being done by robots, hundreds of them.
The labor that's needed today is for people who can program and maintain the robots. Another friend of mine is a machinist. His big skill is knowing how to clean up the programs that are fed to the CNC machines to account for differences from the CAD programs and the CNC machines.
My sister is in her 40s and the medicine that keeps her alive costs $5000/month. She too was very athletic. Between that disease (which turns out to be genetic and cropped up in her 30s) and a very bad bicycle accident she's in pretty bad shape now. There's no way she could afford insurance without the ACA. With the ACA her medication is covered as are all of her doctors visits. She too did bike racing. Now she can barely get on one.
Encryption hides the content. They can still see every IP address you connect to unless you use a VPN.
That's an insult to orangutans. They are gentle peaceful and intelligent creatures.
I'm still using my 4M Plus PS 600. I just ordered a new kit to replace the rollers today. It still works great with Linux. I have the large capacity tray and the duplex unit as well.
It also depends on what group you were in terms of happiness. Blacks, for example, had it pretty tough in many parts of the country due to segregation and discrimination. You were basically happy if you were white and male. Women were expected to stay at home while the man worked. Generally women didn't go to college and there were few methods for women and minorities to get ahead.
One thing that drastically improved people's lives were labor unions for blue collar jobs. That's where things like the 40 hour work week, time and a half and many other benefits came from. Labor unions peaked in 1954 where almost 35% of all workers belonged to a union. The labor unions significantly improved the standard of living for all workers, even those who didn't belong to unions. Combine that with the 90% tax bracket and the fact that the pay difference between the CEO and the line worker was significantly lower than it is today. Back then you also got a pension plan from the company you worked for. Later, however, laws were relaxed and companies skimped on their pension contributions then switched everything over to 401Ks and IRAs.
Decades ago the tax system was also quite different. There was a 90% tax rate, for example. Also, https://en.wikipedia.org/wiki/...">historically the minimum wage was higher when one takes into account the purchasing power.
After World War II the GI bill sent millions of people to college which also significantly improved the lives of many people.
My grandparents, who sadly passed away around 2000 had gone through the great depression and world war 2. My grandfather was born in 1906. They said the "good old days" weren't that great.
I had a couple of encrypted partitions on my Linux setup that I rarely accessed that became inaccessible after a Linux update. In my case I did remember the password but Linux would not accept it. I eventually reformatted it and restored the data from a backup.
Any time you are arrested you should always choose to remain silent and request an attorney even if you are innocent.
The chip is the one referred to in the article, and yes, it does have hundreds of gigabits of bandwidth to it as it says, especially when there are many 25GBps serdes.
The Itanium was quite different than the Pentium. Microsoft already supports two different architectures, X86 and X86-64. ARMv8 AArch64 is not that different than X86-64. While ARM can run either big or little-endian it typically runs little-endian, just like Intel. It also supports unaligned loads and stores like Intel. While hand-crafted assembly for certain things is different there really isn't used all that much any more. In most cases it's just a matter of recompiling. The fact that ARM standardized on UEFI makes things even easier.
The Itanium also suffered from the fact that it was very expensive and the instruction set was extremely complicated and the performance was often not very good except for specially profiled code that could take advantage of its capabilities.
ARM never really understood the server until recently. The lack of decent 64-bit support was a major hindrance and all of the emphasis was on the mobile market. There are some decent server oriented chips now. The problem was that Qualcomm and the other vendors didn't understand the server market and what is involved. AArch64 is not the old ARM. Once you ditch the ARMv7 and older baggage you have a very nice modern RISC processor without the major hindrances holding back performance. ARMv7 doesn't lend itself very well to superscalar or out-of-order execution all that well and the lack of general-purpose registers is similar to that of X86. ARMv8.1 helped address the scalability issues involved with a lot of cores by adding atomic instructions.
The older ARM chips contained a lot of cruft like thumb, predicated ALU instructions and having the PC as one of the general purpose registers. This really limited their performance and scalability.
The ARM chips typically lacked things needed for a server like being able to support a large amount of memory with high memory and I/O bandwidth.
The Cavium ARM chip I'm looking at nicely addresses this with a lot more cores than anything Intel has. The Cavium cores also ditch the ARMv7 32-bit ARM instructions, simplifying things a fair amount.
Intel has a lot of cruft as well that hinders them for backwards compatibility. It adds a lot of complexity to the chips and hinders performance. The latest Intel processor still boots up in real mode and has a very complex instruction decoder. For example, with Intel an instruction can span a page boundary and begin on any byte boundary and be variable length. There's support for real mode, 32-bit mode and 64-bit mode. There's still support in there for 80286 segmentation and the old 8087 math coprocessor instructions in addition to MMX and all the SSE variants. There's a fair amount of microcode as well in order to handle everything.
The new server ARM chips do away with all of that cruft. On the Cavium chip, for example, all of the legacy 32-bit instruction decoding is gone as is Thumb. The instruction encoding for AArch64 is completely different than previous generations, in a sense making it a new modern RISC instruction set by taking advantage of everything that has been learned in the last few decades. AMD did Intel a big favor by cleaning things up quite a bit for x86_64, but it still leaves much of the legacy stuff in place which consumes chip real-estate and power.
The Cavium chips handle multiple PCI-e 3.0 ports. Here's a brief on the I/O capabilities (though it doesn't go into much detail):
http://cavium.com/ThunderX2_AR...
Yes.
Though why just 10-gig-e? The ARM chips I'm working with support multiple integrated 40-gig-e ports and multiple PCIe gen 3 buses.
I have the data sheet for the chip being discussed in the article in front of me. While I can't go into details, it is no slouch and has a massive amount of memory and I/O bandwidth. 10G? That's nothing. I regularly deal with 80G (dual 40G XLAUI) with this chip. The ARM chips are a newer generation than this so the cores are faster.
Some of the ARM chips I work with have built-in RAID engines for offloading all of the RAID calculations as well as engines for a number of other things. Here is a link that shows the I/O oriented chips.
You might be surprised with some of the new server oriented ARM chips.
The processors being discussed are not the lean ARM processors you would find in a phone or tablet. These chips are designed for servers. The Cavium chips, for example, are designed to handle an insane amount of memory bandwidth with a lot of cores, far more cores than Intel offers.
The Cavium cores are lean in the sense that they do not support the older 32-bit ARM instructions or the baggage they bring, i.e. they only support AArch64, not ARMv7. The switch from 32-bit to 64-bit ARM is more radical than the change between X86 and X86-64. A lot of what made ARM 'ARM' is gone. AArch64 is basically a new modern RISC instruction set incorporating everything that has been learned in the last few decades while throwing out much of the cruft that holds back performance. While some things may have been a good idea at the time they later proved to be a hinderance. While many of the instructions may look similar (and even have the same mnemonic), the encoding is completely different. The register set is also completely different. Instead of 16 registers (where the PC was one of the registers) there are now 31 general purpose registers (R31 is always 0 (like MIPS R0) except when it is the stack pointer). See Wikipedia.
The problems with the 32-bit ARM instruction set that prevented out of order execution and issuing multiple instructions in parallel are pretty much gone. Conditional ALU instructions are gone (except branch instructions) and the PC is no longer a general purpose register. There are also now 31 general purpose registers with register r31 having special meaning. It is generally always zero, much like r0 on MIPS, though there are also special instructions so it can be used as a stack pointer. It also doubles the number of 128-bit NEON registers from 16 to 32.
There are other Cavium CPU chips that are targeted at high-speed network devices with a lot of built-in engines for things like networking (10 and 40Gbps networking is built-in), encryption, RAID, compression and a number of other interesting engines useful for big data.
The X86 platform has a lot of warts that make some things very expensive for backwards compatibility. I'm amazed that they get as much performance out of it as they do given how horrible the instruction set is.
These chips can handle Windows just fine.
Full disclosure: I work for Cavium though I'm primarily involved with their MIPS processors.
Mod parent up!