I’m almost an only Mac User since 1989 and I’m very grateful for this impartial review. Videos like this are the only way we have to assure that Apple keeps on improving their hardware. The more companies compete, the better products we’ll all have. It’s a win-win for Windows, Apple, Linux and other systems users. I’ve been following you for years and will remain doing so.
As I remember, Rosetta 2 does some type of translation on the first run of an application. This takes a certain amount of time but is cached so the second run of any application will be faster than the first. This would be worth testing to see if affects your findings.
I imagine a lot of the skepticism of Windows' x86-64 emulation is a result of the slow processors that came on the first Windows-on-Arm laptops, which would make a task running twice as slow feel MUCH slower.
I would like to see the Linux version of this video. Linux on ARM has also risen over the last few years and emulation of X86 has been a part of that too. I wonder how well that works.
@@arthurpizzaI noticed 2 years ago on Docker Hub that there was only 1 image I wanted to run that didn't have an Arm version. Last time I checked a few months ago, that one had an Arm version too.
I think the real advantage, that was confused as "better emulation", is just that Apple CPUs have been so much faster than the ARM CPUs Qualcomm has been using on their SoCs. It doesn't matter if your emulation layer is just as fast if your CPU is half as fast. I hope Oryon competes 1:1 against Apple and makes Windows on ARM a solid product.
Totally this! People who were claiming bad emulation performance under Windows did wrongly compare running the same code under emulation vs. much faster Intel CPU.
when first surface pro x was on the shelf, many applications cannot even use graphic unit of the qualcomm chip. and not to mention 64bit support came two years later? i don't know current situation, as there is almost no content about it, but microsoft made a terrible start on emulation front.
Apple CPUs implement Total Store Ordering, which is a feature of x64 and is about correctly handling memory accesses in multithreaded code. Without it, you need to generate slower ARM code that does store ordering manually. Also, Apple CPUs have a setting that changes how some status flags work , so that they work more like x64 flags, and adds some flag-related instructions. This makes the code easier to convert and also faster.
I can't wait for ARM to take off on Windows. I'll definitely get an ARM Laptop, great battery life and decent performance is all I've always wanted on Windows. I hope Microsoft encourages enough developers to port their apps over soon 😁😄
You have hit the nail on the head. Apple didn't give developers a choice, it was "Go ARM, or go home." All new hardware is Apple Silicon, and Apple was pushing developers towards compatibility (and immediate cross-compilation) via deprecations of various things (64-bit only, no 64-bit Carbon, etc.) for years _before_ Apple Silicon was even announced. For Windows, the vast majority of devices being shipped today - like, 95+% - is still x86-based. Where's the incentive to developers to make ARM-based versions of their apps available? It doesn't exist. If the process is not "check a box, compile, ship" easy, they're not going to do it. Not for years.
@@MichaelAlderete I don't find the x86 instruction set useless. I don't mind owning an x86 desktop as long as I'm getting that top notch performance. I just need that efficiency of ARM for laptops and small form factor PCs. There has to be a way for Windows to convince developers to port over without trying to get rid of x86. I think both of them can coexist side-by-side.
One of the claims Apple made about their emulation approach was that it would improve over time. The first time it translated X86_64 code it would be slow, but the second time it would be much faster. Can you think of a way to test this? The understanding I have of how this worked, is that the translated code would be stored, and re-used the next time it was needed.
@@JxcksonSF The way it was explained: “If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process. When translation finishes, the system launches the translated executable in place of the original. However, the translation process takes time, so users might perceive that translated apps launch or run more slowly at times,” So, every component that is translated is saved as an Apple Silicon native executable.
This seems like a relatively simple Just-Ahead-of-Time-like optimization that doesn't suffer from any big obstacles. This is already a super common idea in other corners of the tech landscape e.g., installing apps on Android, the Julia programming language, and so on. Considering windowsy things like powershell or dotnet already do optimizations like this, this is probably already planned / implemented.
The end-user experience is what matters. I’ve rooted for the Surface Pro X since its arrival. But the performance has been slower and software has been limited. While the back-end experience might be similar, the results in everyday use have been not. Snapdragon’s new chip has raised hopes once again (particularly when you see who created the new tech). But let’s see if the hardware will give us similar performance that we see on a M1 MBA.
@@hanspeter9592 I liked being an insider, never noticed any degradation in performance, and at times noticed nice bump, I'm not on supported 11 hardware and 11 ran faster, but I had to go back to 10 when I sent the laptop in for accident insurance repair. Make sure you get constant images, especially of the build before you begin, after a short while insider deletes your on drive roll back image. In other words, of course, keep current images and a permanent image of the build before insider
I've been using it a lot for the Raspberry Pi 5, and the support has been impeccable. I haven't run into any software that didn't have an ARM build available
@@1funnygame I did my Engineering final project on Raspberry Pi 4b and was truly amazed by it's capabilities. It even ran a full CNN model i did for my project, although I was a little annoyed by Pi team updating the Pi Camera libraries and it took me some time to figure out the new functions and how to use them.
I also did a few tests with box64 - the most popular Linux solution for x86-64 emulation for arm64. In all my test box64 was quite a bit slower than both Windows and MacOS provided emulation.
@@Silent.killer_007 There are already some projects that do that to some phones. I can't think of which off the top of my head, but I very strongly remember seeing some older Snapdragon phones getting WOA ported to them through software wizardry beyond my comprehension.
I really like to see the application you wrote for the test. Window is heavily using dll’s even for standard c library functions. So how sure are you that it didn’t use arm based code on windows?
@@SunsetNovaIntel 14th gen is faster and when comparing against Nvidia GPUs it is not even a fair game. Additionally Apple Silicon cannot be upgraded, your only advantage is on power consumption which provides impressive battery life but that's it mate.
Most people comments about microsoft x86 emulation might from before volterra, it was a mess at the beginning compared to apple, but it not only improve but also show us what can be done. Wanna see what X elite can do, hopefully the game emulation scene can get as mature as apple's one is now.
The “not actually emulating x86” revelation is major, and the new Snapdragon chip is a critically important recent update to consider surrounding this topic.
Thanks for getting the hard numbers on this. I think because I ARM translation got off on a rocky start on Windows, it got a bad reputation. For example, a client of mine had all kinds of issues running x64 code on their Surface Pro years ago. Mostly it was just lack of compatibility, but those were early days. I think because Apple comes out the door 100% working, and has a very good hypenmarketing system, there's just a complete different perception in the two companies. Now, I'm watching this 6 months later, and Microsoft just announced a whole bunch of new ARM "Copilot" computers, two he translation and compatibility is probably even better now, or at least fully matured.
I can see the need for such comparison but I think there has been enough benchmarking of the M1 vs other Arm laptop processors. Doesn't add much at this point. Also for video encoding the test should include whatever hardware acceleration is available. When the Snapdragon X Elite is out then this will certainly need revisiting.
It may be that the Windows emulation has improved over time. IIRC when the Surface X came out, benchmarks showed that emulated software performed much worse vs native. Then when the M1 Macbooks first came out, reviews were showing much better emulation performance vs. Windows. It also could have been the issue you mentioned where MacOS still runs apps with the Arm library, although it was so early in the Apple silicon lifespan that I'm not sure if the apps had a fat version at the time. I don't remember all of the reviews I watched covering both, but I remember LTT being one of them.
True, i also remember something like this, but the problem here is that it was 3 years ago, and people still use that as excuse, but it seems the Windows 11 inside emulator is better like the individualy installed versions in Windows 10 (so when the M1 released). Good to see even Windows are serious about ARM.
@@TamasKiss-yk4st Well to be fair, Microsoft hasn't really made any splash about Windows on ARM, so people probably assumed it was dead or not a priority. We're probably going to see that change once devices with the new Qualcomm chips launch and Microsoft has some sort of event.
This makes a lot of sense if one think about the incentives. Apple wants the devs to quickly port apps over to Arm, so they only care that x86 just works and don't care too much about speed. Microsoft knows that a lot of devs will never port to Arm, hence they need to optimize better.
I recall Adobe announcing arm. Development of their suite back before apples switched to m1. I was mainly excited because of the possibility of the native version being rewritten and ported to the iPad but given this. Knowledge I’m excited to see when a surface book ships with a snapdragon elite
Windows just did not have competitive ARM hardware to run on compared to Apple silicone so people just assumed it ran poorly when the reality is it was running on much weaker hardware. Should be interesting to see how Windows & x86 emulation on Snapdragon Elite will perform in real life now that it's on a comparable platform to the M series.
Note that Microsoft has officially cancelled support for Windows 10 on ARM. So there is only Windows 11 on ARM. It lives happily within a Parallels Desktop VM on my Mac mini and receives all patches and function upgrades including the recently released 23H2. I bet the claims of Rosetta 2 being the better "emulation" stems from Windows 10 on ARM which had x86 emulation only and it was a real emulation, whereas Rosetta 2 uses JIT compilation of x64 code to ARM. Windows introduced JIT along with the x64-Support in Windows 11 on ARM. On Windows 11 on ARM, JIT compilation is only available for x64-Code (as it is in Rosetta 2 as there is no longer support for x86-Code in macOS for years now).
This was really useful. Thanks for taking the time to share the stats. It’s impressive it works at all. It’s nice to have options, though it’s slow enough if wasn’t viable for our use case. Half the speed meant wasting a heap of developer time waiting for tests to run. We wanted to keep it simple when our business transitioned to ARM a few years ago. We aligned our hardware refresh cycles and deployment planning to do it in one step. We adopted ARM workstations and moved our production load to AWS Graviton processes on the same day. In the end it was as simple as changing a flag in a docker build command and changing a setting on AWS. Roughly speaking, it’s working out about 40% cheaper than x86 was. The monthly AWS savings paid off the new workstation costs in under a year. The only x86 processor in my life is the one in my gaming PC.
Thanks for the comparison, it's really interesting to see how far emulation has come now that Microsoft is releasing consumer hardware with the Snapdragon Elite chips.
Except obviously they are different on each platform, so other than the name i.e Microsoft Word, there is little commonality between the actual code running.
@@GaryExplains and I think many people want to know how smooth or buggy they are. It's useless if it runs everything fast but crashes every 10 seconds.
Now I just imagined implications of Apple selling arm64 CPU in the wild to Windows hardware vendors... crazy idea, maybe I've been drinking too much coffee today... Gary, great review and explanations again, thanks!
Interesting topic. My guess as to why people have not responded with the facts that macOS on ARM performing better than Windows on ARM is because its not about the quantity and benchmarks, but the behaviour and experiences of how well the apps run on those platforms. So it's things like the number of apps that are supported, how well they run, signs of slow downs, glitches, etc that are harder to quantify (unless we conduct surveys with users). So making use of ARM libraries when available is a good optimisation technique, thus providing better experiences. But there are limitations, such as the lack of nested virtualisation if you're running VMs.
Maybe, but nobody replied with talk of those things either. The actual reason is that someone probably said it wasn't good in some review on a popular website and everyone just believed it and continue to regurgitate the same stuff without actually verifying if it is true or not. This phenomena doesn't only apply to this subject but many. I am kind of acting as a myth buster in that sense.
Additionally, didn't AppleSilicon have hardware to assist with x86-64 emulation? It was something to do with memory, but do pardon. My memory is hazy since I'd read about it when M1 initially launched with Rosetta!
@@GaryExplains Thanks Gary. Appreciate what you've done here. Granted I don't have evidence to suggest this, but it just feels that Apple's has done a really good job in implementing and providing developer support for ARM. I guess the years of experience the've had with iOS contributes to this. My experience with desktop Linux on ARM (via Parallels and Raspberry Pi) is quite good but rather limited (e.g. Linux Mint is not being available for ARM, some tools and libraries not available). As for Windows, I can only test this on Parallels (so I can't test WSL), but I'm surprised that some games on Steam runs well (like Dying Light). That said, I often can't help resorting to x86 when running desktop Linux and Windows for the better experience.
@@shahnawazshahin3781yes that is correct. The memory does assist in a way as the memory in apple silicon devices is laid out and designed the way x86 based systems memory is. As apparently ARM based systems use a different memory design. So apple gets the best of both worlds by using an ARM processor but having memory built the x86 way. This means it's likely impossible to get ARM windows on an ARM based MAC. The processor is correct but that OS would not be designed for how apple is doing the memory in the system. Apple does it this way for the best of both worlds I guess. But it's all a custom build.
This is what I've been holding out for. I'm going to wait another generation and probably pull the trigger on a system with one of these Snapdragon chips. I'm also very interested to see what x64 emulation on Linux is like.
You can sometimes fool most of the people, and some of the people most of the time, but you can't fool Gary - he rolls his own tests and _measures_ ! 😀
Very cool and great to know👍 So why Apple silicon always wins against Windows ARM PC? Better chip & code optimization? Or is it because till now, with the X-Elite chip released Windows never had similar high performance ARM chip like that comparable to the Apple’s Mx family?
@@PJSOFT Nuvia (ex Apple chief chip designers) was developing custom Arm server cores which Qualcomm adopted after their acquisition and is targeting for the Windows PCs. This is why their cores in comparison to Apple cores run with higher wattage and lower efficiency (efficiency cores r also missing on the X-Elite chips). What Apple does incredibly well is their ULTRA efficiency on both HW & SW side where both of these worlds r amazingly well connected and optimized. U can say that Apple's HW architecture (not just cores or chips) is designed specifically for the SW to run faster and more efficiently. This "only Apple" advantage gives Apple incredible control=power and always better performance per watt in comparison to X-Elite and any other Arm based SoC with of course almost endless budget to afford latest and most advanced chip manufacturing/packaging/interconnect processes.
As someone who prefers Apple (wont call myself a fan boy, but know people will call me a fan boy), the reality is that up until now (with the release of the snapdragon X elite) Windows didnt have a ARM based chip that was comparable to the Apple chips (meaning that the previous ARM chip that the Surface used wasnt as good as Apple Sillicon), therefore in real world use you will always have the experience the Apple emulation of x86 to be better than Windows. I think it is only now that it can be possible to really compare the two. I do think that because Apple has moved away from x86 machines as a whole forcing developers to create native versions, that Apple will will be beter than Windows on ARM (as great as the SD X Elite is I dont think that it is enough to get developers to create native ARM versions and therefore will always have to emulate programs and as mentioned in the video native is always better than emulation
Great video, Gary and your methodology is spot on. What important is that it is not your opinions or based on hearsays (what he said, she said). Anyway, it is good to know (and expected at least to me) that the emulators performance are almost similar on Windows and MacOS. Ultimately, these emulators won't be needed some years later down the line because nothing beats native code. It is interesting to speculate that perhpas in the future there will be split between ARM64 for mobile computing and x86_64 for desktop with regards to Windows. I don't think that x86_64, Intel, AMD will disappear into the ethos very soon.
One has to write x86 code to specifically use instruction set like SSE2 , Larger virtual address space, various types of modes. This should be job of linker and complier, which if not configured, would default to most optimised binary.
What I'd love to know, is how good Linux support will be on the new Snapdragon X Elite Laptops. I know native software support is actually pretty great, thanks to both RaspberryPi & Neoverse servers. But I heard from current Windows Snapdragon device owners, that boot & driver support for installing Linux has been fairly bad for the most part. Hope that changes, if it hasn't already. I'd love to have a Snapdragon X Elite Linux Developer Laptop.
Thanks Gary, that's exactly what I expect to see on youtube. When someone states something, it should be backed up by some tests. But there are still some kinds of things I don't understand well. There are different instructions, some may be better emulated on one platform, some on the other. It would be nice to see that in detail. It would help to understand the difference in results between your code and HandBrake. Another interesting topic is gaming. Windows games rely heavily on DirectX and windows PCs GPUs have hardware optimized for it. What about Qualcomm vs Apple in that regard? Can we expect AAA arm games anytime soon? If you know anything about it, please, let us know.
One thing I will say is that even if the emulation is just as good in either, developers will go to arm quicker on macOS due to it being a forced step forward, whereas windows isn’t as straightforward, but it’s good to see windows on arm
Gary, I'm sorry, but this is a terrible explainer. Apple does have a real technology advantage in this area against Windows on Arm. (Or at least they did as of a year or two ago.) The first part of it is memory ordering. Loosely speaking, this refers to the order in which an observing CPU core sees memory writes generated by other processor cores. x86 implements an ordering model called TSO, in which all writes are observed strictly in program order. Arm has a weaker model which permits some reordering - the writer might think it wrote thing #1 followed by thing #2, but an observer could see write #2 before #1. The practical implications of this are that (a) Arm processors can gain performance thanks to the extra reordering possibilities but (b) programs written for Arm may need more explicit thread synchronization when two threads interact. What does that have to do with emulation? Well, if your Arm processor takes full advantage of the reordering possibilities permitted by the Arm spec, every emulated x86 memory write will need to be treated as a thread synchronization point. Most memory writes aren't actually critical to interactions between threads, but the emulator has no way to guess which ones are important and which aren't, so it has to treat them all as if thread safety depends on it. Doing this in an emulator is expensive! It adds a lot to the count of Arm instructions executed per x86 instruction, and the extra instructions are relatively slow. For a while, Windows-on-Arm offered users the ability to tune emulator settings on a per-app basis to basically ignore this problem (risking bugs and crashes) in return for better performance. Worked great for applications that were completely single threaded, but not a great idea for anything with multiple threads. What did Apple do to address this? They added a custom mode bit to their Arm cores which enforces x86-style TSO memory ordering instead of the looser Arm ordering model. Whenever the macOS kernel starts running an x86 process, it shifts that CPU core into TSO mode. Hardware TSO support greatly reduces the overhead of emulating x86 in a completely thread-safe and correct way. The next piece is what kind of emulator Rosetta is. It actually supports two modes, JIT (just-in-time) and AOT (ahead-of-time). The JIT mode is a fallback to support self-modifying x86 code. In AOT mode, the first time you run an x86 binary, Rosetta completely recompiles it to Arm code, caches the results on disk, then launches the cached Arm binary. Subsequent runs skip the recompilation step and just launch the Arm-ified binary. As of a year or two ago, as far as I'm aware, neither of these pieces of technology were available in any WoA system - WoA's emulator was pure JIT (more runtime overhead), no WoA silicon implemented TSO, and even if it had done, Windows' x86 emulation didn't support it. I am not current on new events in this space, so some or all of that might have changed, or will in the future. (In particular, I expect Qualcomm's Oryon to support TSO - its CPU core was designed by a team lead by Gerard Williams, who was formerly employed by Apple and led the team that designed M1.) By the way, the AOT mode means there is a possible flaw in your benchmarking methodology. If you generate an x86 binary (whether by compilation or LIPO-ing a fat binary), that invalidates the AOT cache for that binary and the next launch will force Rosetta to re-translate it. This is a large amount of overhead and, depending on how you did your testing, could have skewed your numbers a lot. Rosetta users will normally experience one oddly slow program launch followed by excellent performance for months (basically, until either Rosetta self-invalidates the cache because Rosetta got updated and they want to re-translate, or the x86 program gets updated forcing a re-translation).
For someone who had an iBook 12" in 2004, a MBP 13" Retina thingy in 2007, a MBP 13" Retina thingy in 2013, and now a MBA 13" M2 thingy in 2023, all while switching from a PC laptop in 2004 due to Unix/Linux university requirements, and using Windows 7/10/11 via BootCamp or virtualization the whole time ... I'm just glad they get faster and more reliable while remaining dirt cheap by 90's standards. $0.02
Perhaps I'm just dumb, I'm not a developer, but isn't this test mostly semantics? Maybe Rosetta 2 isn't strictly emulation, but with the weird ARM stuff Apple uses with it, the end result for the user is a pretty seamless transition from the debut of Apple Silicon. I know personally, the reason I thought Windows on ARM was so bad was that the Surface Pro X got absulutely roasted on release for being nigh unusable with most x64 applications. It seems like, instead of being like "Well when you make the experience completely like for like, they're both as slow" the better option would be "Make sure Windows 12 or whatever release brings ARM mainstream pulls the same under the hood sleight of hand Rosetta 2 did, because the transition will be much slower and more complicated with the more fragmented Windows ecosystem, so any advantage they can get will be even more important."
8 месяцев назад+1
Probably the reason why people assume that Apple has better IntelToArm emulation is because those MacBooks running Intel were so underpowered, that the huge jump in performance just manifested in emulated apps running still much much better on Apple Silicon than they ever ran on Intel. So people assumed emulation is just so good.
Lovely videos as always! I really enjoy learning something new from @garyexplains Feature Request for future videos: please include more details and metrics about energy consumption and thermals/tdp. I feel this is missing from some of the metrics you typically cover in architecture vids and benchmarks. Moreover, would you be willing to add api benchmarks in future videos? Thank you! Long time fan 🙏🏽
Could it be that the code tested is IO/memory bottlenecked on the Windows device, and therefore the emulation penalty is irrelevant on Windows, but relevant on the MacOS device (because it has higher memory bandwidth and therefore CPU bottlenecked)?
@@GaryExplains OK. I can't see any new code specific to this video. In any case, I hope you're right, as I am Windows fan and jealous of Apple Silicon... but the first test result seems odd which is why I've come up with the memory bottleneck theory. Hopefully your test encourages other people to do similar testing, instead of assuming Rosetta is superior. 🤞
Thank you for the interesting video. Speed of the translated code is important, but even more important, I think, is accuracy of the translation. That is harder to check because it means running translated code of many complex programs to ensure that they are behaving properly and there are no errors. Adobe Lightroom Classic, Photoshop, Premiere Pro, Excel, games, etc. I suppose older pre-Apple Silicon versions can be found that are not fat universal binaries which could be used on Mac to try and get a true comparison of Apple Rosetta 2 translation to Windows translation.
The problem is emulation: Apple forced software companies to compile after some time all their software to ARM, so currently there is no problem with new apps. Microsoft cannot do that.
What I'm missing here is more technical detail on the character of your own test code. What kind of CPU load was it? Was it more arithmetic kind of computation? Did it access a lot of memory? Did it have complicated branching structure? Was it single-threaded or multi-threaded? Did it use x-86 extension instructions? How did the first run differ from the subsequent ones? Etc. It would be super interesting to see how different kinds of load behave in the emulation environment. In the HandBrake case, for example, you can see that the code is most probably heavily low-level optimized for the native architecture. Anyway, the point of your video - negligible difference between Mac and Win low-level emulation performance - seems to hold pretty well and that's great news. Let's see how Microsoft solves the end-user Win-on-Arm experience.
It's not that macOS does it better in terms of performance, it's a matter of reliability. I used Windows for ARM and had many bugs and failed app startups with x86 code, it just didn't work or crashed ever so often than Rosetta on macOS. Apple did it first and it was robust since day 1, Microsoft still needs some time to polish it up.
The Windows problems were not related to the underlying platform, but wit the stubborn wish to make us use that modern UI/windowsRT/whatever. If they compile everything, it will be Ok. It was in the past, there was NT for many platforms, Windows CE was compiled for many CPUs, I for once remember compiling for at least 5 different processors and I can't remember how many platforms with them (had about 30 targets), but there was no CPU transaltion in CE. Other thing to remember is that initially Windows NT was in then called "p"-code and everything was translated! And this was when having 32 megs of RAM required you to be quite a rich person. So, the history is long and Windows is in that game from the beginning, but today considering that many people call the front end UI an Operating System, the difference from decades ago is that everybody can talk and not only those who know what is actually inside the devices.
The main reason why Windows x64 emulation is worse than Mac is due to the fact that only on Windows are some applications not properly working or failing altogether due to the used Intel math library or R not producing the same results as under actual x64 chip. Point in case Python + Pandas or own source compiled against Intel Math library (fails when executing Intel library calls) or Intel versions of R fail or break at times when running in the x64 emu on Arm. The same can be found when using commercial products that rely on those libraries as well The speed, while important, doesn't matter as much as the quality of the emulation. Also, I'd actually argue that it is a better solution if your emulation can map system calls to native Arm libs rather than to x64 libs if it is transparent and results in faster speed. This is not cheating by Apple but by design and the superior solution: faster and less error-prone when you reduce the emulated code execution.
Alright this is really good to hear. I think the main difference now is the level of native support for Arm on Windows vs on Mac so that transaction layer is unfortunately going to be used much more frequently on Windows compared to MacOS. Since MacOS's primary architecture has been ARM in new PC's since M1 came out in 2020 compared to windows where it is much less. Microsoft quoted a piece of research by Counterpoint which stated that ARM laptop marketshare is 14% right now but that includes Apple. There is a Tom's Hardware news story from 2022 that said that Apple had 90% of the ARM pc market. From both of those reports I would generously estimate that Windows on Arm is 2% of PC marketshare which is something that Microsoft is going to have to put in a lot of effort to change and only then will most devs care enough to make ARM versions of their apps.
Hi Gary you should try to build and run the SPEC benchmark suite - it's the gold standard for measuring performance across a wide variety of workloads and I think it's not too hard to build and run
Gary just a simple question. Are you optimistic about where ARM is going on Windows? Do you think we can have a small and light alternative to the M type Macs. I want an powerful and efficient Windows laptop. I don't want to buy into the Apple eco- system as I prefer to use Windows and Android in PC and mobile.
Surprising. I remember when Windows on Snapdragon first became a thing the reviews showed AWFUL emulation. So is it that SoCs are way faster or did Microsoft make additional optimizations?
Thing is, the emulation never has been awful - but no-one, who was claiming that the emulation was awful, did really compare the emulated performance vs the native arm64 performance but compared the emulated performance vs the performance on a much faster Intel CPU.
A very good video Gary. Well done for all the testing and coding. Like you said, the general opinion on the internet for years has been that MacOS emulation is far better than windows and clearly this is not the case. 👍👍
This makes sense. Windows performance even as VM on Apple Sillicon is commendable. I don’t know why so much people lash out to Windows, when it’s clear that there hasn’t been ARM hardware up to the task for Windows… until now with the Snapdragon X. But the 8cx series has been a disaster, expensive and underperforming. Was meant to compete with Intel Y series, just as the M-series took off.
there are 2 things here: 1- windows’ problem is that it relies on other companies hardware and other ARM chip makers haven’t reached apple’s silicon in performance and efficiency on laptops. 2- as you said transition from x86 to arm was mostly seamless for mac but it will take years for developers to adopt native arm CPUs.
@@GaryExplains It’s close to M2 but still behind M3, and M3 is already released to the market while it probably takes a year or two before we see proper windows laptops with X elite and till then there may even be an M4! I’m not an apple fanboy and I don’t even use a mac. personally I like PCs much more but the truth is apple is a few years ahead of everybody else in the arm laptop and desktop computers market. they did fantastic job in transitioning their platform to much more efficient arm architecture.
@@GaryExplains And I think I said proper laptops, no? by the way the snapdragon itself compared it to M2 and on the same wattage it falls slightly short comparing to it. M3 computers are already in the market and x elite, an unreleased chip is already behind it! You are comparing a somewhat paper product to an already stablished platform in its third generation.
Thanks for the video. I’d be interested to know, how does Parallels run Windows 11 on Mac M2 or M3 processors with 16GB minimum, and how fast are Windows apps run that way. Both ARM and x86 Windows apps compared to native Windows ARM machine.
Does Rosetta 2 also use ARM code for other things than benchmarks when it is supposed to translate (without being fat version)? Which might also make it feel better than what it is. I have probably been trainted how poor the Windows ARM translation has been early on and it probably doesnt help the ARM processors for Windows hasn’t been as powerful as the M series. It is interesting whenever someone uses Windows on ARM Mac that x86 programs runs great which people have attributed to Rosetta 2 which might just be Windows own translation but because it got more powerful CPU it feels better than on a Windows ARM PC.
Would you be able to share the code you wrote and your benchmarking setup (i.e. number of runs, outliers, etc.)? Otherwise it's really hard to conclude anything definitive from "I wrote some mystery code and ran it myself, here are the results".
Nice vid, thanks, emulation learns, running subsequent identical emulations should improve benchmarking, can you run your x86 emulation a few times and then compare to the first time you ran it?
Would love some benchmarks on arm64ec on windows compared to full native and emulated. It disallows some vector and other registers, so I'm curious about the impact on performance
i don't care if one emulation is fast or slow, this emulation is most important for old software that assume old and slow hardware, and in that case what matters is that they work at all, and that they have less bugs
Did you even watch the video? How can current x86 software for Windows be considered as "old software that assume old and slow hardware"??? I am very confused.
@@GaryExplains i did watch the whole video. sure there are also current x86 software that do not assume old hardware, but i am not worried about them because both the software development side and the windows/mac side will make sure they run smoothly on arm. i am much more worried about the old software that will be neglected
@@GaryExplains I've subscribed to your channel, I respect your content but if you are going to say that most internet claims about apple's superior implementation are fake then we need some facts, we can't just rely on your words. It would be helpful if you could add descriptions with links to backup your claims so we all can see for ourselves.
A hypothetical ARM Steam Deck is a really interesting device, as it. either forces games to work or drives emulation performance forward to get them playable, similar to the advances in Linux compatibility we see through Steam OS right now. I could see them sticking with AMD for the GPU as that relationship seems strong. Maybe a future Samsung partnership would be what makes that happen, as they've already had mild success with RDNA+ARM SoCs.
What about docker running x86_64 images under Windows on arm64? I'd be interested to see if OSx is just using some binfmt tools to run alternative architectures, or if they'd done something to be able to use rosetta with them (being that all docker images normal people use are Linux based)
Interesting to see more arm64 content. Thanks! Have you had a look at ADLINK's Ampere Altra Developer Platform. Up to 128 arm64 CPUs in a convenient workstation format.
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Probably one of the most necessary videos for ARM enthusiasts.
I’m almost an only Mac User since 1989 and I’m very grateful for this impartial review. Videos like this are the only way we have to assure that Apple keeps on improving their hardware. The more companies compete, the better products we’ll all have. It’s a win-win for Windows, Apple, Linux and other systems users. I’ve been following you for years and will remain doing so.
As I remember, Rosetta 2 does some type of translation on the first run of an application. This takes a certain amount of time but is cached so the second run of any application will be faster than the first. This would be worth testing to see if affects your findings.
I imagine a lot of the skepticism of Windows' x86-64 emulation is a result of the slow processors that came on the first Windows-on-Arm laptops, which would make a task running twice as slow feel MUCH slower.
I would like to see the Linux version of this video. Linux on ARM has also risen over the last few years and emulation of X86 has been a part of that too. I wonder how well that works.
*Agreed*
For my setup literately the only program that needs to be translated is Steam. Everything else has a native arm build.
In every video, there is always a guy asking for results on linux 😂😂
@@broccoloodlewho doesn't like 🐧?
@@arthurpizzaI noticed 2 years ago on Docker Hub that there was only 1 image I wanted to run that didn't have an Arm version. Last time I checked a few months ago, that one had an Arm version too.
I think the real advantage, that was confused as "better emulation", is just that Apple CPUs have been so much faster than the ARM CPUs Qualcomm has been using on their SoCs. It doesn't matter if your emulation layer is just as fast if your CPU is half as fast.
I hope Oryon competes 1:1 against Apple and makes Windows on ARM a solid product.
Totally this! People who were claiming bad emulation performance under Windows did wrongly compare running the same code under emulation vs. much faster Intel CPU.
when first surface pro x was on the shelf, many applications cannot even use graphic unit of the qualcomm chip. and not to mention 64bit support came two years later? i don't know current situation, as there is almost no content about it, but microsoft made a terrible start on emulation front.
Apple CPUs implement Total Store Ordering, which is a feature of x64 and is about correctly handling memory accesses in multithreaded code. Without it, you need to generate slower ARM code that does store ordering manually.
Also, Apple CPUs have a setting that changes how some status flags work , so that they work more like x64 flags, and adds some flag-related instructions. This makes the code easier to convert and also faster.
I can't wait for ARM to take off on Windows. I'll definitely get an ARM Laptop, great battery life and decent performance is all I've always wanted on Windows.
I hope Microsoft encourages enough developers to port their apps over soon 😁😄
Also, hoping to see powerful mini PCs
You have hit the nail on the head. Apple didn't give developers a choice, it was "Go ARM, or go home." All new hardware is Apple Silicon, and Apple was pushing developers towards compatibility (and immediate cross-compilation) via deprecations of various things (64-bit only, no 64-bit Carbon, etc.) for years _before_ Apple Silicon was even announced.
For Windows, the vast majority of devices being shipped today - like, 95+% - is still x86-based. Where's the incentive to developers to make ARM-based versions of their apps available? It doesn't exist. If the process is not "check a box, compile, ship" easy, they're not going to do it. Not for years.
Just do what I did and pick up a Dell Inspiron with Snapdragon ARM processor for ~$280. Black Friday sale.
@@edwarddodge7937 how good is the performance?
@@MichaelAlderete I don't find the x86 instruction set useless. I don't mind owning an x86 desktop as long as I'm getting that top notch performance. I just need that efficiency of ARM for laptops and small form factor PCs.
There has to be a way for Windows to convince developers to port over without trying to get rid of x86. I think both of them can coexist side-by-side.
Thanks for clearing up the misconceptions.
Glad it was helpful!
One of the claims Apple made about their emulation approach was that it would improve over time. The first time it translated X86_64 code it would be slow, but the second time it would be much faster. Can you think of a way to test this?
The understanding I have of how this worked, is that the translated code would be stored, and re-used the next time it was needed.
Im pretty sure they where talking about getting better with every update, not "on the fly improvement"
@@JxcksonSF The way it was explained: “If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process. When translation finishes, the system launches the translated executable in place of the original. However, the translation process takes time, so users might perceive that translated apps launch or run more slowly at times,”
So, every component that is translated is saved as an Apple Silicon native executable.
This seems like a relatively simple Just-Ahead-of-Time-like optimization that doesn't suffer from any big obstacles. This is already a super common idea in other corners of the tech landscape e.g., installing apps on Android, the Julia programming language, and so on. Considering windowsy things like powershell or dotnet already do optimizations like this, this is probably already planned / implemented.
The end-user experience is what matters. I’ve rooted for the Surface Pro X since its arrival. But the performance has been slower and software has been limited. While the back-end experience might be similar, the results in everyday use have been not. Snapdragon’s new chip has raised hopes once again (particularly when you see who created the new tech). But let’s see if the hardware will give us similar performance that we see on a M1 MBA.
It would be a lot better if u have used latest insider build on windows 11 as some emulation improvements have been made there.
I bet it would perform worse if i know microsoft even a little
Do you recommend to use the insider builds? I'm currently using pro 9 sq3
@@hanspeter9592 I'm using insider builds in my main x64 pc. All my arm PCs dual boot insider and stable.
@@hanspeter9592 I liked being an insider, never noticed any degradation in performance, and at times noticed nice bump,
I'm not on supported 11 hardware and 11 ran faster, but I had to go back to 10 when I sent the laptop in for accident insurance repair.
Make sure you get constant images, especially of the build before you begin, after a short while insider deletes your on drive roll back image.
In other words, of course, keep current images and a permanent image of the build before insider
End of the day it depends on user preference. But love to see linux running on proper ARM platforms... that will just be amazing!
I've been using it a lot for the Raspberry Pi 5, and the support has been impeccable. I haven't run into any software that didn't have an ARM build available
@@1funnygame I did my Engineering final project on Raspberry Pi 4b and was truly amazed by it's capabilities. It even ran a full CNN model i did for my project, although I was a little annoyed by Pi team updating the Pi Camera libraries and it took me some time to figure out the new functions and how to use them.
I also did a few tests with box64 - the most popular Linux solution for x86-64 emulation for arm64. In all my test box64 was quite a bit slower than both Windows and MacOS provided emulation.
I wonder if we could install windows arm version on androids in future? Currently we can run box64 and other windows emulators already.
@@Silent.killer_007 There are already some projects that do that to some phones. I can't think of which off the top of my head, but I very strongly remember seeing some older Snapdragon phones getting WOA ported to them through software wizardry beyond my comprehension.
I would prefer comparison with fex-emu also as it also has 32 bit emulation built in instead of separated solutions.
I really like to see the application you wrote for the test. Window is heavily using dll’s even for standard c library functions. So how sure are you that it didn’t use arm based code on windows?
That is great insight and really good journalism Gary. Really waiting to use new fanless ARM laptops in 2024.
Fantastic video Gary! Very clearly explains your methodology and clearly shows the results.
Awesome!
Glad you enjoyed it
Now do linux vs win vs Mac arm emulation comparison for us 3% linux users.
Tempting! 😀 But if this video get 10,000 views then I don't think it is really worth me making another video for an additional 300 views! 😛
@@GaryExplainsis youtube your sole income source now?
Not a Linux user here, but definitely interested in the "vs Linux" part/video if it ever comes.
Very timely. Just upgrading from i9 to M3 and I’m having quite a bit of architecture anxiety.
The slaves making your apple parts in China are having a different kind of anxiety.
@@shadmansudipto7287 there isn't much difference on the pc side either you know.
You won’t be disappointed. Apple silicon smokes Intel
@@shadmansudipto7287turn on your front facing camera on the Chinese device you’re holding and take a good look at yourself.
@@SunsetNovaIntel 14th gen is faster and when comparing against Nvidia GPUs it is not even a fair game.
Additionally Apple Silicon cannot be upgraded, your only advantage is on power consumption which provides impressive battery life but that's it mate.
Most people comments about microsoft x86 emulation might from before volterra, it was a mess at the beginning compared to apple, but it not only improve but also show us what can be done.
Wanna see what X elite can do, hopefully the game emulation scene can get as mature as apple's one is now.
Game emulation seems to pretty good on linux from that switch linux video by geekerwan, switch runs gow lol
Lovely, hope you do a an energy efficiency comparison between apple's m3 vs snapdragon x elite.
The “not actually emulating x86” revelation is major, and the new Snapdragon chip is a critically important recent update to consider surrounding this topic.
Thanks for getting the hard numbers on this. I think because I ARM translation got off on a rocky start on Windows, it got a bad reputation. For example, a client of mine had all kinds of issues running x64 code on their Surface Pro years ago. Mostly it was just lack of compatibility, but those were early days. I think because Apple comes out the door 100% working, and has a very good hypenmarketing system, there's just a complete different perception in the two companies. Now, I'm watching this 6 months later, and Microsoft just announced a whole bunch of new ARM "Copilot" computers, two he translation and compatibility is probably even better now, or at least fully matured.
I love to know more about the absolute amounts of time taken to convert the same video source on both platforms in native and emulated modes
I can see the need for such comparison but I think there has been enough benchmarking of the M1 vs other Arm laptop processors. Doesn't add much at this point. Also for video encoding the test should include whatever hardware acceleration is available. When the Snapdragon X Elite is out then this will certainly need revisiting.
It may be that the Windows emulation has improved over time. IIRC when the Surface X came out, benchmarks showed that emulated software performed much worse vs native. Then when the M1 Macbooks first came out, reviews were showing much better emulation performance vs. Windows. It also could have been the issue you mentioned where MacOS still runs apps with the Arm library, although it was so early in the Apple silicon lifespan that I'm not sure if the apps had a fat version at the time. I don't remember all of the reviews I watched covering both, but I remember LTT being one of them.
True, i also remember something like this, but the problem here is that it was 3 years ago, and people still use that as excuse, but it seems the Windows 11 inside emulator is better like the individualy installed versions in Windows 10 (so when the M1 released). Good to see even Windows are serious about ARM.
@@TamasKiss-yk4st Well to be fair, Microsoft hasn't really made any splash about Windows on ARM, so people probably assumed it was dead or not a priority. We're probably going to see that change once devices with the new Qualcomm chips launch and Microsoft has some sort of event.
@@jeevana.6391 they haven’t since 2012 that’s 12 years ago
Looks good.... looking forward to when I can buy a proper ARM-based PC! Hopefully sometime next year..
it's here now :)
Next year was right :D
@@aiSage48 I'm still interested in how well these ARM based PCs will run x86/x64 based s/w compared to native 14700K...
FINALLY! A REAL comparison.
Thank you!
This one of the best non bias video. Thanks for always making these brilliant video. Still love my M2 Mac 😊
This makes a lot of sense if one think about the incentives.
Apple wants the devs to quickly port apps over to Arm, so they only care that x86 just works and don't care too much about speed.
Microsoft knows that a lot of devs will never port to Arm, hence they need to optimize better.
I recall Adobe announcing arm. Development of their suite back before apples switched to m1. I was mainly excited because of the possibility of the native version being rewritten and ported to the iPad but given this. Knowledge I’m excited to see when a surface book ships with a snapdragon elite
Windows just did not have competitive ARM hardware to run on compared to Apple silicone so people just assumed it ran poorly when the reality is it was running on much weaker hardware.
Should be interesting to see how Windows & x86 emulation on Snapdragon Elite will perform in real life now that it's on a comparable platform to the M series.
Can you please test fedora or ubuntu on it? I wonder if we can finally have some good arm hardware to run linux on
Note that Microsoft has officially cancelled support for Windows 10 on ARM. So there is only Windows 11 on ARM. It lives happily within a Parallels Desktop VM on my Mac mini and receives all patches and function upgrades including the recently released 23H2.
I bet the claims of Rosetta 2 being the better "emulation" stems from Windows 10 on ARM which had x86 emulation only and it was a real emulation, whereas Rosetta 2 uses JIT compilation of x64 code to ARM. Windows introduced JIT along with the x64-Support in Windows 11 on ARM. On Windows 11 on ARM, JIT compilation is only available for x64-Code (as it is in Rosetta 2 as there is no longer support for x86-Code in macOS for years now).
This was really useful. Thanks for taking the time to share the stats.
It’s impressive it works at all. It’s nice to have options, though it’s slow enough if wasn’t viable for our use case. Half the speed meant wasting a heap of developer time waiting for tests to run.
We wanted to keep it simple when our business transitioned to ARM a few years ago. We aligned our hardware refresh cycles and deployment planning to do it in one step. We adopted ARM workstations and moved our production load to AWS Graviton processes on the same day. In the end it was as simple as changing a flag in a docker build command and changing a setting on AWS.
Roughly speaking, it’s working out about 40% cheaper than x86 was. The monthly AWS savings paid off the new workstation costs in under a year.
The only x86 processor in my life is the one in my gaming PC.
Thanks for the comparison, it's really interesting to see how far emulation has come now that Microsoft is releasing consumer hardware with the Snapdragon Elite chips.
Another thing to test is compatibility. You can refer to the lists of most used PC software and test them on both platforms to see how well they run.
Except obviously they are different on each platform, so other than the name i.e Microsoft Word, there is little commonality between the actual code running.
@@GaryExplains and I think many people want to know how smooth or buggy they are. It's useless if it runs everything fast but crashes every 10 seconds.
Now I just imagined implications of Apple selling arm64 CPU in the wild to Windows hardware vendors... crazy idea, maybe I've been drinking too much coffee today... Gary, great review and explanations again, thanks!
Interesting topic. My guess as to why people have not responded with the facts that macOS on ARM performing better than Windows on ARM is because its not about the quantity and benchmarks, but the behaviour and experiences of how well the apps run on those platforms. So it's things like the number of apps that are supported, how well they run, signs of slow downs, glitches, etc that are harder to quantify (unless we conduct surveys with users).
So making use of ARM libraries when available is a good optimisation technique, thus providing better experiences. But there are limitations, such as the lack of nested virtualisation if you're running VMs.
Maybe, but nobody replied with talk of those things either. The actual reason is that someone probably said it wasn't good in some review on a popular website and everyone just believed it and continue to regurgitate the same stuff without actually verifying if it is true or not. This phenomena doesn't only apply to this subject but many. I am kind of acting as a myth buster in that sense.
Additionally, didn't AppleSilicon have hardware to assist with x86-64 emulation? It was something to do with memory, but do pardon. My memory is hazy since I'd read about it when M1 initially launched with Rosetta!
@@GaryExplains Thanks Gary. Appreciate what you've done here. Granted I don't have evidence to suggest this, but it just feels that Apple's has done a really good job in implementing and providing developer support for ARM. I guess the years of experience the've had with iOS contributes to this.
My experience with desktop Linux on ARM (via Parallels and Raspberry Pi) is quite good but rather limited (e.g. Linux Mint is not being available for ARM, some tools and libraries not available).
As for Windows, I can only test this on Parallels (so I can't test WSL), but I'm surprised that some games on Steam runs well (like Dying Light).
That said, I often can't help resorting to x86 when running desktop Linux and Windows for the better experience.
@@shahnawazshahin3781yes that is correct. The memory does assist in a way as the memory in apple silicon devices is laid out and designed the way x86 based systems memory is. As apparently ARM based systems use a different memory design. So apple gets the best of both worlds by using an ARM processor but having memory built the x86 way. This means it's likely impossible to get ARM windows on an ARM based MAC. The processor is correct but that OS would not be designed for how apple is doing the memory in the system. Apple does it this way for the best of both worlds I guess. But it's all a custom build.
very interesting subject indeed and in the right time too, very clever and informative approach, big fan 💚💚.. thank you
Glad you enjoyed it!
This is what I've been holding out for. I'm going to wait another generation and probably pull the trigger on a system with one of these Snapdragon chips. I'm also very interested to see what x64 emulation on Linux is like.
Great video! Much needed proof to dismiss hype.
You can sometimes fool most of the people, and some of the people most of the time, but you can't fool Gary - he rolls his own tests and _measures_ ! 😀
Very cool and great to know👍
So why Apple silicon always wins against Windows ARM PC? Better chip & code optimization?
Or is it because till now, with the X-Elite chip released Windows never had similar high performance ARM chip like that comparable to the Apple’s Mx family?
That's why Qualcomm bought Nuvia.
@@PJSOFT Nuvia (ex Apple chief chip designers) was developing custom Arm server cores which Qualcomm adopted after their acquisition and is targeting for the Windows PCs. This is why their cores in comparison to Apple cores run with higher wattage and lower efficiency (efficiency cores r also missing on the X-Elite chips).
What Apple does incredibly well is their ULTRA efficiency on both HW & SW side where both of these worlds r amazingly well connected and optimized. U can say that Apple's HW architecture (not just cores or chips) is designed specifically for the SW to run faster and more efficiently.
This "only Apple" advantage gives Apple incredible control=power and always better performance per watt in comparison to X-Elite and any other Arm based SoC with of course almost endless budget to afford latest and most advanced chip manufacturing/packaging/interconnect processes.
@@D.u.d.e.r You should have replied to your own comment, so I didn't have to.
Another thing, it’s the same name (Rosetta) but it’s not the same technology in either, it’s just emulation tailored to the OSs and type of binaries.
Thanks you. This answers my phobia of Arm transition
Rosetta also has access to intel memory extensions that apple built into m series SoC. This improved the performance a lot.
I'm really impressed, thanks for the video
Glad you liked it!
As someone who prefers Apple (wont call myself a fan boy, but know people will call me a fan boy), the reality is that up until now (with the release of the snapdragon X elite) Windows didnt have a ARM based chip that was comparable to the Apple chips (meaning that the previous ARM chip that the Surface used wasnt as good as Apple Sillicon), therefore in real world use you will always have the experience the Apple emulation of x86 to be better than Windows.
I think it is only now that it can be possible to really compare the two.
I do think that because Apple has moved away from x86 machines as a whole forcing developers to create native versions, that Apple will will be beter than Windows on ARM (as great as the SD X Elite is I dont think that it is enough to get developers to create native ARM versions and therefore will always have to emulate programs and as mentioned in the video native is always better than emulation
Great video, Gary and your methodology is spot on. What important is that it is not your opinions or based on hearsays (what he said, she said). Anyway, it is good to know (and expected at least to me) that the emulators performance are almost similar on Windows and MacOS. Ultimately, these emulators won't be needed some years later down the line because nothing beats native code.
It is interesting to speculate that perhpas in the future there will be split between ARM64 for mobile computing and x86_64 for desktop with regards to Windows. I don't think that x86_64, Intel, AMD will disappear into the ethos very soon.
One has to write x86 code to specifically use instruction set like SSE2 , Larger virtual address space, various types of modes. This should be job of linker and complier, which if not configured, would default to most optimised binary.
You have to test also battery duration, it is an important point, if a bought an ARM laptop that would be to get more portability.
The new Windows emulator with X SoCs actually has a name. It's talk Prism.
What I'd love to know, is how good Linux support will be on the new Snapdragon X Elite Laptops. I know native software support is actually pretty great, thanks to both RaspberryPi & Neoverse servers. But I heard from current Windows Snapdragon device owners, that boot & driver support for installing Linux has been fairly bad for the most part. Hope that changes, if it hasn't already. I'd love to have a Snapdragon X Elite Linux Developer Laptop.
Great video! Thank you. Thanks for doing an actual test of the myth. Your results were very interesting.
Thanks Gary, that's exactly what I expect to see on youtube. When someone states something, it should be backed up by some tests.
But there are still some kinds of things I don't understand well. There are different instructions, some may be better emulated on one platform, some on the other. It would be nice to see that in detail. It would help to understand the difference in results between your code and HandBrake.
Another interesting topic is gaming. Windows games rely heavily on DirectX and windows PCs GPUs have hardware optimized for it. What about Qualcomm vs Apple in that regard? Can we expect AAA arm games anytime soon? If you know anything about it, please, let us know.
Eye opening, keep up the good work, Gary! 👌🏻
One thing I will say is that even if the emulation is just as good in either, developers will go to arm quicker on macOS due to it being a forced step forward, whereas windows isn’t as straightforward, but it’s good to see windows on arm
Gary, I'm sorry, but this is a terrible explainer. Apple does have a real technology advantage in this area against Windows on Arm. (Or at least they did as of a year or two ago.)
The first part of it is memory ordering. Loosely speaking, this refers to the order in which an observing CPU core sees memory writes generated by other processor cores. x86 implements an ordering model called TSO, in which all writes are observed strictly in program order. Arm has a weaker model which permits some reordering - the writer might think it wrote thing #1 followed by thing #2, but an observer could see write #2 before #1. The practical implications of this are that (a) Arm processors can gain performance thanks to the extra reordering possibilities but (b) programs written for Arm may need more explicit thread synchronization when two threads interact.
What does that have to do with emulation? Well, if your Arm processor takes full advantage of the reordering possibilities permitted by the Arm spec, every emulated x86 memory write will need to be treated as a thread synchronization point. Most memory writes aren't actually critical to interactions between threads, but the emulator has no way to guess which ones are important and which aren't, so it has to treat them all as if thread safety depends on it. Doing this in an emulator is expensive! It adds a lot to the count of Arm instructions executed per x86 instruction, and the extra instructions are relatively slow. For a while, Windows-on-Arm offered users the ability to tune emulator settings on a per-app basis to basically ignore this problem (risking bugs and crashes) in return for better performance. Worked great for applications that were completely single threaded, but not a great idea for anything with multiple threads.
What did Apple do to address this? They added a custom mode bit to their Arm cores which enforces x86-style TSO memory ordering instead of the looser Arm ordering model. Whenever the macOS kernel starts running an x86 process, it shifts that CPU core into TSO mode. Hardware TSO support greatly reduces the overhead of emulating x86 in a completely thread-safe and correct way.
The next piece is what kind of emulator Rosetta is. It actually supports two modes, JIT (just-in-time) and AOT (ahead-of-time). The JIT mode is a fallback to support self-modifying x86 code. In AOT mode, the first time you run an x86 binary, Rosetta completely recompiles it to Arm code, caches the results on disk, then launches the cached Arm binary. Subsequent runs skip the recompilation step and just launch the Arm-ified binary.
As of a year or two ago, as far as I'm aware, neither of these pieces of technology were available in any WoA system - WoA's emulator was pure JIT (more runtime overhead), no WoA silicon implemented TSO, and even if it had done, Windows' x86 emulation didn't support it. I am not current on new events in this space, so some or all of that might have changed, or will in the future. (In particular, I expect Qualcomm's Oryon to support TSO - its CPU core was designed by a team lead by Gerard Williams, who was formerly employed by Apple and led the team that designed M1.)
By the way, the AOT mode means there is a possible flaw in your benchmarking methodology. If you generate an x86 binary (whether by compilation or LIPO-ing a fat binary), that invalidates the AOT cache for that binary and the next launch will force Rosetta to re-translate it. This is a large amount of overhead and, depending on how you did your testing, could have skewed your numbers a lot. Rosetta users will normally experience one oddly slow program launch followed by excellent performance for months (basically, until either Rosetta self-invalidates the cache because Rosetta got updated and they want to re-translate, or the x86 program gets updated forcing a re-translation).
Very excited for x elite laptops.... Gona be awesome. I was going to get a new laptop but I'll wait till the ARM one comes out
i love watching your videos , keep going U R the best
For someone who had an iBook 12" in 2004, a MBP 13" Retina thingy in 2007, a MBP 13" Retina thingy in 2013, and now a MBA 13" M2 thingy in 2023, all while switching from a PC laptop in 2004 due to Unix/Linux university requirements, and using Windows 7/10/11 via BootCamp or virtualization the whole time ... I'm just glad they get faster and more reliable while remaining dirt cheap by 90's standards. $0.02
Perhaps I'm just dumb, I'm not a developer, but isn't this test mostly semantics?
Maybe Rosetta 2 isn't strictly emulation, but with the weird ARM stuff Apple uses with it, the end result for the user is a pretty seamless transition from the debut of Apple Silicon.
I know personally, the reason I thought Windows on ARM was so bad was that the Surface Pro X got absulutely roasted on release for being nigh unusable with most x64 applications.
It seems like, instead of being like "Well when you make the experience completely like for like, they're both as slow" the better option would be "Make sure Windows 12 or whatever release brings ARM mainstream pulls the same under the hood sleight of hand Rosetta 2 did, because the transition will be much slower and more complicated with the more fragmented Windows ecosystem, so any advantage they can get will be even more important."
Probably the reason why people assume that Apple has better IntelToArm emulation is because those MacBooks running Intel were so underpowered, that the huge jump in performance just manifested in emulated apps running still much much better on Apple Silicon than they ever ran on Intel. So people assumed emulation is just so good.
Lovely videos as always! I really enjoy learning something new from @garyexplains Feature Request for future videos: please include more details and metrics about energy consumption and thermals/tdp. I feel this is missing from some of the metrics you typically cover in architecture vids and benchmarks. Moreover, would you be willing to add api benchmarks in future videos? Thank you! Long time fan 🙏🏽
Could it be that the code tested is IO/memory bottlenecked on the Windows device, and therefore the emulation penalty is irrelevant on Windows, but relevant on the MacOS device (because it has higher memory bandwidth and therefore CPU bottlenecked)?
My code isn't io based. And I doubt handbrake can create data faster than the SSD can write it.
@@GaryExplains Are you happy to share your code? It doesn't access memory at all?
Doesn't have to be I/O in the sense of networking or SSD. I'm thinking memory bandwidth
Most of my code is in GitHub, just pick any of my tests and try for yourself. Handbrake is of course at its official website.
@@GaryExplains OK. I can't see any new code specific to this video. In any case, I hope you're right, as I am Windows fan and jealous of Apple Silicon... but the first test result seems odd which is why I've come up with the memory bottleneck theory. Hopefully your test encourages other people to do similar testing, instead of assuming Rosetta is superior. 🤞
Thanks for this video. There are many speculations on the street.
Has been impatiently waiting for the new Windows Arm machines.
Thank you for the interesting video. Speed of the translated code is important, but even more important, I think, is accuracy of the translation. That is harder to check because it means running translated code of many complex programs to ensure that they are behaving properly and there are no errors. Adobe Lightroom Classic, Photoshop, Premiere Pro, Excel, games, etc. I suppose older pre-Apple Silicon versions can be found that are not fat universal binaries which could be used on Mac to try and get a true comparison of Apple Rosetta 2 translation to Windows translation.
Guys can you share his channel as much as possible..he really deserves many more subscribers
The problem is emulation: Apple forced software companies to compile after some time all their software to ARM, so currently there is no problem with new apps. Microsoft cannot do that.
What I'm missing here is more technical detail on the character of your own test code. What kind of CPU load was it? Was it more arithmetic kind of computation? Did it access a lot of memory? Did it have complicated branching structure? Was it single-threaded or multi-threaded? Did it use x-86 extension instructions? How did the first run differ from the subsequent ones? Etc. It would be super interesting to see how different kinds of load behave in the emulation environment.
In the HandBrake case, for example, you can see that the code is most probably heavily low-level optimized for the native architecture.
Anyway, the point of your video - negligible difference between Mac and Win low-level emulation performance - seems to hold pretty well and that's great news. Let's see how Microsoft solves the end-user Win-on-Arm experience.
It's not that macOS does it better in terms of performance, it's a matter of reliability. I used Windows for ARM and had many bugs and failed app startups with x86 code, it just didn't work or crashed ever so often than Rosetta on macOS. Apple did it first and it was robust since day 1, Microsoft still needs some time to polish it up.
Have you tried it recently?
The Windows problems were not related to the underlying platform, but wit the stubborn wish to make us use that modern UI/windowsRT/whatever. If they compile everything, it will be Ok. It was in the past, there was NT for many platforms, Windows CE was compiled for many CPUs, I for once remember compiling for at least 5 different processors and I can't remember how many platforms with them (had about 30 targets), but there was no CPU transaltion in CE. Other thing to remember is that initially Windows NT was in then called "p"-code and everything was translated! And this was when having 32 megs of RAM required you to be quite a rich person. So, the history is long and Windows is in that game from the beginning, but today considering that many people call the front end UI an Operating System, the difference from decades ago is that everybody can talk and not only those who know what is actually inside the devices.
The main reason why Windows x64 emulation is worse than Mac is due to the fact that only on Windows are some applications not properly working or failing altogether due to the used Intel math library or R not producing the same results as under actual x64 chip. Point in case Python + Pandas or own source compiled against Intel Math library (fails when executing Intel library calls) or Intel versions of R fail or break at times when running in the x64 emu on Arm. The same can be found when using commercial products that rely on those libraries as well
The speed, while important, doesn't matter as much as the quality of the emulation. Also, I'd actually argue that it is a better solution if your emulation can map system calls to native Arm libs rather than to x64 libs if it is transparent and results in faster speed. This is not cheating by Apple but by design and the superior solution: faster and less error-prone when you reduce the emulated code execution.
Alright this is really good to hear. I think the main difference now is the level of native support for Arm on Windows vs on Mac so that transaction layer is unfortunately going to be used much more frequently on Windows compared to MacOS. Since MacOS's primary architecture has been ARM in new PC's since M1 came out in 2020 compared to windows where it is much less. Microsoft quoted a piece of research by Counterpoint which stated that ARM laptop marketshare is 14% right now but that includes Apple. There is a Tom's Hardware news story from 2022 that said that Apple had 90% of the ARM pc market. From both of those reports I would generously estimate that Windows on Arm is 2% of PC marketshare which is something that Microsoft is going to have to put in a lot of effort to change and only then will most devs care enough to make ARM versions of their apps.
Hi Gary you should try to build and run the SPEC benchmark suite - it's the gold standard for measuring performance across a wide variety of workloads and I think it's not too hard to build and run
If you have the $1000 I need to buy SPEC then sure I will do that 😜
Gary just a simple question. Are you optimistic about where ARM is going on Windows? Do you think we can have a small and light alternative to the M type Macs. I want an powerful and efficient Windows laptop. I don't want to buy into the Apple eco- system as I prefer to use Windows and Android in PC and mobile.
Surprising. I remember when Windows on Snapdragon first became a thing the reviews showed AWFUL emulation. So is it that SoCs are way faster or did Microsoft make additional optimizations?
Thing is, the emulation never has been awful - but no-one, who was claiming that the emulation was awful, did really compare the emulated performance vs the native arm64 performance but compared the emulated performance vs the performance on a much faster Intel CPU.
Great comparison, How does QEMU compare to Rosetta and the windows emulator?
Now I want a laptop on Snapdragon X Elite.
Gary, when do you think i will be able to install microsoft visual studio in my galaxy phone? I really looking forward to that moment
A very good video Gary. Well done for all the testing and coding. Like you said, the general opinion on the internet for years has been that MacOS emulation is far better than windows and clearly this is not the case. 👍👍
This makes sense. Windows performance even as VM on Apple Sillicon is commendable. I don’t know why so much people lash out to Windows, when it’s clear that there hasn’t been ARM hardware up to the task for Windows… until now with the Snapdragon X. But the 8cx series has been a disaster, expensive and underperforming. Was meant to compete with Intel Y series, just as the M-series took off.
I just noticed recently that windows arm update brings significant x86/x64 emulation performance improvement!
there are 2 things here:
1- windows’ problem is that it relies on other companies hardware and other ARM chip makers haven’t reached apple’s silicon in performance and efficiency on laptops.
2- as you said transition from x86 to arm was mostly seamless for mac but it will take years for developers to adopt native arm CPUs.
"ARM chip makers haven’t reached apple’s silicon in performance and efficiency on laptops" -> Snapdragon X Elite.
@@GaryExplains It’s close to M2 but still behind M3, and M3 is already released to the market while it probably takes a year or two before we see proper windows laptops with X elite and till then there may even be an M4! I’m not an apple fanboy and I don’t even use a mac. personally I like PCs much more but the truth is apple is a few years ahead of everybody else in the arm laptop and desktop computers market. they did fantastic job in transitioning their platform to much more efficient arm architecture.
6 months until laptops with X Elite. I have several videos on the performance. I think I said in this video that it was behind the M3, no?
@@GaryExplains And I think I said proper laptops, no? by the way the snapdragon itself compared it to M2 and on the same wattage it falls slightly short comparing to it. M3 computers are already in the market and x elite, an unreleased chip is already behind it! You are comparing a somewhat paper product to an already stablished platform in its third generation.
Amazing tests Gary
Thanks for the video. I’d be interested to know, how does Parallels run Windows 11 on Mac M2 or M3 processors with 16GB minimum, and how fast are Windows apps run that way. Both ARM and x86 Windows apps compared to native Windows ARM machine.
No Linux comparison? FEX and box64 seem to be pretty good
Yeah, I would like to see a comparison between those two on Linux as well. It would be very interesting.
Does Rosetta 2 also use ARM code for other things than benchmarks when it is supposed to translate (without being fat version)? Which might also make it feel better than what it is.
I have probably been trainted how poor the Windows ARM translation has been early on and it probably doesnt help the ARM processors for Windows hasn’t been as powerful as the M series.
It is interesting whenever someone uses Windows on ARM Mac that x86 programs runs great which people have attributed to Rosetta 2 which might just be Windows own translation but because it got more powerful CPU it feels better than on a Windows ARM PC.
Would you be able to share the code you wrote and your benchmarking setup (i.e. number of runs, outliers, etc.)? Otherwise it's really hard to conclude anything definitive from "I wrote some mystery code and ran it myself, here are the results".
All my benchmarks are in my GitHub repo, pick one and give it a try 👍
Nice vid, thanks, emulation learns, running subsequent identical emulations should improve benchmarking, can you run your x86 emulation a few times and then compare to the first time you ran it?
Would love some benchmarks on arm64ec on windows compared to full native and emulated. It disallows some vector and other registers, so I'm curious about the impact on performance
i don't care if one emulation is fast or slow, this emulation is most important for old software that assume old and slow hardware, and in that case what matters is that they work at all, and that they have less bugs
Did you even watch the video? How can current x86 software for Windows be considered as "old software that assume old and slow hardware"??? I am very confused.
@@GaryExplains i did watch the whole video. sure there are also current x86 software that do not assume old hardware, but i am not worried about them because both the software development side and the windows/mac side will make sure they run smoothly on arm. i am much more worried about the old software that will be neglected
Good point. That will be interesting to test out!
Now people will say you wrote the code wrong!
For sure!
now without the code we can't be sure, can we?
Wow @gag_singh are you going to reply with that comment everywhere?
@@GaryExplains I've subscribed to your channel, I respect your content but if you are going to say that most internet claims about apple's superior implementation are fake then we need some facts, we can't just rely on your words.
It would be helpful if you could add descriptions with links to backup your claims so we all can see for ourselves.
@@gag_singhI don't think you need me to post a link for you to find HandBrake do you?
Fascinating! It was definitely true when the M1 released. I'm really happy to see it's good now
Makes me think we could get an ARM based Steam Deck one day! One day the scales may tip to ARM and that's where the all the focus will be.
A hypothetical ARM Steam Deck is a really interesting device, as it. either forces games to work or drives emulation performance forward to get them playable, similar to the advances in Linux compatibility we see through Steam OS right now. I could see them sticking with AMD for the GPU as that relationship seems strong. Maybe a future Samsung partnership would be what makes that happen, as they've already had mild success with RDNA+ARM SoCs.
What about docker running x86_64 images under Windows on arm64? I'd be interested to see if OSx is just using some binfmt tools to run alternative architectures, or if they'd done something to be able to use rosetta with them (being that all docker images normal people use are Linux based)
What the testing code does? That may affect the results. Do they use SIMD operations (SSE/NEON)?
Impressive testing
Thanks
Interesting to see more arm64 content. Thanks! Have you had a look at ADLINK's Ampere Altra Developer Platform. Up to 128 arm64 CPUs in a convenient workstation format.
I have seen it, yes
Do you know what kind of memory will be with Snapdragon X? Thank you for your reviews, you are a breath of fresh air in the world of hype!
Can’t wait to see how the snapdragon surface handles emulation. Might switch from my iPad lol