30-year-old analysis of RISC vs CISC still reads well!
-
RE: https://mendeddrum.org/@fanf/116090957426748922
30-year-old analysis of RISC vs CISC still reads well!
though it's fun to see which RISCisms have died out, such as "Do NOT support arbitrary alignment of data for loads/stores"
-
RE: https://mendeddrum.org/@fanf/116090957426748922
30-year-old analysis of RISC vs CISC still reads well!
though it's fun to see which RISCisms have died out, such as "Do NOT support arbitrary alignment of data for loads/stores"
@regehr okay but that's because unaligned stores are fucking awesome for optimisation
-
@regehr okay but that's because unaligned stores are fucking awesome for optimisation
@dysfun of course
-
RE: https://mendeddrum.org/@fanf/116090957426748922
30-year-old analysis of RISC vs CISC still reads well!
though it's fun to see which RISCisms have died out, such as "Do NOT support arbitrary alignment of data for loads/stores"
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
-
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
@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
-
-
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
@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 -
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
@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
-
@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
@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?
-
@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
-
RE: https://mendeddrum.org/@fanf/116090957426748922
30-year-old analysis of RISC vs CISC still reads well!
though it's fun to see which RISCisms have died out, such as "Do NOT support arbitrary alignment of data for loads/stores"
@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!)
-
@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
-
@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 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.
@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
-
@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
@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
