27 ms·
Apple CPU tricks: memory reordering, JavaScript support, ref counting
- jchw 6y agoRe: “JavaScript” instructions. I think it means FJCVTZS which is not Apple specific and only yields a fairly minor improvement. It’s not even really that JS specific, it’s definitely designed to help with JS numbers but it’s not like a large chunk of JS functionality is in silicon. The memory ordering stuff is cool, calling it cheating might be a bit harsh although it would be cool if other ARM cores would support something like this.
- snowwrestler 6y agoWhen I read this on Twitter yesterday, it seemed like it was just a summary of what has already been reported by others elsewhere. Not sure why it’s worth posting here, where all this info has already been covered in more detail in earlier threads.
- Hokusai 6y agoTwitter makes no sense as platform for long reads. The format is atrocious and difficult to follow. (When all that you have is a hammer all problems seem a nail)
- dmart 6y agoThis was a legitimate criticism back when there was no way to thread tweets and you had to read them in reverse. Now that you just scroll down like any other website, it just sounds like tired complaining.
- Hokusai 6y agoIt is still atrocious. Designers have developed thru the ages great fonts, layouts and a miriad of tools to create text that is easy to read. Not having to read the text backwards is a extremely low bar, I expect more from a text. Twitter is the wrong tool for the task, a very bad one.
- phs318u 6y agoThis complaint is about more than mere website formatting (per HN guidelines). There's now 11 distinct reply threads of fragmented discussion to dig into, for anyone that might be interested. Hokusai is right to complain about this. And people savvy enough to write the article should know better. Post it on a blog and tweet the link. How hard is that?
- rini17 6y agoIt is hard, some people are plainly incapable of expressing themselves in article form. Or refuse to. There was plenty of shaming already and it did not help.
- phs318u 6y agoI wasn’t commenting on his essay writing skills. I appreciate many people aren’t wordsmiths. Literally the same 11 points in a single block of contiguous text, posted anywhere (GitHub, LinkedIn, Medium etc etc).
- gifnamething 6y ago>Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- fxtentacle 6y ago"They did something in their CPU to double the speed of reference counting." I wish we'd get that on x86_64 too. Especially since it seems like an obvious and easy win.
- zozbot234 6y agoRefcounting in a single-threaded context is extremely quick and efficient. What's expensive is atomic reference counting, as seen e.g. in C++ shared_ptr<> and Swift ARC.
- vlovich123 6y agoInterestingly the Twitter thread is saying uncontended atomic operations are generally as fast as non-atomic, so I don’t think the weaker memory model is the totality of the reason. Another thing is apparently their branch predictor is specially tuned to work with how Objective-c dispatch works (which iirc Swift inherits in places too, and not just when interfacing with Obj-C APIs)
- spankalee 6y agoFor an the references to this, I haven't yet seen a description of what the optimization is. Anyone know?
- tambourine_man 6y agoIt’s much more than twice as fast. https://twitter.com/catfish_man/status/1326238434235568128?s=21 https://twitter.com/catfish_man/status/1326238434235568128?s...
- spankalee 6y agoWhat's the actual optimization though?
- tambourine_man 6y ago
- messe 6y agoFinally I see somebody mentioning the memory ordering. I've been wondering for a while how they've managed to get multithreaded x86 emulation working fast. I had heard mentions of "kernel support", but hadn't really looked into it much. It turns out that what I had guessed was correct, and that they simply added intel's memory ordering as an optional mode to their processor; "When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering."
- zozbot234 6y agoRISC-V also has a weak memory ordering by default, with TSO (like x86) as an optional feature. So this is not a novel approach in any way.
- monocasa 6y agoThere's a spec for that, but I don't know of any synthesizable RV cores with optional TSO that have actually been made, whether ASICs _or_ configurable logic. That does make it pretty novel on Apple's end. I agree with Heinlein that "a good idea is worth one bottle of scotch"; that the execution is where the vast majority of the work is and where the vast majority of praise should lie. And that's coming from someone who's not as bullish as some on Apple's execution. I think AMD's cores are better and compared 1/1 on the same process node Apple would look a little behind overall. But Apple for sure gets praise for their execution here (optionality in store order), which is remarkably good.
- brigade 6y agoWell sure, POWER7 implemented a strong-ordering mode specifically for x86 emulation a decade ago [1] [1] https://marc.info/?l=linux-mm&m=121382852909406&w=2 https://marc.info/?l=linux-mm&m=121382852909406&w=2
- gpderetta 6y agoThanks, I have been looking for this for ages and I couldn't find a reference. I was starting to think I immagined it.
- haunter 6y agoMore readable format https://threadreaderapp.com/thread/1331735383193903104.html https://threadreaderapp.com/thread/1331735383193903104.html
- phs318u 6y agoThank you! Posting anything long-form on Twitter is madness. Whether it's posting an image of long-form text, or tweeting. Individual. Sentences. Like. You're. Captain. Kirk.
- pythonvisa 6y agoIs the ARM ISA fundamentally faster than x86? If the underlying architectures are converging as described, it kinda seems that the difference between the two instruction sets are more legal than technical.
- tambourine_man 6y agoNo, just a lot of brute force and focused optimization going on the M1. There are a few advantages, (it’s a newer architecture after all) but nothing that justifies the current difference.
- toast0 6y agoI think there's a couple things here. x86 defines a pretty strict ordering of memory operations, where ARM is more relaxed; as discussed elsewhere in the thread, this means atomic operations, used for synchronization, will need to wait for pending stores to finish on x86, but not on ARM. The other thing is that the M1 processor seems to be a lot wider than contemporary processors. This means it can (potentially) do more operations per clock. Wider processors are harder to clock faster, but it works for Apple. Apple has no desire to put in the cooling you need to get chips running at 4+ GHz, so it's not a big deal if their chips are clock limited. On the other hand, Intel and AMD like their cores to approach 5 GHz at the top end.
- calo_star 6y agoCan you elaborate on the "Wider processors are harder to clock faster" part?
- normaljoe 6y agoClock is a up volt and down volt. There is a period of time it takes to reach either up or down. If I have to get the clock to reach 2 cores/units at the same time that is easier then say 4 cores/units. As you increase the clock speed the time to reach all the cores decreases. So if you are wider you would need to reach more cores/units in the same period of time, hence "harder". EDIT (To make it a little more clear) To make it more clear the voltage change is typically represented in books as a vertical line, but that is not the case it's diagonal and fuzzy. By fuzzy I mean not a straight line but will have some tiny mini downs on the way up. Different parts of the circuits are going to respond to the up or the down. They are also can vary based on the exact voltage. For example if I have a 5V up one circuit might consider 4.8V to be up and another could be 4.9 or 4.7. Silicon has improved, but there still is limits of scale based on size, volts and timing.
- muststopmyths 6y ago>8/ Another "magic" trick is how their "Swift" programming language uses "reference counting" instead of the "garbage collection" in Android. They did something in their CPU to double the speed of reference counting. What the hell does that even mean ? Disregarding the nonsensical attribution of magic to Swift vs Java, if "reference counting" on translated x86 code is faster, then I suppose M1 does "lock add / cmpxchng" or whatever faster than X86. I would love to know how. Other than just as a side-effect of a SoC, UMA architecture.
- dathinab 6y ago> What the hell does that even mean ? > double the speed of reference counting The simplest low latency system memory making atomics faster in some contexts (faster cache write back/fetch). Then atomic operations (using Aquire/Release) are theoretically faster on ARM due to the weak memory ordering (I'm not sure if this does help for translated x86 code). Potentially other reasons can include: - maybe optimized fetch add/sub instructions (or more precise the ARM instructions used by fetch add/sub functions in higher level languages) - maybe tweaks to the coherence protocol - maybe specialized optimizations in the pipelineing All in all it means Apple focused on making sure fetch add/sub are fast (most likely as this is what is normally used for Rc).
- annilt 6y agoI think it says refcounting twice faster for swift on M1 compared to swift on x86. It is possible because if you don’t have TSO(total store order), you can employ atomic operations without waiting/flushing previous items in the CPU’s store buffer
- gpderetta 6y agoBut apparently they are faster even in TSO mode. Maybe they aggressively speculate around them.
- ksherlock 6y agoMaybe this: https://twitter.com/Catfish_Man/status/1326238434235568128 https://twitter.com/Catfish_Man/status/1326238434235568128 fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1 ... Weaker memory model makes acquire-release atomics possible to implement much more efficiently, in exchange for not hiding some classes of multithreading bugs
- voldacar 6y ago> reference counting is faster than garbage collection lol, not taking the bait
- dathinab 6y agoBut reference counting is (potentially) faster then garbage collection. At least under some circumstances: - modern architecture having fast atomic fetch_add/sub - weak memory ordering making atomic fetch_add/sub even faster (if Acquire/Release ordering is used) - optimize the usage of reference counting by eliminating pointless reference counting, e.g. as done by Objective-C/Swift automatic reference counting (ARC). Or e.g. done when using borrows in rust for everything except the places you know you really need to clone the Atomic Reference Counter (also ARC but a different one ;=) ). Reference counting was for a long time basically guaranteed to be slower then garbage collection because of slower atomics, no weak memory ordering and "naive" usage of reference counting introducing a lot of unnecessary reference counter increased and decreases. But with modern hardware and compilers it's no longer as clear cut, at least in practice wrt. to modern hardware.
- WSSP 6y agothe bait is that reference counting is (often considered to be) a type of garbage collection, and that correction is frequently made in comment threads and hey, here we are
- lern_too_spel 6y agoReference counting cannot be faster than naive manual memory management because it does the same thing with the additional overhead of reference counting. Even a very simple generational GC beats naive explicit memory management on most nontrivial workloads given enough memory. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
- skellington 6y agoYou are misunderstanding this paper deeply. Quoted summary from the paper itself: >>>We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management.<<< GC is "competitive" when is has 5x as much memory according to the authors. Well, probably this is because GCs are fast when they have low to no memory pressure. They simply don't need to garbage collect anything. In fact, a non-collecting, non-managed, memory approaches can be faster than any memory management. That is, you have a short lived application that just allocates what it needs, never frees anything, then dies when done. But this is not apples to apples. The paper also says that with 2x more memory than manual management, GC is 70% slower and under paging scenarios GC can suffer "order-or-magnitude performance penalties relative to explicit memory management." Except under unusual conditions, there is no case where GC is faster than manual.
- danvk 6y agoCan someone say more about the JavaScript optimization?
- tjalfi 6y agoThey might be referring to the ARM FJCVTZS instruction[0]. It speeds up converting JavaScript doubles to 32-bit integers. [1] is the Webkit commit that added support for FJCVTZS, it was between a 0.5 to 2% speedup - that's a big win for a mature optimizer. [0] https://stackoverflow.com/a/50966903/ https://stackoverflow.com/a/50966903/ [1] https://bugs.webkit.org/show_bug.cgi?id=184023#c24 https://bugs.webkit.org/show_bug.cgi?id=184023#c24
- annilt 6y agoIn addition to FJCVTZS instruction, they added more floating point execution units and registers. Also did lower latency of pipelined fp instructions
- dukeofdoom 6y agoThey also seem to have added video codec decoders, because it can run 8k timelines pretty well in final cut. 4k without dropping frames even on the macbook air.
- wmf 6y agoEvery GPU including Nvidia, AMD, and Intel have video decoders.
- dukeofdoom 6y agoYes, but I think the latest codec that canon uses in their newest cameras for 10 bit 8k raw are now supported. I'm not sure if it's hvac265 or something else
- deleted 6y ago[deleted]
- apetrovic 6y agoIs there any reference/confirmation for all of this? The fact that the author types "Swift" under quotes and doesn't know that refcount is something inherited from Objective C and the whole OS rely on it makes the rest of claims a bit more gossipy. Also, AFAIK MS translation of x86 -> ARM works different than Rosetta2, so the results aren't just because "Apple added Intel's memory ordering to their CPU" (whatever that means)
- barnaclejive 6y agoThe author did type "Swift" but it applies to Obj-C also, obviously. I wouldn't discount the whole post because of that slip-up. The optimizations made to reference counting are more than "gossip". David Smith posted about this weeks ago also, if you need more reference/confirmation than that I'm not sure what to tell you.
- gameswithgo 6y agomay also apply to Rust where we often make use of reference counting when the borrow checker isn’t enough
- vlovich123 6y agoARC probably yes (assuming the standard library annotates the atomic operations properly). RC no. That being said, it sounds like in general uncontended atomic operations are faster so this might benefit a lot of atomic code in any language.
- skywhopper 6y agoWhile I was also thrown off by the lack of reference to Objective-C, in context I think the author used quotes around “Swift” to make it clear it’s a proper name and that he’s not talking about a “swift (ie fast) programming language”.
- coliveira 6y agoFinally a company has the guts to move us from the straitjacket of x86. I hope this is just the beginning of much needed innovation in CPU architecture. Due to the MS/Intel duopoly we had to suffer x86 for decades with few real options.
- pram 6y ago2020 is finally the year of RISC on the desktop
- vaxman 6y agouh, no. Well, maybe... “ On Friday, September 1, 2017, after a round of layoffs that started in Oracle Labs in November 2016, Oracle terminated SPARC design after the completion of the M8. Much of the processor core development group in Austin, Texas, was dismissed, as were the teams in Santa Clara, California, and Burlington, Massachusetts.[4][5] SPARC development continues with Fujitsu returning to the role of leading provider of SPARC servers, with a new CPU due in the 2020 time frame.”
- vaxman 6y agoHow long before 2020 Fujitsu rebinned SPARC chips are sold to OEMs for SPARCstations runnin’ popOS? It’s not like System76 is going to be able to buy M1s (dang sounds like a weapon when you put it that way ) and Ryzen might not compete with near term successors to M1.
- pjmlp 6y agoI thought it was during the 80's and early 90's. https://en.wikipedia.org/wiki/Acorn_Archimedes https://en.wikipedia.org/wiki/Acorn_Archimedes https://en.wikipedia.org/wiki/Silicon_Graphics#RISC_era https://en.wikipedia.org/wiki/Silicon_Graphics#RISC_era https://en.wikipedia.org/wiki/HP-UX#BL_series https://en.wikipedia.org/wiki/HP-UX#BL_series https://en.wikipedia.org/wiki/SPARCstation https://en.wikipedia.org/wiki/SPARCstation https://en.wikipedia.org/wiki/NeXT#1987%E2%80%9393:_NeXT_Computer https://en.wikipedia.org/wiki/NeXT#1987%E2%80%9393:_NeXT_Com... https://en.wikipedia.org/wiki/BeBox https://en.wikipedia.org/wiki/BeBox
- titzer 6y ago> 4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. Uh, no. Implementing TSO in a highly performant way is not "cheating", it's a difficult engineering feat. And no, TSO is not some fancy Intel thingy. It's a standard memory model.
- gameswithgo 6y agoi believe in this case cheating is being used to mean that they were clever, working around the problem, not doing anything wrong
- Waterluvian 6y agoYeah. "How do we make the Wii run Game Cube games? We cheat by putting a Game Cube in the Wii!" It's a playful use of the term.
- eyelidlessness 6y agoOr for us old [feeling] folks: it’s “cheating” by getting a world map and playing through the puzzles and minibosses we would still encounter... not getting a Game Genie and sliding under Mother Brain. Edit: Lol I know, downvote away, icgaf I haven’t played a game besides minesweeper in months.
- Waterluvian 6y agoI honestly just don't understand what you're trying to say.
- eyelidlessness 6y agoI honestly was just kind of flow of consciousness riffing so I don’t blame you. Just overextending the metaphor of gaming applied to cheating with applied knowledge versus cheating with deus ex machina
- saagarjha 6y agoIt’s important to note that most of the things mentioned here are just “tricks”: they’re fun to discover and talk about, but they really only end up being minor wins in practice. TSO is great…if you are trying to make a simpler Rosetta (it’s not even necessary on the M1, although I think Apple is still using it for convenience; I’m still trying to find out where). The JavaScript instruction speeds up…one specific rounding in JavaScript. Fast atomics help…if you’re that one specific part of Apple’s runtime that has taken advantage of it yet. They are all cool, important little optimizations, and I’m sure that few other companies could do what Apple is doing in this space. However, it’s very much not true that Apple is “cheating” their way to performance with a bunch of these tricks for their own software (as much as you can call this cheating). Their processors are optimized for general-purpose workloads, and blow everything else out of the water even if you’re doing something profoundly “un-specialized” like run Photoshop or a Linux VM. It’s easy to come up with takes like these that point at buzzwords that you’ve seen being thrown around in the last couple weeks in an attempt to explain this chips. The reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we don’t have the details right now.
- _kbh_ 6y agoI believe with regards to TSO, it is actually a huge benefit performance wise. Without you would need to effectively have a barrier after every memory operation ARM, reducing performance drastically.
- saagarjha 6y agoImplementing the memory ordering in hardware is a huge performance benefit, but they didn’t have to do it with a switch like they have right now. ARMv8.4-RCpc would be enough, and I believe M1 supports these too. (FWIW, Rosetta itself does “cheat”: the translated code and the runtime shares an address space, and memory accesses are not checked, so it’s possible to write an “Intel” binary that is aware of the runtime and can read emulator state.)
- 6y ago
- olliej 6y agoQuick note: the magic "help JS function" is literally just a double->int conversion that uses the x86 sentinel values and rounding modes. The effect on JS is that it removes a set of branches following ((int)someDouble) that are needed to match the x86 semantics that JS mandates. The instruction is not magically faster than x86. In fact more or less by definition it's just doing what x86 does. I am tired of people bringing up that instruction as though it's magically making JS faster compared to intel. At best it's a leveling the playing field instruction. Implementing TSO isn't "cheating", it's hard work that other companies aren't willing to do. Ref counting isn't magically faster than other GC methods - there's arguments that it is slower - it does however use much less memory than pretty much any other GC scheme, hence the lower memory needs on iOS vs Android.
- normaljoe 6y agoRC vs GC really depends on workload/memory and the volatility of the allocate to deallocate timeframe. I think the better argument here is that iOS and MacOS use RC in the underlying objc libs. Having a CPU that works better around that makes sense to increase performance for those particular OSes.
- olliej 6y agoOh I didn’t mean to distract from the improvements to refcounting - it sounds very much like they’ve significantly improved the perf of uncontended atomic increment vs Intel which is obviously a win on iOS and OS X as objc and Swift both inline refcounting - I think on windows/COM it is through a virtual call? In which case improving the increment itself seems like it would not be a huge win. As far as perf the general argument is that dropping the need for refcounting saves time, and that removal also helps caching due to reduced per-object size. That said I’m not sure if those comparisons are comparing to generational or moving collectors (which are the low latency collectors) because those start needing write barriers.
- GeekyBear 6y agoAnandtech has already posted a list of ways that Apple's big ARM core implementation (in the iPhone version of the chip) differs from industry norms, ARM and x86. Some examples >Decode: What really defines Apple’s Firestorm CPU core from other designs in the industry is just the sheer width of the microarchitecture. Featuring an 8-wide decode block, Apple’s Firestorm is by far the current widest commercialized design in the industry. Re-order Buffer: A +-630 deep ROB is an immensely huge out-of-order window for Apple’s new core, as it vastly outclasses any other design in the industry. Intel’s Sunny Cove and Willow Cove cores are the second-most “deep” OOO designs out there with a 352 ROB structure, while AMD’s newest Zen3 core makes due with 256 entries, and recent Arm designs such as the Cortex-X1 feature a 224 structure. Execution Units: On the Integer side, we find at least 7 execution ports for actual arithmetic operations. These include 4 simple ALUs capable of ADD instructions, 2 complex units which feature also MUL (multiply) capabilities, and what appears to be a dedicated integer division unit. On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Cache: Apple’s designs are monstrous, and the A14 Firestorm cores continue this trend. Last year we had speculated that the A13 had 128KB L1 Instruction cache, similar to the 128KB L1 Data cache for which we can test for, however following Darwin kernel source dumps Apple has confirmed that it’s actually a massive 192KB instruction cache. That’s absolutely enormous and is 3x larger than the competing Arm designs, and 6x larger than current x86 designs, which yet again might explain why Apple does extremely well in very high instruction pressure workloads, such as the popular JavaScript benchmarks. The huge caches also appear to be extremely fast – the L1D lands in at a 3-cycle load-use latency. AMD has a 32KB 4-cycle cache, whilst Intel’s latest Sunny Cove saw a regression to 5 cycles when they grew the size to 48KB. https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de... There are plenty of other details in the piece, although bear in mind that the M1 is more beefy than the A14 detailed here (more i/o bandwidth, larger system cache, etc.).
- rayiner 6y ago
- forrestthewoods 6y ago> They did something in their CPU to double the speed of reference counting. Can anyone explain what they did exactly? Also, what are their JavaScript specific instructions?
- xucheng 6y agoAbout TSO, I do wonder whether Apple will stop implementing it in its future chips when the transition to Apple silicon is over and Rosetta 2 is dropped.
- pjmlp 6y ago> 18/ Another "magic" trick is how their "Swift" programming language uses "reference counting" instead of the "garbage collection" in Android. They did something in their CPU to double the speed of reference counting. > 19/ ...even when translating x86 code, all that reference counting overhead (already more efficient than garbage collection) gets dropped in half. Yet another weird performance enhance to add to all the others. Not at all, as proven by known benchmarks. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages Putting refcounting in the CPU was the only way Apple managed to make it fast enough. Objective-C only went with refcounting because Apple failed to make their tracing GC work flawless across frameworks with mixed compiler flags alongside C semantics, thus having the compiler automate retain/release was a more sane option to do. Likewise, Swift had a requirement to have flawless interoperability with Objective-C runtime and libraries, so the natural option was to adopt reference counting instead of a translation layer across both worlds. .NET / COM interoperability is a good example on how to integrate a tracing GC with reference counting can turn into an engineering feat. Speaking of which UWP, which is 100% COM based, is somehow noticeable slower than pure Win32 applications, besides the sandboxing, the main reason is naturally AddRef/Release everywhere. Hence why C++/WinRT as C++/CX replacement is full of tricks, moving destruction to background threads, wrapping COM handles in stack allocations, taking advantage of constexpr. So yeah, it is tricks and marketing how those tricks are sold, specially to crowds that care more about the next SPA framework release than how compilers work and CPUs work.
- legulere 6y agoIt would be really interesting to see the performance difference of TSO on and off for the arm assembly.
- layoutIfNeeded 6y ago>When you recompile code for a new architecture, it usually breaks. Yeah, then your code is shit and was relying on undefined behaviour.
- rwmj 6y agoI wonder if TSO "violates" ARM standard conformance in some way? Perhaps not since it makes the memory ordering stronger, and is therefore upwards compatible. Or perhaps Apple doesn't care any more about strictly conforming to ARM's specs, which would be interesting news.
- jsheard 6y agoM1 does follow standard ARM memory ordering rules in general, TSO is only enabled for processes running under Rosetta2 emulation It probably would be legal to enable TSO everywhere as you said, but weaker ordering lets the CPU do more aggressive optimizations
- angry_octet 6y agoThis is about as accurate as Rob Graham's other hot takes. He's no expertise in CPU microarchitecture, and he's way off the mark again.