111–120 of 196 posts
Finally 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.
Beware what you wish for.
Earlier quoted context omitted.
> 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. I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for som…
This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we'r…
I think the problem isn’t just that it’s not particularly useful, but that it’s an actively bad idea. It statically encodes ILP that we get dynamically in chip designs today, which means that ILP can no longer react to changing conditions, like literally any core architecture changes as the underlying hardware evolves (or even on the same die, say finding itself running on an efficiency core rather than a performance core or vice versa) or running in an SMT environment in which it is not the only instruction stream going through the pipeline.
Is 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.
I 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 m…
Earlier quoted context omitted.
This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we'r…
Not disputing what you're saying on instruction decoding but there is a lot of other stuff on an x86 processor that Apple hasn't needed or chosen to implement: 32bit, AVX, legacy SIMD, legacy modes, Intel Management Engine plus probably a more complex instruction set. Individually these may not make a difference but add them all up ....
... and it still may not make a difference.
> 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.
To add to this: The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM engineer: > Currently, power has a weaker memory model than x86. Implementing a stronger memory model allows an emulator to more efficiently translate x86 code into power code, resulting in faster code execution. What's interesting is IBM publishes pretty detail…
As for sharing data, a non-TSO thread can basically assume that a thread using TSO is equivalent to a non-TSO thread using only ldapr/stlr for memory access. And those interactions are well-defined.
> 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
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.
It’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 rou…
That "competitor" btw is not Intel - they already fail at the basics - but AMD.
> 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.
Earlier quoted context omitted.
> 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. I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for som…
This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we'r…
Without AMD in the picture, Itanium issues would have eventually been sorted out.