From: nowhere@nospicedham.never.at   
      
   what I think about benchmarks (one more time):   
      
   iterative runs of any  piece of code is senseless, results are just   
   background noise from OS.   
      
   benchmarks from one tool will never match any other, so all these   
   reported values look suspicious random to me.   
      
   And where is the practical use of such test loops ?   
   most code under test may run frequently but rare as a loop,   
      
      
   my solution produces reproducible (max 1 cycle deviation) results even   
   if just testing a single instruction. I check only a few times but I use   
   my own OS with my own debugger (it's short and got no PL issues)**:   
      
   1. WBINV   
       JMP near test (forward)   
      
   test:   
       ALIGN for code under test starts aligned (cache bounds)   
       CLI   
       RDTSC and store eax:edx in ecx:ebx (this shows constant timing)   
      
       code under test is here (but keep ecx:ebx or two others alive)   
      
       RDTSC sub eax:edx, ecx:ebx  (time result is in eax:edx yet)   
       STI   
       RET (to my debugger, code under test remain cached)   
       read the result   
      
   2. start the test again without WBINV and JMP.   
       read the result   
      
   3. play with alignment and run step 1 & 2 again to compare with   
       previous reads (only a few times anyway).   
      
   ** I always test within PL0, so my results may differ from those run at   
   lesser PL.   
      
   this works well for short code parts that fit a cache line, for larger   
   function blocks I call the test-code and store temporary TSC in memory.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)