This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, i386] Enable x86_ext_80387_constants for m_K8, m_CORE2 and m_GENERIC64


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.

And povray was a bit faster with this patch ;)

#define rdtsc(value) \
asm volatile("rdtsc":"=A" (value))

int main(int argc, char ** argv)
{
 unsigned long long a,b;
 unsigned short zz;

 rdtsc(a);
 rdtsc(b);
 printf("%lld\n", b-a);

 rdtsc(a);
 asm volatile ("rolw $8, %w0;" : "=q" (zz));
 rdtsc(b);
 printf("%lld\n", b-a);

 rdtsc(a);
 asm volatile ("xchg %b0, %h0;" : "=Q" (zz) : "0" (zz));
 rdtsc(b);
 printf("%lld\n", b-a);

 return 0;
}

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]