miskMicrosoft says “Prism” translation layer does for Arm PCs what Rosetta did for Macs
jqubedI don’t really know if ARM adds benefits I’d really notice as an end user, but it’ll be interesting to see if this really goes through and upends the dominant architecture we’ve seen for really 40+ years.
partial_accumenIf nothing else it breaks the stranglehold the 2.1 x86 licensees (Intel and AMD) have on the Windows market. Its just that that market is much MUCH smaller than it was 20 or 30 years ago.
So we replace two players with one (ARM)?
atocciARM is the licensor, not the licensee. At the very least, they are willing to license the ARM architecture to more companies (the licensees) than Intel is with x86. More RISC-V support would be ideal though for sure...
Right? I’m much more excited to see RISC-V start to become more powerful and have more commercial offers of hardware to compete against the global tech brokers. We need the FOSS version of hardware or else our future privacy and ownership rights will forever be in jeopardy with info tech.
ricdehRISC-V is just an ISA, the same for ARM and other RISCs and CISCs. There’s no guarantee that RISC-V will be any freer than current CPUs, because the actual implementation and manufacturing are the job of the OEMs.
RISC-V is an open standard under an open and free license. Which means that it doesn’t require an expensive proprietary licensing fee. Effectively it means that it has the potential of creating cheaper hardware that manufacturers can create with lower cost overhead and whatever improvements they make upon the designs can be used for free by other manufacturers. And it is the necessary development bed upon which open source hardware can be created.
The RISC-V ISA is free and open with a permissive license for use by anyone in all types of implementations. Designers are free to develop proprietary or open source implementations for commercial or other exploitations as they see fit. RISC-V International encourages all implementations that are compliant to the specifications. […] There is no fee to use the RISC-V ISA. FAQ
gregorumThe benefits, basically, are that it can provide an architecture that is designed for modern computing needs that can scale well into the future. That means high performance with low power consumption and heat.
The x86/64 model has been up against a wall for a while now, pumping out red-hot power hogs that don’t suit modern needs and don’t have much of a path forward wrt development compared to ARM.
Uranium3006I give ARM a decade before RISC-V eats it from the bottom up
Huh?
32-bit ARM and x86 were both from 1985…
It did take ARM a lot longer to make 64-bit work
As an ARM Mac user, I wouldn’t trade all this new battery life for an x86 processor
Second this. Not to mention INSTANT resume from suspend! It’s fucking crazy. I can use this thing ALL DAY doing webGL CAD work and Orca Slicer and barely scratch 50%.
With a modern system, I honestly don’t think there’s a noticeable difference between suspend to ram and suspend to disk. They’ve gotten the boot times down so much that it’s lightning-fast. My work laptop’s default is suspend to disk, and I don’t notice a difference except when it prompts for the bitlocker password.
S0 standby is borderline unusable on many PCs. On Apple silicon macs it’s damn near flawless.
My current laptop is probably the last machine to support S3 standby and I do not look forward to replacing it and being forced back into a laptop that overheats and crashes in my backpack in less than 15 minutes. On my basic T14 it works ok for the most part, but my full fat Thinkpad P1 with an i9 is in S0 standby for longer than a few minutes, and sometimes uses more power than when it was fully on. Maybe Meteor lake with it’s LP E cores will fix this but I doubt it.
voxeltbh it has been nearly flawless on win11 for me (just make sure to disable automatic windows updates unless you want to get woken up by jet turbine sounds in the middle of the night)
As a potential iPad buyer, I would trade a millimeter of slimness for a vastly improved battery.
Idk, the battery of my 12.9“ iPad Pro is great.
There’s nothing stopping x86-64 processors from being power efficient. This article is pretty technical but does a really good explanation of why that’s the case: chipsandcheese.com/…/why-x86-doesnt-need-to-die/
It’s just that traditionally Intel and AMD earn most of their money from the server and enterprise sectors where high performance is more important than super low power usage. And even with that, AMD’s Z1 Extreme also gets within striking distance of the M3 at a similar power draw. It also helps that Apple is generally one node ahead.
If there’s ‘nothing stopping’ it then why has nobody done it? Apple moved from x86 to ARM. Mobile is all ARM. All the big cloud providers are doing their own ARM chips. Intel killed off much of the architectural competition with Itanic in the early 2000’s. Why stop?
Their primary money makers are what’s stopping them I reckon. Apple’s move to ARM is because they already had a ton of experience with building their own in house processors for their mobile devices and ARM licenses stock chip designs, making it easier for other companies to come up with their own custom chips whereas there really isn’t any equivalent for x86-64. There were some disagreements between Intel and AMD over patents on the x86 instruction set too.
So there is something stopping them. The manufacturers.
This article fails to mention the single biggest differentiator between x86 and ARM: their memory models. Considering the sheer amount of everyday software that is going multithreaded, this is a huge issue, and the reason why ARM drastically outperforms x86 running software like modern web browsers.
Do you mind elaborating what is it about the difference on their memory models that makes a difference?
On the x86 architecture, RAM is used by the CPU and the GPU has a huge penalty when accessing main RAM. It therefore has onboard graphics memory.
On ARM this is unified so GPU and CPU can both access the same memory, at the same penalty. This means a huge class of embarrassingly parallel problems can be solved quicker on this architecture.
That’s actually not what I was referring to, although the unified memory architecture is certainly more power efficient for mixed-intensive workloads.
Do x86 CPUs with iGPUs not already use unified memory? I’m not exactly sure what you mean but are you referring to the overhead of having to do data copying over from CPU to GPU memory on discrete graphics cards when performing GPU calculations?
Yes unified and extremely slow compared to an ARM architecture’s unified memory, as the GPU sort of acts as if it was discrete.
Do you have any sources for this? Can’t seem to find anything specific describing the behaviour. It’s quite surprising to me since the Xbox and PS5 uses unified memory on x86-64 and would be strange if it is extremely slow for such a use case.
It’s been a while since I’ve coded on the Xbox, but at least in the 360, the memory wasn’t really unified as such. You had 10 MB of EDRAM that formed your render target and then there was specialised functions to copy the EDRAM output to DRAM. So it was still separated and while you could create buffers in main memory that you access in the shaders, at some penalty.
It’s not that unified memory can’t be created, but it’s not the architecture of a PC, where peripheral cards communicate over the PCI bus, with great penalties to touch RAM.
Well for the current generation consoles they’re both x86-64 CPUs with only a single set of GDDR6 memory shared across the CPU and GPU so I’m not sure if you have such a penalty anymore
It’s not that unified memory can’t be created, but it’s not the architecture of a PC, where peripheral cards communicate over the PCI bus, with great penalties to touch RAM.
Are there any tests showing the difference in memory access of x86-64 CPUs with iGPUs compared to ARM chips?
Here is a great article on the topic. Basically, x86 spends a comparatively enormous amount of energy ensuring that its strong memory guarantees are not violated, even in cases where such violations would not affect program behavior. As it turns out, the majority of modern multithreaded programs only occasionally rely on these guarantees, and including special (expensive) instructions to provide these guarantees when necessary is still beneficial for performance/efficiency in the long run.
For additional context, the special sauce behind Apple’s Rosetta 2 is that the M family of SoCs actually implement an x86 memory model mode that is selectively enabled when executing dynamically translated multithreaded x86 programs.
Thanks for the links, they’re really informative. That said, it doesn’t seem to be entirely certain that the extra work done by the x86 arch would incur a comparatively huge difference in energy consumption. Granted, that isn’t really the point of the article. I would love to hear from someone who’s more well versed in CPU design on the impact of it’s memory model. The paper is more interesting with regards to performance but I don’t find it very conclusive since it’s comparing ARM vs TSO on an ARM processor. It does link this paper which seems more relevant to our discussion but a shame that it’s paywalled.
simpleYou will definitely notice better battery life as an end user.
PeachManI’m not expert, but I can tell you that Apple Silicon gave the new Macbooks insane battery life, and they run a lot cooler with less overheating. Intel really fucked up the processors in the 2015-2019 Macbooks, especially the higher-spec i7 and i9 variants. Those things overheat constantly. All Intel did was take existing architectures and raise the clock speeds. Apple really exposed Intel’s laziness by releasing processors that were just as performant in quick tasks, they REALLY kicked Intel’s ass in sustained workloads, not because they were faster on paper, but simply because they didn’t have to thermal throttle after 2 minutes of work. Hell, the Macbook Air doesn’t even have any active cooling!
I’m not saying these Snapdragon chips will do exactly the same thing for Windows PC’s, obviously we can’t say that for sure yet. But if they do, it will be fucking awesome for end users.
Battery life and thermals. really neat for laptops
The idea is ARM can be more efficient, which translates as longer battery life and/or faster computers for the end user.
Let’s spend all that new-found battery life by translating x86 code to ARM code.
LOL if MS says it then you know it’s the exact opposite.
woelkchenWhat Apple did for Macs when switching architectures, though, was to port their own software to the new architecture. Microsoft doesn’t even port fucking Minesweeper to ARM.
JohnnyCanuckIsn’t that the point? This new layer is supposed to make it easier to port everything, and they’re saying that’s what Rosetta did for Apple/Mac.
Translation layers aren’t porting
Fair enough, but to the end user it doesn’t matter if it works.
to the end user it doesn’t matter if it works.
Emulation is always slower and eats more battery. Microsoft’s laziness is proof they don’t care about that hardware, so may just as well buy an iPad Pro instead.
Emulation is almost always slower and eats more battery.
FTFY. There have been some cases where emulation actually outperforms native execution, though these might be, “the exceptions that prove the rule.” For example, in the early days of World of Warcraft, it actually ran better on WINE on Linux than natively on Windows.
For example, in the early days of World of Warcraft, it actually ran better on WINE on Linux than natively on Windows.
WINE literally stands for “WINE Is Not an Emulator”.
To be fair this is also a translation layer and not an emulator.
To be fair this is also a translation layer and not an emulator.
Prism is an x86 emulator for ARM. If you think that Prism is “a translation layer and not an emulator”, I refer you to the very first word of the second to last paragraph of the submitted article.
That’s assuming the writer knows what they’re talking about. Last line from the second paragraph:
Windows 11 has similar translation capabilities, and with the Windows 11 24H2 update, that app translation technology is getting a name: Prism.
And first line from the third paragraph.
Microsoft says that Prism isn’t just a new name for the same old translation technology.
That’s assuming the writer knows what they’re talking about.
Certainly more than you because Prism emulates an x86 CPU and WINE doesn’t, therefore the WINE comparison is still wrong.
Edit: Please prove the writer wrong.
This article seems to conflate “emulation” and “translation layer”. I don’t think there is anything that confirms “Prism emulates an x86 CPU”, only that it allows for running x86 code on ARM. This does not inherently require emulation as demonstrated by Rosetta 2, which is a translation layer.
only that it allows for running x86 code on ARM. This does not inherently require emulation as demonstrated by Rosetta 2, which is a translation layer.
WINE doesn’t “translate” one CPU architecture to another CPU architecture either, so the WINE comparison is still wrong, no mater if CPU translation is called emulation by you or not. WINE is a wrapper for API calls within the same CPU architecture. That’s it.
WINE doesn’t “translate” one CPU architecture to another CPU architecture
“Windows apps are mostly compiled for x86 and they won’t run on ARM with bare Wine”
What you linked is an effort to combine WINE with the QEMU x86 emulator which is an emulator because it emulates CPU calls. Hint that it’s an emulator is in the name “QEMU” and an actual quote from the wiki page you linked and clearly didn’t care to read: “Running Windows/x86 Applications: See Emulation”
EDIT: Let me also quote from the readme file of the Hangover project:
Hangover uses various emulators as DLLs (pick one that suits your needs, e.g. works for you) to only emulate the application you want to run instead of emulating a complete Wine installation.
Wine is not an emulator
To add to what the other person said, there are some Windows-only games that run better on Linux than on Windows (I don’t have examples off the top of my head.)
Wine is not CPU emulation.
Just like wine is not a windows emulator, this will not be an x86 emulator
This is a pretty interesting counter example: eteknix.com/running-yuzu-on-switch-gives-you-bett…
But, as others have said, exceptions confirm the rule.
Yuzu can exhibit superior performance because the Switch is rocking the Tegra X1 from 2015. Yuzu absolutely cannot beat the Switch with contemporary hardware and/or comparable power consumption.
But yuzu was running on the switch in that example. So it was beating the switch on contemporary hardware.