Anyway, I think they should keep focussing on making the computer chips and focus on the temperature problem.
Except there are two things wrong with that theory:
1) "IoT" is mainly a new name for something that has already existed - a market that has already been dominated by ARM: the embedded/microcontroller market. ARM has much better expertise in this market, better relationships, and better ecosystem, as well as a full range of products.
2) If Intel's chips weren't competitive in the mobile market (especially when you compare all three metrics of performance, power, and price), then why would they be in the embedded IoT market, which plays even more to ARM's strengths?
The IoT is much more than just the embedded hardware. It's the potential that lies within connecting embedded hardware. Extracting and refining data from embedded machines/sensors/nodes. The whole ecosystem of apps/services that can potentially be created on top of these new data streams.
While the embedded/microcontroller tech hasn't changed drastically, the cloud/edge processing & analytics parts of the tech stack are new. The "services" business models are also new.
And these are the kind of devices Intel has decided to overlook 15, 20 years ago and now ARM is eating its cake.
What makes it an even bigger ARM turf than otherwise.
I haven't seen any of that yet, just hype. Of course every company wants to collect more data on consumers and is hoping IoT will enable them. None has provided a compelling reason for a "consumer" to buy an IoT device. Look at how Nest was all hype and then had a thermostat fail at its primary function when it lost the net connection. That's a huge step backward, and it's not going to get any better when the data collection remains the priority.
(Disclaimer: I work on the MessageSight messaging engine used in Watson IoT)
It's really more complex then that.
x86_64 has a lot of backwards compatibility. Even low power chips made by Intel typically consume 2-5x the wattage of ARM counter parts. Intel's very low power line (matches ARM) doesn't actually have the 64bit extension and is functionally a i586 chip from circa 1999-2003. Modern x86_64 chips have a whole section of die space dedicated to emulation, re-ordering, re-naming, and caching for us to pretend x86 is fast.
Then you have monopoly. Intel is the only company making x86_64 chips (Yes VIA/AMD exist, but collectively they have <10% of the market). They are the only show in town, it's their prices. While ARM simply licenses it's IP to other companies, who then compete with one another and drive prices even lower.
So, whether ARM64 has an power efficiency advantage isn't clear at all when one tries to actually compare them fairly. I frequently see people linearly scaling power/performance curves, or comparing cores that contain ECC, significantly more IO, etc against cores that don't and claiming that the core with 10x the IO bandwidth is somehow less efficient computationally because it consumes 5 watts more to power a PCIe bus.
So, lets get this out of the way, performance is not linear to power. Simply having a clock rate 50% faster has a large impact on power given the rough P=CV^2f equation because often the voltage goes up to support the higher frequencies. Worse designing for a target top end frequency of 4Ghz may entail extra pipeline stages/etc than one targeting 2Ghz in the same process. The result is significantly higher power draw at the same frequency due to the fact that higher frequencies are supported. Then there is leakage current/etc, which will be proportional to the number of transistors, so a design with 15MB of cache is going to waste more on leakage than one with 1MB. The extra 14MB of cache may only contribute another percent or two to the bottom line in many workloads, but frequently the difference between a processors at X performance and one at 1.5X is not due to a single factor but dozens of design tradeoffs that individually only net small percentage gains.
Bottom line, its better to compare implementations, and when ARM vs x86 chips are compared on similar grounds, they are a lot closer than you hear in glib remarks on forums like this. Intel's handicap in mobile (lack of native x86 android apps) and ARM's handicap in desktop/server all really come down to the software (and maybe in the case of some ARM products what one might consider alpha/immature products).
"Instruction sets" are not fast, the implementations are. Also AMD has a nice chunk of marketshare which will only get bigger once Zen is out.
Getting more register names in x86-64 was a huge boost too.
"to pretend x86 is fast" is a terrible choice of words. The fundamental problem is the memory wall. There are only two ways to solve it. Either put the processor directly onto the memory or add complex circuitry to mitigate it's effects. The former is difficult because DRAM and CPUs use different manufacturing processes. Thus neither x86 or ARM can avoid the latter if they want to maximise performance and in turn they become less power inefficient.
What you should have said is "to pretend DRAM is fast". It's not.