5 ms·

I'm curious that the latency of these is actually worse than the latency of floating operations. Yes, they are worse than many integer instructions, but they s

by taeric 1mo ago

I'm curious that the latency of these is actually worse than the latency of floating operations. Yes, they are worse than many integer instructions, but they seem to be on basically the same order as the equivalent float operations?

jcranmer 1mo ago
Floating-point division requires 53 bits instead of 64 bits for integers. A lot of the increased latency comes from the wider datatypes.
- throw235346 1mo ago
  32-bit integer division is slower than 64-bit float division, so it’s not that. CPU manufacturers just optimise one way more than the other. https://uops.info/html-instr/IDIV_R32.html https://uops.info/html-instr/IDIV_R32.html https://uops.info/html-instr/DIVSD_XMM_XMM.html https://uops.info/html-instr/DIVSD_XMM_XMM.html
mtklein 1mo ago
My rule of thumb is that integer ops cost 1 cycle except divides, floats 3 but maybe divide is a bit more, then integer divides are like infinity at 20+ cycles that cannot be amortized by vectorization. When you code simd it's best to assume the integer divide instruction does not exist. Just an impossibility, if you need to divide ints, rethink your whole program.
- dzaima 1mo ago
  Float divides are still pretty expensive; 8-10 cycles of latency on modern hardware, integer divides being 8-20 cycles. (on Apple M1 both are 8-10 cycles; int div is much worse on older x86 hw) Integer multiply is also pretty universally 3 cycles of latency, i.e. basically the same as float multiply (or even add!). What float div definitely has over int div is throughput, as float div comes in vectorized versions on x86 & ARM, and it usually is actually parallelized. On top of generally fp div generally having higher throughput (M1 gets down to 1 instr/cycle! though int div isn't bad either at 0.5 instrs/cycle; x86 numbers are messy but even 32-bit int div is never better than f64 div, though they're close; also an annoying aspect is that x86 division instrs actually always take a 128-bit divisor, though hopefully a sign-/zero-extended 64-bit value skips the extra work)
- brianpaul 1mo ago
  Though, if you happen to be dividing by constants, compilers can do a good job of optimizing for that, simd too probably.

by taeric 1mo ago

jcranmer 1mo ago

Floating-point division requires 53 bits instead of 64 bits for integers. A lot of the increased latency comes from the wider datatypes.

throw235346 1mo ago
32-bit integer division is slower than 64-bit float division, so it’s not that. CPU manufacturers just optimise one way more than the other. https://uops.info/html-instr/IDIV_R32.html https://uops.info/html-instr/IDIV_R32.html https://uops.info/html-instr/DIVSD_XMM_XMM.html https://uops.info/html-instr/DIVSD_XMM_XMM.html

mtklein 1mo ago

My rule of thumb is that integer ops cost 1 cycle except divides, floats 3 but maybe divide is a bit more, then integer divides are like infinity at 20+ cycles that cannot be amortized by vectorization. When you code simd it's best to assume the integer divide instruction does not exist. Just an impossibility, if you need to divide ints, rethink your whole program.

dzaima 1mo ago
Float divides are still pretty expensive; 8-10 cycles of latency on modern hardware, integer divides being 8-20 cycles. (on Apple M1 both are 8-10 cycles; int div is much worse on older x86 hw) Integer multiply is also pretty universally 3 cycles of latency, i.e. basically the same as float multiply (or even add!). What float div definitely has over int div is throughput, as float div comes in vectorized versions on x86 & ARM, and it usually is actually parallelized. On top of generally fp div generally having higher throughput (M1 gets down to 1 instr/cycle! though int div isn't bad either at 0.5 instrs/cycle; x86 numbers are messy but even 32-bit int div is never better than f64 div, though they're close; also an annoying aspect is that x86 division instrs actually always take a 128-bit divisor, though hopefully a sign-/zero-extended 64-bit value skips the extra work)
brianpaul 1mo ago
Though, if you happen to be dividing by constants, compilers can do a good job of optimizing for that, simd too probably.