From past experience...
"battery life is comparable to smartphones in its class" is code for "it lasts half as long" right?
The first Intel-based smartphone has been unveiled, but don't go looking for it at AT&T, Vodafone, Verizon, or Orange. When the Lenovo 800K ships in the second quarter of this year, you'll have to get yours from China Unicom. "Today, I'm thrilled to announce that the best of Intel's computing is now coming to smartphones," …
Even if Intel is filling their boots with money to start with how is this going to work long term? Intel's chips are not just hotter than ARM ones they are significantly more expensive, which is where Intel's massive profits come from. If for no other reason than they're, er, cheap as chips, ARM offers a compelling argument against x86 where you have only two vendors.
Looking forward to wider deployment of ARM (or MIPS perchance) based workstations. And servers. We really could use some more competition there.
The problem is of course that too much programmers have been on a monoculture of x86 for far too long, making it harder to outperform. Then again, code that unduly depends on the underlying architecture is a liability and thus gives a good excuse for fixing-or-replacing. 'Sides, I don't really care about "javascript performance" in a smartphone. In fact, on the desktop needing such is highly questionable already. Most js is cpuburn making up for developer lazyness. That means the developer hasn't done his homework, and doesn't scale well.
Most "app" code is written for virtual machines so native optimisation, apart from for iOS, is not such an issue. The compilers seem to be doing a good job of cross-compiling for the various ARM flavours when native is required.
I've never been a fan of Javascript but the work done by the various browser makers have turned it into a reasonable basis for cross-platform development which is what we consumers need if we are to benefit from a large choice of devices and software that "works" on all of them. If things continue to develop at their current pace, it wouldn't surprise me to see dedicated Javascript units on the ARM chips which should give the same kind of improvements that you get with hardware OpenGL over the software variant. This might be one of the reasons that Google bought Motorola for as a way to unify their Javascript / NaCl projects.
@"code that unduly depends on the underlying architecture"
First off that's the only way to get good performance out of any processor. Second, one of the biggest categories of applications is games (around 40% of apps on mobile devices) so we are talking about hundreds of thousands of games available on mobile devices and many of them are coded to use the underlying CPU and many will not bother (uneconomical) to support less than 1% of the market devices like x86 based phones and so x86 based phones will find lots of apps simply not working on them, so that will hamper their uptake in the market.
We have already played out this scenario before in the days of WinCE mobile PDA devices. They tried to support multiple processor types and it didn't work out well. In the end, they went ARM only and dropped all support for other manufacturers CPU's which not only hampered the uptake of all WinCE devices (as the market was split between supporting 3 different processor types) but even worse, customers who bought the other processor types suddenly found their new PDA's were no longer supported and so were understandably very unhappy about loosing hundreds on unusable obsolete hardware.
So now lets compare the 3 main contenders in mobile, namely, Android, iPhone and Windows (Support for RIM, like it or not is dying).
In the case of Android they do native C++ code via the NDK (and can compile for multiple CPU types, but as multiple CPU's haven't been around for ARM many just compile for the lowest common denominator). Plus there are many Android games already out there, that developers simply won't bother updating to x86. Also iPhone is a more controlled environment so ARM only, but they can also do C++ development as well.
However in the case of Windows, we have C# only mobile development. So Microsoft are playing the exact same game they tried and failed with back in the days of WinCE PDA mobile devices. Microsoft plan to support multiple CPU types and hamper all Apps via C#. Hamper, not because C# is good or bad, but simply because its not cross platform. The problem is, games engines are very non-trial code bases to write and so cross platform development is vital. For example the Unreal engine can and does work on Android and iPhone. Its already on both platforms ... but don't hold your breath for Windows phone support. End result, it means games will not support Windows phones as much and certainly not the larger games without more expensive development costs to write c# specific versions. So that instantly places Windows phones at a commercial disadvantage in being unable to host many (not all, but many) of the games other users on other phones are playing.
End result, like it or not games are popular and x86 and Windows are not going to get equal support as Android and iPhone now have. That places x86 phones and Windows phones at a commercial disadvantage.
So there goes Microsoft's hopes of competing and Intel doesn't have a hope in hell of competing with ARM on mobile devices. (Also one ARM CPU I was looking at recently only had 80mW power usage per GIP of processing power, so there is no hope of Intel achieving that low level on the same chip making process. With Intel's bloated legacy x86 design, they cannot even get close to that low power on the same chip process size).
..this is a report full of unproven statements and vendor hype. Let's just pick the power consumption argument claiming an x86 processor would be competitive with an ARM-based CPU:
Their claim of "being in the same class" is nothing more than an unchecked claim. If TheReg wouldn't be lazy, they would have taken the device in question, hooked a multimeter or a scope between phone and battery and recorded true energy consumption in different, typical situations. Then they would do the same with competing, ARM-based products with the same or a similar OS.
Instead they are the mouthpiece of two major vendors who claim something they historically never managed to do. That's poor journalism.
Interesting. They have to do _MUCH_ better than their last effort:
I recall the X86emulator on Itanic. On the first revisions it was made in hardware, later they figured it did perform better in software and saved silicon.
It had one main shortcoming, it was tied to the core frequency of the itanic, and at 600MHz while the pentiums where at 2.4GHz it was way too slow to be usable, even for testing.