Live data from Hacker News

Snapdragon X2 Elite ARM Laptop CPU

qualcomm.com

201–210 of 223 posts

Re: Snapdragon X2 Elite ARM Laptop CPU

#201

Earlier quoted context omitted.

> People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed This is a misinterpretation of what the author wrote! There is a real and significant performance impact in emulating x86 TSO semantics on non-TSO hardware. What the author argues is that enabling TSO process-wide (like macOS does with Rosetta) resolves this impact but it carries counteracting overhead in non-emulat…

How is it a misinterpretation? To re-quote that last sentence: > In my opinion, TSO is a red herring that isn't really improving performance, but it sounds nice on paper. That's the author directly saying that TSO isn't the major emulation performance gain that people think it is. You're correct that there are countering effects between TSO's benefits to the emulated code vs. the negative effects on the emulator and…

> How is it a misinterpretation? To re-quote that last sentence:

I think we agree in our understanding, but condensing it down to "TSO isn't as much of a deal as claimed" is misleading:

* Efficient TSO emulation is crucial (both on Windows and elsewhere)

* The blog claims hardware TSO is non-ideal on Windows only (because Microsoft adapted the ecosystem to facilitate software-based TSO emulation). (Even then, it's unclear if the author quantified the concrete impact)

* Hardware TSO is still of tremendous value on systems that don't have ecosystem support

> [volatile metadata] doesn't help executables compiled with non-MSVC compilers like Clang, nor any JIT code, nor is there any documentation indicating how to support either of these cases.

That's funny, I hadn't considered third party compilers. Those applications would still benefit from ARM64EC (i.e. native system libraries), but the actual application code would be affected quite badly by the TSO impact then, depending on how good their fallback heuristics are. (Same for older titles that were compiled before volatile metadata was added)

Re: Snapdragon X2 Elite ARM Laptop CPU

#202
post #66

Earlier quoted context omitted.

For one thing Apple dropped 32-bit before they transitioned to ARM while Windows compatibility goes back 30 years.

Actually, the Macho file format was multiarch by design (On Windows we're still stuck with Program Files (x86)).. Anyway, before dropping 32bit, they've dropped PowerPC. Another consideration, Apple is the king of dylib, you're usually dynamically linking to the OS frameworks/libs. so they can actually plan their glue smarter so the frameworks would still work in native arch. (that was really important with PPC->Inte…

You also get "Program Files (ARM)" (including a complementary "SysArm32") on older arm64 systems too.

Re: Snapdragon X2 Elite ARM Laptop CPU

#204
post #72

Earlier quoted context omitted.

For people complaining about battery control and android emulation on linux, ChromeOS is a boon. You effectively get an actual Linux distro + most of android, with a side of Chrome. It's way closer to "a real computer" than an iPad for instance, and only loses to the Surface Pro/Z13 line in term of versatility IMHO. It really wasn't bad, my only deal breakers were keyboard remapping being non existent and the bluetoo…

I got a ChromeOS device a few years ago and it was great. I think they get an underserved bad reputation from being the locked-down devices you're forced to use in schools, but a personal ChromeOS device is a capable computer that can run any Android app or desktop Linux app. Though having said that, in the past year I've replaced ChromeOS with desktop Linux (postmarketOS) and I love it even more now. 4GB of RAM was…

Let's hope pKVM and other Android virtualization stuff can fill in the gap here.

Re: Snapdragon X2 Elite ARM Laptop CPU

#205

Earlier quoted context omitted.

How is it a misinterpretation? To re-quote that last sentence: > In my opinion, TSO is a red herring that isn't really improving performance, but it sounds nice on paper. That's the author directly saying that TSO isn't the major emulation performance gain that people think it is. You're correct that there are countering effects between TSO's benefits to the emulated code vs. the negative effects on the emulator and…

> How is it a misinterpretation? To re-quote that last sentence: I think we agree in our understanding, but condensing it down to "TSO isn't as much of a deal as claimed" is misleading: * Efficient TSO emulation is crucial (both on Windows and elsewhere) * The blog claims hardware TSO is non-ideal on Windows only (because Microsoft adapted the ecosystem to facilitate software-based TSO emulation). (Even then, it's un…

> Efficient TSO emulation is crucial (both on Windows and elsewhere)

Yes, but this is not in contention...? No one is disputing that TSO semantics in the emulated x86 code need to be preserved and that it needs to be done fast, we're talking about the tradeoffs of also having TSO support on the host platform.

> The blog claims hardware TSO is non-ideal on Windows only (because Microsoft adapted the ecosystem to facilitate software-based TSO emulation). (Even then, it's unclear if the author quantified the concrete impact)

> Hardware TSO is still of tremendous value on systems that don't have ecosystem support

That isn't what the author said. From the article:

> Another common misconception about Rosetta is that it is fast because the hardware enforces Intel memory ordering, something called Total Store Ordering. I will make the argument that TSO is the last thing you want, since I know from experience the emulator has to access its own private memory and none of those memory accesses needs to be ordered. In my opinion, TSO is ar red herring that isn't really improving performance, but it sounds nice on paper.

That is a direct statement on Rosetta/macOS and does not mention Prism/Windows. How correct that assessment may be is another matter, but it is not talking about Windows only.

> Those applications would still benefit from ARM64EC (i.e. native system libraries), but the actual application code would be affected quite badly by the TSO impact then, depending on how good their fallback heuristics are.

I will have to check this, I don't think it's that bad. JITted programs run much, much better on my Snapdragon X device than the older Snapdragon 835, but there are a lot of variables there (CPU much faster/wider, Windows 11 Prism vs. Windows 10 emulator, x86 vs x64 emulation). I have a program with native x64/ARM64 builds that runs at -25% speed in emulated x64 vs native ARM64, I'm curious myself to see how it runs with volatile metadata disabled.

Re: Snapdragon X2 Elite ARM Laptop CPU

#206

Earlier quoted context omitted.

How is it a misinterpretation? To re-quote that last sentence: > In my opinion, TSO is a red herring that isn't really improving performance, but it sounds nice on paper. That's the author directly saying that TSO isn't the major emulation performance gain that people think it is. You're correct that there are countering effects between TSO's benefits to the emulated code vs. the negative effects on the emulator and…

> How is it a misinterpretation? To re-quote that last sentence: I think we agree in our understanding, but condensing it down to "TSO isn't as much of a deal as claimed" is misleading: * Efficient TSO emulation is crucial (both on Windows and elsewhere) * The blog claims hardware TSO is non-ideal on Windows only (because Microsoft adapted the ecosystem to facilitate software-based TSO emulation). (Even then, it's un…

Following up that last part -- I recompiled my x64 codebase with /volatileMetadata-, which reduced the volatile metadata by ~20K (the remainder most likely from the statically linked CRT). The profiling results were negligible, under noise level between the builds and both about 15-30% below the native ARM64 build.

The interesting part is when the compatibility settings for the executables are modified to change the default multi-core setting from Fast to Strict Multi-Core Operation. In that mode, the build without volatile metadata runs about 20% slower than the default build. That indicates that the x64 emulator may be taking some liberties with memory ordering by default. Note that while this application is multithreaded, the worker threads do little and it is very highly single thread bottlenecked.

Re: Snapdragon X2 Elite ARM Laptop CPU

#207
post #12

Who is likely to package this into existing lines, from the majors? Is this a future lenovo/thinkpad carbon?

X1 Carbon is part of the Intel Evo Platform. These are co-developed with Intel and therefore this line is exclusive to them. X13s was confirmed to be sunset, another T14s is the most likely candidate among the ThinkPads.

Damn. They sunset the x13s? That's been my daily driver for a few months now. I was really hoping we'd see another one based around the Snapdragon X2.

Re: Snapdragon X2 Elite ARM Laptop CPU

#208

We’ve been using X Elite Snapdragon laptops (Thinkpad T14s and Yoga Slim running Ubuntu’s concept images) to build large amounts of ARM software without the need for cross-compiling. The hardware peripheral support isn’t 100% yet (good enough) but I’ve been impressed with the performance. ARM seems to be popular in the server space and it’s nice to see it trickling down to the PC market.

Trickling? Apple’s been on ARM for five years with great results.

To be fair, they did say "PC" specifically. It's not uncommon to consider that a category that doesn't include Apple (e.g. the "I'm a Mac" "I'm a PC" ads from years ago)

Re: Snapdragon X2 Elite ARM Laptop CPU

#209

Earlier quoted context omitted.

> How is it a misinterpretation? To re-quote that last sentence: I think we agree in our understanding, but condensing it down to "TSO isn't as much of a deal as claimed" is misleading: * Efficient TSO emulation is crucial (both on Windows and elsewhere) * The blog claims hardware TSO is non-ideal on Windows only (because Microsoft adapted the ecosystem to facilitate software-based TSO emulation). (Even then, it's un…

Following up that last part -- I recompiled my x64 codebase with /volatileMetadata-, which reduced the volatile metadata by ~20K (the remainder most likely from the statically linked CRT). The profiling results were negligible, under noise level between the builds and both about 15-30% below the native ARM64 build. The interesting part is when the compatibility settings for the executables are modified to change the…

20% is about the general order of magnitude we observed in FEX a while ago, though as you enable all TSO compatibility settings (including those rarely needed) it'll be much higher even. As people elsewhere in the thread mentioned it'd be interesting to see how FEX fares on Asahi with hardware TSO enabled vs disabled (but with conversative TSO emulation as set up by default) since it's less of a blackbox.

Re: Snapdragon X2 Elite ARM Laptop CPU

#210
post #208

Earlier quoted context omitted.

Trickling? Apple’s been on ARM for five years with great results.

To be fair, they did say "PC" specifically. It's not uncommon to consider that a category that doesn't include Apple (e.g. the "I'm a Mac" "I'm a PC" ads from years ago)

People just need to quit using the term "PC" to refer to desktop or laptop hardware that happens to be running Windows. Laptops running MacOS are "personal computers," as are desktops running Linux, or effing phones running Android, for that matter.
Post reply on HN