4 ms·

There are processor architectures (MIPS) that can't do unaligned memory access where Linux will catch the fault, emulate the memory access in kernel and return

There are processor architectures (MIPS) that can't do unaligned memory access where Linux will catch the fault, emulate the memory access in kernel and return to the program. On every unaligned access. At least this only has to be done once, and frankly these AVX instructions are slow initially anyway.

loeg 6y ago
And MIPS is slow as a dog, in part as a result of software handlers like this (software handles TLB and virtual memory walks, too, IIRC).
saagarjha 6y ago
Yeah, and that was suuuper slow and everyone told you to not do it for exactly that reason…
- stefan_ 6y ago
  It's absurdly slow on hot paths, yet entirely unnoticeable to the vast majority of software out there.
  - H8crilA 6y ago
    Most performance anti-patterns in almost any program are not important at all, as most of the code is not on the hot path.
zokier 6y ago
As it happens, MIPS is also practically dead as an general purpose architecture...
- sigotirandolas 6y ago
  It also happens on 32-bit ARM, which is maybe on its way out, but still way more common.
gumby 6y ago
> At least this only has to be done once, and frankly these AVX instructions are slow initially anyway. FWIW I believe only some of them, and those are just some (or all?) AVX-512 instructions. I think AVX2 is implemented on the main die and doesn't have to be powered up first.
- celrod 6y ago
  https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html AVX (256 bit) instructions also suffer a penalty. Both the 256 and 512 bit instructions resulted in a slowdown for 9 microseconds featuring a quarter the instructions per clock, but the 512 bit instructions resulted in an additional penalty of 11 microseconds without executing instructions. The first penalty was associated with voltage, and the second with frequency. Heavier 256 bit instructions would probably have resulted in the frequency transaction as well.

loeg 6y ago

And MIPS is slow as a dog, in part as a result of software handlers like this (software handles TLB and virtual memory walks, too, IIRC).

saagarjha 6y ago

Yeah, and that was suuuper slow and everyone told you to not do it for exactly that reason…

stefan_ 6y ago
It's absurdly slow on hot paths, yet entirely unnoticeable to the vast majority of software out there.
- H8crilA 6y ago
  Most performance anti-patterns in almost any program are not important at all, as most of the code is not on the hot path.

zokier 6y ago

As it happens, MIPS is also practically dead as an general purpose architecture...

sigotirandolas 6y ago
It also happens on 32-bit ARM, which is maybe on its way out, but still way more common.

gumby 6y ago

> At least this only has to be done once, and frankly these AVX instructions are slow initially anyway. FWIW I believe only some of them, and those are just some (or all?) AVX-512 instructions. I think AVX2 is implemented on the main die and doesn't have to be powered up first.

celrod 6y ago
https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html AVX (256 bit) instructions also suffer a penalty. Both the 256 and 512 bit instructions resulted in a slowdown for 9 microseconds featuring a quarter the instructions per clock, but the 512 bit instructions resulted in an additional penalty of 11 microseconds without executing instructions. The first penalty was associated with voltage, and the second with frequency. Heavier 256 bit instructions would probably have resulted in the frequency transaction as well.