30-year-old analysis of RISC vs CISC still reads well!

[dysfun@social.treehouse.systems]

@regehr okay but that's because unaligned stores are fucking awesome for optimisation

[regehr@mastodon.social]

@dysfun of course

[regehr@mastodon.social]

although I guess the alignment story is a bit more complicated than that. modern x86 vector extensions sometimes require alignment, and AArch64 allows (but does not require) support for unaligned accesses

[joe@f.duriansoftware.com]

@regehr and usually unaligned accesses that straddle a cache line, or especially page, boundary still carry a significant cost. so sticking to natural alignment avoids ever dealing with those cliffs

[fay59@tech.lgbt]

@koakuma @regehr have also heard of old cores that use the alignment bits as a rotation pattern, so *(ptr_to_int32|2) loads ptr_to_int32 but rotates it 16 bits

[zwol@masto.hackers.town]

@regehr from a microarchitectural perspective I think the consensus looks something like

* code density is valuable
* complex instruction encodings make decode a bottleneck
* complex *operations*, however, just cost die area, which is cheap nowadays
* avoid situations where one instruction can trigger multiple memory faults
* avoid situations where code tuned for CPU generation N is slow on generation N+1

[fay59@tech.lgbt]

@regehr I think that one died out literally because of C. There’s no way to express that a pointer is or isn’t aligned and it’s just too useful to not have to think about it

[void_friend@tech.lgbt]

@fay59 you mean, in C you express that the pointer is aligned by building it and GCC and Clang each have optimizations that will screw you up if it isn't because “fuck you it's UB”? Or do you mean something else?

[iximeow@haunted.computer]

@fay59 @regehr i really want to know what the story is with the x86 sse ops that allow vs disallow unaligned access. like why! was the aligned one ever faster? it *is* true that an unaligned access might cross two cache lines and *that* would be gross, but...

[malwareminigun@infosec.exchange]

@regehr These days I see this most often as "people who hate wintel wanting to claim ARM is better because RISC" despite for most of the period Intel just making better parts than available from any of the ARM vendors. Being like 5 years ahead on fabs vs. everyone else was a Big Deal.

I hear this discussion less now that ARM parts competitive with Intel are out as of 2020. If anything, these days I hear the discussion in the opposite direction: Windows people blaming Apple's slight processor lead for all of Windows problems and expecting Snapdragon to fix it. (Snapdragon X Elite looks like an interesting part but I refuse to buy one until I see at least MS treat it as a first class target. I bought 2 Windows on ARM devices that are paperweights and I won't get burned like that a 3rd time. It's depressing to see people talk about Windows on ARM like it's the "new hotness" when Windows on ARM is *older* than macOS on ARM!)

[zwarich@hachyderm.io]

@joe @regehr *Device memory entered the chat*

[malwareminigun@infosec.exchange]

@iximeow I mean, on modern Intel parts the aligned one *isn't* faster. But that's partially because compiler vendors feared using the aligned ones ever for fear of breaking someone's code and Intel responded by spending the die area to make the unaligned one "free" as long as the input was actually aligned.

[iximeow@haunted.computer]

@malwareminigun llvm emits alignment-requiring sse movs even today, you can see this when it moves a 32-128 byte struct. i did say "was it ever" pretty specifically. i should have just checked uops.info because they have been the same since around nehalem, where before movups was up to four times slower

[iximeow@haunted.computer]

@malwareminigun that said uops.info's test uses an aligned pointer in both cases so that kind of is the opposite of the interesting case