What 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.
Another thing they did is add hardware support for the x86 strong memory model to their ARM chips, allowing for efficient emulation. Without this, translated code takes a big performance hit.
Did Qualcomm add something similar to their ARM CPUs ?
They’ve still got things that haven’t changed since about Windows 3.1, like that ODBC dialog window.
Isn’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.
To add to what the other person said, there are some Windows-only games even today 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
Its not laziness, they have lost developers support over time and lets be honest here, Windows 8 arm was roundly laughed out the door. Expectations are now marketing hallucinated by copilot.
This is typical Microsoft “agile”: minimum effort and delivery.
Not porting simple stuff like Minesweeper is definitely laziness on Microsoft’s part.
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.
deleted by creator
Isn’t that the point?
No, the point of Rosetta was to be a stop-gap for 3rd party software because Apple did all porting in-house software long ago.
Prism is Microsoft’s tool for staying lazy. Microsoft ships ARM-based Surface tablets since 12 years!!!
In all architecture transitions (PPC->Intel then Intel->ARM), Apple Chess has always been a native port from day one.
I firmly maintain that if Microsoft gave a shit about ARM, they would be defaulting every one of their compilers to produce fat x86/aarch64 binaries. The reality is, however, that they don’t care about the hardware so long as it is good enough.
if Microsoft gave a shit about ARM, they would be defaulting every one of their compilers to produce fat x86/aarch64 binaries
Wasn’t the point of .NET once that native binary code isn’t needed? I’d say if Microsoft gave a shit about ARM, everything would have been ported to .NET.
The 68k to PPC transition was rough though. It wasn’t until system 8 that Mac OS on a PPC mac was fully PPC code. But that was also a much different Apple that’s nothing like the Apple of today.
this is for the transition. no point in porting your software if nobody has the hardware. This will get people to get the hardware, as they can just keep using the existing software, and wait until it’s properly ported
Edit: you people really think windows is the only software that needs a translation? Do you only ever use your OS on your computer, and not a single software more?
Nobody will buy the hardware if they can’t commit to supporting the software. In a previous role, I was responsible for advising purchasing decisions for my company’s laptop fleet. The Surface X (Arm edition) looked cool, but we weren’t willing to take the risk, because at the time Microsoft had far worse transitional support than they do now. It’s gotten better, but no one in their right mind is going to make the kind of volume purchases that actually drive adoption until they demonstrate they are in it for the long haul. It’s a chicken and egg problem, and Microsoft doesn’t care what hardware you are using, so long as it is running Windows or using (expensive) Windows services.
What better way to sell devices than by halfassing them to oblivion?
Apple released a native x86 version of Tiger with their first Intel Macs.
Sure, but the vast majority of Mac software at the time, including loads of first applications from Apple, couldn’t run on Tiger. You had to run it in the “Classic” environment - and they never ported that to Intel.
Tiger shipped just 4 years after the MacOS 9.2 and plenty of people hadn’t switched to MacOS X yet.
The reality is Apple only brings things forward when they can do it easily.
Apple has done eight major CPU transitions in the last 40 years (mix of architecture and bit length changes) and a single team worked on every single transition. Also, Apple co-founded the ARM processor before they did the first transition. It’s safe to assume the team that did all those transitions was also well aware of and involved in ARM for as long as the architecture has existed.
No, this won’t get people to get hardware that looks horribly slow because everything needs to run through a translation layer. They do have the sources. They could just recompile them for the new hardware. If their sources are not total crap.
I’d expect there’s quite a lot of assembly and endianness-dependent stuff here and there. It’s Microsoft. Their culture is about pride of things being arcane-complex inside, cause if you can untangle that, you are a good programmer. They think that. I think they think that. Maybe they are just vile.
You may be spot on with that. Though the assembly part can be fixed by code translation at compile time. Endianess and shitty programming habits are another thing that the cross-executor must deal with, too, so maybe this has been covered already. Or it will blow up in their faces, anyway.
Both arches are little endian btw.
I’m sure they have found something to make the port problematic.
I mean, it’s a Microsoft product.
Windows NT historically ran on lots of CPU architectures, PowerPC, MIPS, Alpha, Itanium, etc, and that included the bundled software like 3D Pinball. I would have expected it to still be quite portable.
20 years have passed.
Why the fuck would they name it PRISM?
Just being honest about how much data Windows collects these days…
Maybe their goal is to bury that prism and hope people forget?
Lol they knew exactly what they were doing…
They probably want to bury it by making their Prism more SEO friendly
Prism is definitely a bad name , Edward Snowden knows
Is it ? ( ͡° ͜ʖ ͡°)
I 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.
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 hibernation! 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.
tbh it has been nearly flawless on win11 for me with an amd cpu
(just make sure to disable automatic windows/defender updates unless you want to get woken up by jet turbine sounds in the middle of the night)
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: https://chipsandcheese.com/2024/03/27/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?
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.
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. The cost of transferring to/from dedicated GPU memory is (unsurprisingly) quite large.
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.
deleted by creator
deleted by creator
Idk, the battery of my 12.9“ iPad Pro is great.
I’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.
If 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)?
ARM 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.
RISC-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. It is the necessary development bed upon which open source hardware can be created. 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.
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
While all other ISAs are proprietary standards that charge chip designers up the nose to even look at the specifications. Hence why there’s so few chip manufacturers in the world.
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.
You will definitely notice better battery life as an end user.
Battery life and thermals. really neat for laptops
The 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.
Huh?
32-bit ARM and x86 were both from 1985…
It did take ARM a lot longer to make 64-bit work
I give ARM a decade before RISC-V eats it from the bottom up
I don’t see this working. The reason that Apple and ARM work is because Apple controls the whole ecosystem on Macs.
Apple controls the whole ecosystem on Macs.
In what sense? The vast majority of macOS software is downloaded/installed from the internet, just like Windows.
I don’t see it working because the Windows APIs are a dozen self-oxidizing dumpster fires scattered into the wind, but that’s a different story.
They control the ecosystem in the way that they provide what hardware is new on MacOS and what capabilities it has. So if any developer wants to support modern devices they have to port to that new hardware. They don’t have any choice, if they want to stay relevant.
I wouldn’t necessarily present that as a good thing. If operating systems become incompatible with old software, that means that such software cannot be effectively preserved and may be lost to time eventually without a committed maintainer.
This is and always will be true about software. Progress sometimes means abandoning bad ideas, even ideas that were good at the time but are bad now that something else has changed.
Old Windows games generally don’t work on modern Windows without a virtual machine.
So if any developer wants to support modern devices they have to port to that new hardware.
See, you say that, but it doesn’t seem like Rosetta 2 going anywhere any time soon, which means developers aren’t pressured their software to ARM.
One of the biggest problems I had with windows on ARM was drivers. Most of my devices that needed drivers didn’t have an arm compatible version available. This needs to change more urgently than simply being able to run software, for me, at least.
What drivers?
Most importantly, my soundcard. But also my graphics tablet.
On a ARM device? Wouldn’t the device be made for ARM compatibility?
External devices I presume
Yes, that’s right. Of course, ms shipped a device with drivers for its own hardware.
But most devices I plugged in, that needed drivers, had problems installing.
…It took them only 4 years to follow the leader this time.
It has more to do with manufacturers than Microsoft. Nobody was making high performance ARM chips, so there was never a market for windows on ARM until now
Windows on arm was a thing, I had a surface 2 rt about a decade ago, too bad it never felt like microsoft ever really fully committed to the idea imo, and yeah x86 apps wouldn’t run on it (though there was an emulation tool apparently, was community developed). Market was definitely there (though I’m not sure how big it was, probably a cross over with netbook users), they just fumbled it like they did windows phone in my view.
Same argument can be valid for Apple as well.
Although it may look like Windows is a platform for any-hardware, reality is MS can and does push manufacturers to shape hardware as it’s desire, like forcing all mainboards to have TPM.
…but Apple started making performance ARM chips 4 years ago
And Apple was not selling those chips to Windows laptop manufacturers.
True but Nvidia has been making performant ARM chips (for example, the ones in the Nintendo Switch)
The Tegra X1 is slower than existing underpowered arm processors used in windows laptop. It’s nowhere near performant enough.
I can hear the game launchers laughing. If EA doesn’t have a native version of their app out, that should be every reviewers first test.
LOL if MS says it then you know it’s the exact opposite.
While they are at it, can we get Prism for Linux?
We have Box64
And fex
not hw accelerated either
And my Axe
not hw accelerated
I’m not sure that means anything. For it to be hardware accelerated you would need a amd64 cpu
both apple m cpus and snapdragon have hardware magic to make translation viable when paired with usermode tools like Rozetta or Prism
otherwise it’s painfully slow, as demonstrated by both box64 and fex.Do you have a source for that? It seems like that would defeat the purpose of using ARM.
well apple cpus have a hardware flag which slightly changes side effects of some existing arm instructions AND completely changes the memory model to one that imitates Intel x86 for the current thread. (TSO)
with this flag enabled, the code can be almost fully recompiled ahead-of-time (from x86_64 to arm64) with minimal overhead (no need to remap memory addresses etc), with no reason to resort to e.g. jit recompilation on the fly (which is exactly what box64 does all the time)
i assume snapdragon and microsoft are doing a similar thing (it definitely involves some hw magic too, maybe not exactly the same as in apple) since it’s seemingly the only way to achieve parity with apple in terms of performance
now we need some sort of hw-accelerated x86_64 layer but for linux
Isn’t there already Box64/Box32? Not to mention most Linux software is already compiled for ARM thanks to being open source.
yes, but you’ll be missing out on ALL games, none of which are compiled for arm64.
also no, box64 is not hardware accelerated. both snapdragon and apple m series cpus have hardware magic that makes translation viable at all (as demonstrated by box64’s (and even fex) piss poor performance)
