On 11/26/06, Roger Sayle <roger@eyesopen.com> wrote:
> For CPU tuning patches, I wonder if you could also post timing on some
> trivial microbenchmark, when possible, to confirm that the published cycle
> counts are representative and not dominated by other timing issues (decode
> paths, pipeline stalls, memory latency, etc...) so that we can confirm at
> least some piece of code will be faster on some CPU in practice.
> Compiler tuning is often more of an art than a science :-)
Following code can be used to measure latencies of _integer_
instructions (perhaps the approach will be of general interest,
otherwise it is an example of xchg vs rolw timings), but the results
for FP instructions are totally unpredictable (due to
out-of-order-execution of FP insns I guess). So for FP, there is no
other way than to benchmark several million loops of instructions.