4 ms·
A lot of it generally holds true if you're programming for x86/x64, ARM, or PowerPC. The "hierarchy of speed" could use some updating, I think these days it is
by maximilianburke 12y ago
A lot of it generally holds true if you're programming for x86/x64, ARM, or PowerPC. The "hierarchy of speed" could use some updating, I think these days it is more along the lines of:
1. Comparisons (no branch, just compare)
2. u/int add/subtract/bit operations
3. FP mul
4. FP add/sub
5. FP div
6. u/int mul
7. indexed array access (data in L1, including latency for data to move to registers)
8. u/int div
That rough order seems to generally hold on a modern Haswell processor or the in-order PowerPC cores in an Xbox 360, though the cycle counts will vary.
Being thoughtful with respect how you access your data, paying attention to the effects of access patterns on caching, will almost always help regardless of the target architecture :)
- nkurz 12y ago1. Comparisons (no branch, just compare) 2. u/int add/subtract/bit operations Is there a reason you follow Andrei's lead and suggest that comparisons operations are faster than integer subtraction? At least for x64 on Intel, I think they would always be the same speed and thus should be grouped together. Are they different on the other platforms?
- mattgodbolt 12y agoThe only justification I can think of for that statement is that on modern processors (Sandy Bridge and above), micro-op fusion in the decode stage can fuse a comparison with a branch that immediately follows it, turning it into a "compare and branch" micro-op.
- spc476 12y agoOne possibility: the compare only updates one register (flags), not two (flags and the destination register).