241–249 of 249 posts
Earlier quoted context omitted.
> That's par for course with Apple. They never acknowledge competitors Unlike which company that does?
https://www.google.com/search?ei=CWzzXqODOLK90PEPhbi7uAY&q=%...
That's referencing them to tell how better you are: "Optional Clear View™ mast offers up to 40% greater visibility than leading competitors."
Apple does that too.
Earlier quoted context omitted.
That would be too expensive, unless the emulation in general is ao high not to matter. If store releases and load aquires were very cheap already why make them distinct from normal one anyway? I suspect that either the CPU is already TSO in practice or has some TSO mode.
> If store releases and load aquires were very cheap already why make them distinct from normal one anyway? Perhaps if the ARM ISA was designed today, they would, I'm not sure. My impression is that ARM added them when (a) it became obvious the way the wind was blowing with respect to modern memory models, like Java (sort of), C and C++, where acquire and release are the dominant paradigm (and I doubt any other langu…
Re TSO mode, I thought I remembered that Power8/9 had a TSO mode (explicitly for compatibility with x86 code), but I can't find any reference to it right now.
Earlier quoted context omitted.
> If store releases and load aquires were very cheap already why make them distinct from normal one anyway? Perhaps if the ARM ISA was designed today, they would, I'm not sure. My impression is that ARM added them when (a) it became obvious the way the wind was blowing with respect to modern memory models, like Java (sort of), C and C++, where acquire and release are the dominant paradigm (and I doubt any other langu…
sorry for the confusion, I'm aware why ARM added those instructions (a very good decision compared to the bizarre barriers available on classic RISCs); what I meant is, if store release can be implemented to be as fast as a normal store, why wouldn't Apple just give release semantics to normal stores? I guess this allow them to be forward compatible with future more relaxed architectures, but I don't think they care…
"I never said release stores can be implemented as fast as regular stores, but they might well be fast enough. Maybe half the throughout (1/cycle) with some other ordering related slowdowns.
In particular, maybe you can implement them as fast an acq/rel all the time CPU mode would be".
Or something like that.
Earlier quoted context omitted.
sorry for the confusion, I'm aware why ARM added those instructions (a very good decision compared to the bizarre barriers available on classic RISCs); what I meant is, if store release can be implemented to be as fast as a normal store, why wouldn't Apple just give release semantics to normal stores? I guess this allow them to be forward compatible with future more relaxed architectures, but I don't think they care…
I think understood the first time, but my answer is: "I never said release stores can be implemented as fast as regular stores, but they might well be fast enough . Maybe half the throughout (1/cycle) with some other ordering related slowdowns. In particular, maybe you can implement them as fast an acq/rel all the time CPU mode would be". Or something like that.
The reason I'm thinking the cpu might actually be tso is that I haven't seen significant evidence that, in an high performance cpu, tso is a significant performance bottleneck. For the last 15 year or so Intel had the best performing memory subsystem and didn't seem significantly hampered by reordering constraints compared to, say, POWER.
Earlier quoted context omitted.
I think understood the first time, but my answer is: "I never said release stores can be implemented as fast as regular stores, but they might well be fast enough . Maybe half the throughout (1/cycle) with some other ordering related slowdowns. In particular, maybe you can implement them as fast an acq/rel all the time CPU mode would be". Or something like that.
Yes, I could see a slightly slower but fast enough store and load be good enough (and in fact it would be great in general, not just translation). The reason I'm thinking the cpu might actually be tso is that I haven't seen significant evidence that, in an high performance cpu, tso is a significant performance bottleneck. For the last 15 year or so Intel had the best performing memory subsystem and didn't seem signif…
Also, it seems that Apple ARM chips exhibit essentially unlimited memeory level parallelism, while until very recently Intel chips had a hard limit of 10 or 12 outstanding requests, and in a very-hand wavy way some have claimed that this may be related to the difficulty of maintaining ordering.
More recent, Ice Lake can execute two stores per cycle, but can only commit one store per cycle to the L1D, unless two consecutive stores are to the same cache line. The "consecutive" part of that requirement comes directly from the store-store ordering requirement, and is a significant blow for some high store throughput workloads.
Similarly, I believe the whole "memory ordering mis-speculation on exiting a spin lock spin" thing, which was half the reason for the pause instruction, also comes from the strong memeory model.
None of these are terrible restrictions on performance, but they aren't trivial either. Beyond that it is hard to estimate the cost of the memeory ordering buffer in terms of power use, etc.
I agree that Intel has made chips with power memory subsystems despite this, but it is really hard to compare across vendors anyway: R&D and process advantage can go a long way to papering over many faults.
[1] https://www.realworldtech.com/forum/?threadid=173441&curpost...
Earlier quoted context omitted.
Yes, I could see a slightly slower but fast enough store and load be good enough (and in fact it would be great in general, not just translation). The reason I'm thinking the cpu might actually be tso is that I haven't seen significant evidence that, in an high performance cpu, tso is a significant performance bottleneck. For the last 15 year or so Intel had the best performing memory subsystem and didn't seem signif…
Yes, it's not a devastating impact, but my thinking on this has shifted a bit lately to "somewhat significant" impact. For example, I believe the strong store-store ordering requirement significantly hurts Intel chips when cache misses and hits are mixed and an ABA scenario occurs as described at [1]. Also, it seems that Apple ARM chips exhibit essentially unlimited memeory level parallelism, while until very recentl…
But which architectures do not actually drain the buffer in order in practice? Even very relaxed RISCs (including ARM) normally respect causality (i.e. memory_order_consume) and it seems to me that if, say, an object pointer is made visible before the pointed object, that can violate this guarantee, right?
You say that Apple CPUs show near unlimited MLP, do you have any pointers?
Earlier quoted context omitted.
Yes, it's not a devastating impact, but my thinking on this has shifted a bit lately to "somewhat significant" impact. For example, I believe the strong store-store ordering requirement significantly hurts Intel chips when cache misses and hits are mixed and an ABA scenario occurs as described at [1]. Also, it seems that Apple ARM chips exhibit essentially unlimited memeory level parallelism, while until very recentl…
Thanks for the RWT link, I had missed that discussion back then. I normally assume that store-store reordering is not a huge deal as the store buffer hides any latency and blocking, but I failed to appreciate that the store buffer filling up is an issue. But which architectures do not actually drain the buffer in order in practice? Even very relaxed RISCs (including ARM) normally respect causality (i.e. memory_order_…
Earlier quoted context omitted.
The original PowerPC on Intel Rosetta was pretty amazing. First, most programs do much of their work inside the OS - rendering, network, interaction, whatever, so that's not emulated, Rosetta just calls the native OS functions after doing whatever input translation is necessary. So, nothing below a certain set of API's is translated. You have to keep a separate translated binary in memory, and be able to compile miss…
> the translated apps frequently faster than running native on PowerPC macs! This gets repeated a lot and it's generally false. In fact, most of the time they were slower, and realistically you would expect this. On a clock for clock basis, an OG Mac Pro 2.66GHz was about 10-20% slower than a Quad G5 2.5GHz running the same PowerPC software. In some benchmarks, the Quad G5 was still faster at running PowerPC software…