42 ms·
I don't think this is how you measure clock frequencies. Don't assume each iteration will take once cycle, and divide the time by the number of iterations. In
by alain94040 7y ago
I don't think this is how you measure clock frequencies.
Don't assume each iteration will take once cycle, and divide the time by the number of iterations.
Instead, you measure the time it takes for several loops that are likely to have prime ratios in terms of execution time, and then you figure out the common denominator, which is your clock frequency.
So you never have to do something ugly like:
#ifdef __aarch64__
frequency *= 2; // Many ARM processors need 2 cycles per iteration due to lack or flag renaming and fusion
#endif
- pjc50 7y agoThe cycle time of all the instructions involved is specified in the architecture reference manual. The issue here is that the Intel decoder will fuse "dec %[counter]; jnz cyclemeasure2" into a single instruction. So the Intel loop is doing one cycle per count and the ARM one is two cycles per count.
- alain94040 7y agoThat's not true for any high-end processor from the last 15 years or so. You just can't predict how instructions will interleave and how much parallelism the processor decoder will be able to extract at run-time.
- pjc50 7y agoIn general no, but if you're only using two instructions, subtract and branch, it's feasible. There's only one register involved, so each subtract is always waiting on the previous one and they cannot run in parallel.