I think the question is whether the performance will be reasonable. Most emulators (e.g. of gaming consoles) struggle to keep up with recent software, since the translation often incurs in a lot of overhead.
Game emulators are running everything emulated. An application running on top of an operating system will hopefully get some benefit of spending time calling native operating system code. It helped a lot back in the day with Apple’s 68K to PPC transition.
I assume it's targeted at consumers. Many of them are happy right now with Windows on old Core 2 Duo, Celeron, etc, machines. Assuming a sufficiently fast ARM processor, they may not notice the slowness the same way you would.
Yes, exactly. AMD made it a mandatory part of the AMD64 spec. Before that, SSE2 was an optional part of the ISA. Now, it's required if you support AMD64. Not a problem for AMD, since it had a cross license agreement with Intel, but an issue for anyone else. It's not a coincidence that AMD64 support is being proposed when the AMD64 and SSE2 parents are expiring (likely Microsoft has a license agreement with AMD, given how short of cash AMD was until recently, and AMD's need for MS to support AMD64 in the first place.). So, quite possibly the main holdup for Microsoft to emulate AMD64 has been to wait until the SSE2 patents expired.
>Intel has put out a legal fix statement last time around. Similar announcement this time?
AMD64 was announced in 1999 and the spec was out in 2000, with the first implementations in 2003ish IIRC, and Intel releasing its implementations starting 2006 somewhere. While there have been more extensions and new features since then, most of the really key ones from the basic perspective of requirements to run software were early. Which means we're at or rapidly approaching the big deal day when all possible patents expire on all core parts of the ISA. It'll definitely be very interesting to see what happens at that point. As well as Microsoft, it may be something Apple has been waiting for as well. Moving to their own chips for Macs would be a lot easier if they can just flat out implement x86-64 (or at least enough of it) however they want for a transition period or even permanently.
It's actually the x86-64 instruction set, that is to say, the 64-bit version of x86. AMD created the first implementation of this set with AMD64, and Intel then adopted it with their own flavor as Intel 64. I don't think the headline is as accurate as it could be. Probably wrote the headline with the assumption that "most readers" would better understand "64-bit Intel" than "x86-64" but they might be underestimating their readers! And even then, it's officially called "Intel 64" according to Wikipedia.
AMD invented 64-bit extensions back when Microsoft was busy trying to differentiate between their "big metal" Itanium chips and consumer processors. Turns out everyone wanted more memory and didn't want to have to rewrite all of their apps to get it.
Intel then had to license it, but because it's Intel they refused to call it AMD64. So the industry as a whole just started saying x86-64 to mean both AMD64 and Intel 64 so that the general consumer wouldn't think that insert app wasn't compatible with both.
Someone with a better understanding of CPU architectures and instruction sets may be able to correct me if I'm wrong, but wouldn't it be more accurate to say that Microsoft is working on bringing x86-64 emulation to Windows 10 on ARM? No doubt the headline is written to be a bit more consumer-friendly.
AMD pioneered this version of the instruction set with AMD64, and Intel actually adopted it as Intel 64, with minor differences[0].
>The original specification, created by AMD and released in 2000, has been implemented by AMD, Intel and VIA.
>Intel's project was originally codenamed Yamhill. After several years of denying its existence, Intel announced at the February 2004 IDF that the project was indeed underway.
If Intel wasn't so focused on the Itanium they would of beat AMD by years.
Anybody who was following the industry at the time knew about Yamhill at least by 2002, though Intel had conceptions on how to extend x32 to x64 well before that in a natural way, but instead went the resource and engineering draining Itanium route, allowing AMD to produce the first available chips.
While I only know murmuring on the peripherial about Intel's early x64, I'd love to hear insider knowledge about why management decided Itanium was so hot that they dropped everything about bringing x32 to its logical x64 conclusion.
They’re all just different names for the same ISA, and both parties have extended it since. Are you complaining about credit? AMD just extended Intel’s design to a wider format. Why should AMD get more credit? I do write AMD64 myself, but title is fine.
> AMD just extended Intel’s design to a wider format.
In that case just call it x86 as a catchall. But if you're going through the effort to specify the 64 bit ISA, then "Intel's" stops being particularly correct.
MS removed 16-bit support on 64-bit Windows. Linux and WINE can run older Windows programs than Windows can! So, if Microsoft is the polar opposite, then Linux must be the stratospheric opposite.
As far as I know, Windows 10 does not support 16-bit segments at all, so Wine on Windows 10 would
be unable to execute 16-bit code. I don’t know to what extend 64-bit Windows supports segmentation at all.
Linux, in contrast, gives complete control of the LDT except that the LDT may not contain call gates, long mode segments, or anything with DPL != 3.
Making this work safely, especially on x86_64, is a real PITA, so I can’t really blame MS for declining to support it.
Windows 10 can run Linux in a VM (e.g. Windows Services for Linux, which is a VM these days), and it can run DOS or Windows 3.1 or whatever else in a VM as long as you have virtualization enabled. What it can't do is run native 16-bit segmented code as a regular user mode process. Linux can.
The NTVDM port appears to be a legally dubious emulator.
Apple can afford to do that, and still retain royal customers. The lock-in is too real.
Microsoft on the other hand has to keep literally everyone happy (90% of the world not on Linux or Mac). Ofc, they can't abandon backwards compatibility.
The reason that IBM/Motorola stop being competitive was the cost of staying competitive was to great compared to the number of processors they hope to sell. By the time that Apple made the switch to Intel, they were the only PPC customers besides game consoles and mainframes that had different needs. Apple was only selling five or six million computers back then.
Now, Apple sells about as many ARM based devices than all of the PC manufacturers combined [1] sell x86 chips. Apple will be its own best customer.
[1] Apple sold about 230-240 million iPhones, iPads, watches, AppleTVs and if it start selling ARM Macs it will add about 16-20 million to that number.
They're trying to "unlimit" it by making emulated x86/x64 apps work, otherwise the chicken/egg/app/platform problem persists.
Supposedly ARM is more power efficient than the x86 family, so you'd get lighter laptops with longer battery life.
I would love to know from the HW experts here what happens when you start running your usual desktop workload on an ARM device. Does the power consumption stay low ?
looking at how quickly phones run out of battery when playing games, my feeling is that the ARM advantage is over-hyped, but I'd be interested in opinions from people who know this stuff.
Phones have much smaller batteries and you’re not going to usually be playing graphic intensive games on a laptop. Besides, games usually use the GPU which would use up more battery.
Reviews have stated the emulation performance is terrible - akin to Rosetta back in the PPC/Intel transition into OSX.
I read two reviews which stated even 32-bit Chrome’s performance was terrible compared to the native ARM 64-bit Edge, and Photoshop, etc, are borderline unusable.
Stranger still, the Surface Pro X’s battery life has been reported to be on par or poorer than the less expensive Intel-native Pro 7’s - I’m rather confused by Microsoft’s strategy here.
Sorry, my phrasing was terrible, as usual. I know the emulated performance is terrible. My query is about native ARM desktop workloads vs native x86 desktop workloads (if Microsoft's vision comes to fruition) in terms of power consumption. I really can't imagine they'd be different, but I don't know enough about it other than "tech press" comparing phone battery lives to laptops.
I am also quite curious about this. Just like when I see review sites benchmark an iPad versus a surface pro running full windows, I can’t help but be confused as to what anyone really hopes to learn from such an apples to oranges comparison
I acquired a Surface Pro X. I can't compare it to a 7 but battery life is excellent so far.
One thing that my previous Surface Pro 4 did was Connected Standby. It would usually be fine and wake up after an hour asleep just 1 or 2 percent battery down. But then other times I'd go to use it and it'd be at 20%.
So far this X has not betrayed me like that. It's been good for regular tablet use (not continuous) for 10 hour days, easy.
I'm sure there's a long German word that means "having your opinion about a product lowered due to a press release announcing a feature you already thought it had."
Who knew Wintel combination will become the curse for Microsoft. Microsoft paid heavy price including a complete OS flop, and losing mobile war; just because developers were not ready to leave Win32 API and step down to WinRT (buggy and half baked). Current emulation for 32-bit is slow and reviews are terrible. I wonder if Intel will ever be able to develop something revolutionary that runs x64 and energy efficient as ARM.
WinRT may have been buggy but the mobile OSes were not so bad. They had mobile OS releases mirroring XP, 7, 8/8.1, and 10. The problem is Microsoft made no commitment to non-secureboot hardware on non-Intel devices and all of these devices were extremely locked down and not accessible to end users. Consequently, no one cared about them. You probably didn't even know they had a mobile OS patterned after Win7, right?
This turned around a little bit for the 8/8.1 and 10 mobile OS releases but not by much. A lot of stuff just wasn't possible on a Windows phone, even though the garden experience was exceptional.
This is stupid. Most desktop people don't want to touch ARM anything and rightly so - Qualcomm's chips suck (Apple's do great but even they don't seem to think they're rest to go ARM Mac yet), there's no battery life advantage especially when you do all the desktop things and you have to deal with ARM snowflake crap along with vastly limited SoC support for new OS versions. And needless to say without specialized CPU support the 64-bit Intel emulation is going to be dog slow - remember emulating ARM Android images on X64?
There's literally no upside to this. I just wish AMD puts out a great mobile CPU and we can have even better competition for Intel in laptop market.
So no thanks - I'll let Intel have their laptop monopoly if that means I can run standard x86 hardware with great support for non Windows OSes.
Can I ask you why? Do you know what you will be gaining and what you will be giving up? If it's just geeky dream it's ok but saying it like it would be objectively a better result to throw away standardized x86 for ARM on the desktop when you can also just carry a iPad instead is just silly. In Apple's case it's not going to be x86 and ARM macs - just ARM macs and for their business it makes total monetary sense to control everything from SoC/CPU to the OS. But if you are getting excited about that as a consumer, you don't really understand the irony - move away from Intel monopoly to more Apple monopoly.
That's all hunky dory but no amount of software innovation is going to speed up running x64 code on ARM. Qualcomm would just need to build that into the CPU and at that point it is a circus.
So yeah I am cool with trying out things that have potential but something that has not upside and will never be good - because CS - I will justly call it stupid.
57 comments
[ 2.8 ms ] story [ 103 ms ] threadLooks like bringing ARM power efficiency and crazy parallelism to windows is only a good thing for consumers.
AMD64 was announced in 1999 and the spec was out in 2000, with the first implementations in 2003ish IIRC, and Intel releasing its implementations starting 2006 somewhere. While there have been more extensions and new features since then, most of the really key ones from the basic perspective of requirements to run software were early. Which means we're at or rapidly approaching the big deal day when all possible patents expire on all core parts of the ISA. It'll definitely be very interesting to see what happens at that point. As well as Microsoft, it may be something Apple has been waiting for as well. Moving to their own chips for Macs would be a lot easier if they can just flat out implement x86-64 (or at least enough of it) however they want for a transition period or even permanently.
What is the difference between x64 and AMD64?
Why is it called "64-bit Intel app" in the headline?
https://en.wikipedia.org/wiki/X86-64#Intel_64
One official name among others. Linux distros tend to refer to it as amd64.
Intel then had to license it, but because it's Intel they refused to call it AMD64. So the industry as a whole just started saying x86-64 to mean both AMD64 and Intel 64 so that the general consumer wouldn't think that insert app wasn't compatible with both.
AMD pioneered this version of the instruction set with AMD64, and Intel actually adopted it as Intel 64, with minor differences[0].
[0] https://en.wikipedia.org/wiki/X86-64#Intel_64
>Intel's project was originally codenamed Yamhill. After several years of denying its existence, Intel announced at the February 2004 IDF that the project was indeed underway.
If Intel wasn't so focused on the Itanium they would of beat AMD by years.
Anybody who was following the industry at the time knew about Yamhill at least by 2002, though Intel had conceptions on how to extend x32 to x64 well before that in a natural way, but instead went the resource and engineering draining Itanium route, allowing AMD to produce the first available chips.
While I only know murmuring on the peripherial about Intel's early x64, I'd love to hear insider knowledge about why management decided Itanium was so hot that they dropped everything about bringing x32 to its logical x64 conclusion.
* they would have beaten
Isn’t that exactly what the title says? Which bit are you quibbling with? Or has the title been changed?
In that case just call it x86 as a catchall. But if you're going through the effort to specify the 64 bit ISA, then "Intel's" stops being particularly correct.
Linux, in contrast, gives complete control of the LDT except that the LDT may not contain call gates, long mode segments, or anything with DPL != 3.
Making this work safely, especially on x86_64, is a real PITA, so I can’t really blame MS for declining to support it.
The NTVDM port appears to be a legally dubious emulator.
Microsoft on the other hand has to keep literally everyone happy (90% of the world not on Linux or Mac). Ofc, they can't abandon backwards compatibility.
Intel might run into serious problems for whatever reason we can't even imagine today.
Apple switched from Power to Intel when IBM stopped being competitive in their area. Apple is rumored to also work on the switch to ARM.
It is usually a good idea to invest into a few alternatives if only it is to bring them up in negotiations.
Now, Apple sells about as many ARM based devices than all of the PC manufacturers combined [1] sell x86 chips. Apple will be its own best customer.
[1] Apple sold about 230-240 million iPhones, iPads, watches, AppleTVs and if it start selling ARM Macs it will add about 16-20 million to that number.
Supposedly ARM is more power efficient than the x86 family, so you'd get lighter laptops with longer battery life.
I would love to know from the HW experts here what happens when you start running your usual desktop workload on an ARM device. Does the power consumption stay low ?
looking at how quickly phones run out of battery when playing games, my feeling is that the ARM advantage is over-hyped, but I'd be interested in opinions from people who know this stuff.
I read two reviews which stated even 32-bit Chrome’s performance was terrible compared to the native ARM 64-bit Edge, and Photoshop, etc, are borderline unusable.
Stranger still, the Surface Pro X’s battery life has been reported to be on par or poorer than the less expensive Intel-native Pro 7’s - I’m rather confused by Microsoft’s strategy here.
The Surface RT didn’t work.
One thing that my previous Surface Pro 4 did was Connected Standby. It would usually be fine and wake up after an hour asleep just 1 or 2 percent battery down. But then other times I'd go to use it and it'd be at 20%.
So far this X has not betrayed me like that. It's been good for regular tablet use (not continuous) for 10 hour days, easy.
This turned around a little bit for the 8/8.1 and 10 mobile OS releases but not by much. A lot of stuff just wasn't possible on a Windows phone, even though the garden experience was exceptional.
To the contrary, I stuck with Windows phone forever. I loved it.
There's literally no upside to this. I just wish AMD puts out a great mobile CPU and we can have even better competition for Intel in laptop market.
So no thanks - I'll let Intel have their laptop monopoly if that means I can run standard x86 hardware with great support for non Windows OSes.
For one, I see Macs running on Apple’s own ARM chips a real possibility in the near future.
Even if the emulation is slow and barely useable, it can and will be refined using modern tools and practices in the future.
Trying something out that is out of the norm is the the whole point of innovation. I’m super excited to see Microsoft’s progress in this space.
So yeah I am cool with trying out things that have potential but something that has not upside and will never be good - because CS - I will justly call it stupid.
It is more expensive than the Pro 7, and the x86 emulation has been disappointingly slow.
Reviews have been poor on average, and it’s all reminiscent of the Surface RT debacle - except at least the RT was less expensive - not more.