4 ms·

Yeah I'm deep into AVR, never got into the fancy architectures like x86 and this sounded bananas to me. In my world a register is a register is hardware. Hell,

Yeah I'm deep into AVR, never got into the fancy architectures like x86 and this sounded bananas to me. In my world a register is a register is hardware. Hell, by sidestepping GCC's register allocation one can substantially increase performance if you arrange your data into registers that your ALU or other peripheral likes best. Prime example, RAM access can be twice as fast if you load your target address into the X/Y/Z register with LD instead of letting GCC emit the LDS instruction. You'd do something like store a pointer to a very important struct that you want to access many times very quickly. I honestly have no clue if a similar concept exists on modern x86. I'd assume that you are explicitly meant to not care about things at this level and it's all handled behind the scenes. It's crazy how much the x86 CPU does for you, but I find it much more fun to tweak things close to the bare metal.

gpderetta 2y ago
It is not really my speciality, but there are equivalent things on OoO Land. Although CPUs are very good at running reasonable code efficiency, peak FP performance is still the real of hand written ASM or at the very least copious use of intrinsics. It can also be very microarchitecture specific. Because FP code often need significant unrolling, the number of architectural registers needed to store partial results can be a bottleneck, especially if the compiler doesn't do a perfect job.
dzaima 2y ago
All registers are basically always treated the exact same in OoO-land (though on x86-64 for some instruction forms it can add an extra byte of instruction encoding if there's some operand in r8..r15). But there's still a massive amount of performance tuning. Some fun examples being how Haswell can only do one FP add per cycle, but two FMAs, so you can sometimes improve throughput by replacing some 'a+b's with 'a*1+b' (at the cost of higher latency). Or how, on older Intel, three-addend 'lea' can execute on only one port (as opposed to two for two-addend 'lea', or 3 or 4 for 'add') and has 3-cycle latency (vs. 1 cycle for two-addend; so two back-to-back 'lea's have lower latency than one three-addend one), but still uses only one port and thus can sometimes be better for throughput.

gpderetta 2y ago

It is not really my speciality, but there are equivalent things on OoO Land. Although CPUs are very good at running reasonable code efficiency, peak FP performance is still the real of hand written ASM or at the very least copious use of intrinsics. It can also be very microarchitecture specific. Because FP code often need significant unrolling, the number of architectural registers needed to store partial results can be a bottleneck, especially if the compiler doesn't do a perfect job.

dzaima 2y ago

All registers are basically always treated the exact same in OoO-land (though on x86-64 for some instruction forms it can add an extra byte of instruction encoding if there's some operand in r8..r15). But there's still a massive amount of performance tuning. Some fun examples being how Haswell can only do one FP add per cycle, but two FMAs, so you can sometimes improve throughput by replacing some 'a+b's with 'a*1+b' (at the cost of higher latency). Or how, on older Intel, three-addend 'lea' can execute on only one port (as opposed to two for two-addend 'lea', or 3 or 4 for 'add') and has 3-cycle latency (vs. 1 cycle for two-addend; so two back-to-back 'lea's have lower latency than one three-addend one), but still uses only one port and thus can sometimes be better for throughput.