lkml.org 
[lkml]   [1997]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Pentium __delay weirdness... the final results (longish)
On Sep 12, Gordon Oliver wrote:

> Here's the final summary all numbers are in cycles as reported by rdtsc.
> This is using a set of assembly that executes the entire timing loop twice,
> in an effort to get the caching right.

for my Intel PODP83 things are different (worse) which is why I started
this whole thread...

> ---------------------------Normal loop----------------------------------
>
> 2: decl %eax
> jns 2b
>
> offset of label 2:
> 0-9 6*loop_count + overhead
> 10-4092 5*loop_count + overhead
> 4093-4095 2*loop_count + overhead

offset of label 2:
0-7 6*loop_count + overhead

offset mod 8 of label 2 for offset > 8:
0-1 6*loop_count + overhead
2-4 5*loop_count + overhead
5-7 2*loop_count + overhead


> ---------------------------Nop loop-------------------------------------
>
> 2: decl %eax
> nop
> jns 2b
>
> offset of label 2:
> 0-9 3*loop_count + overhead
> 10-4095 2*loop_count + overhead

offset of label 2:
0-7 3*loop_count + overhead

offset mod 8 of label 2 for offset > 8:
0-1 3*loop_count + overhead
2-7 2*loop_count + overhead

> --------------------
> Solution 1: add align 4 to __delay. This would leave a 20% variation in the
> possible delay values, but at least there isn't a 3 times variation.
> The nop should not be put in the loop, as the percentage variation
> jumps to 50% in this case.
>
> Solution 2: make __delay not be an inline function. That way it should not
> cause problems as it will _always_ be at the same offset.
>
> Solution 3: make __delay not be an inline function, and also have it use
> rdtsc when available (this idea is from H. Peter Anvin). This means
> adding some sort of check for rdtsc and using a function pointer
> to choose the appropriate delay. As long as there are fewer bugs
> in rdtsc than in jump prediction this will be a win (seems likely).

I'd prefer #2 and #3 as long as I don't know a good reason for using
__delay as inline function.

> ---------------------
> Details. The entire timing loop.
>
> For the nop case, the nop is moved from after the sti to after the
> decl %eax. In each case the size of the timing loop, plus code to save the
> address and difference is exactly 47 bytes. Repeated 4096 times, this gives
> every possible offset mod 4096.

which gcc options did you use for compilation of the generated asm file ?
using gcc-2.7.2.1 without any options I don't get all possible offsets.
check with

awk '{print $1}' gendelay.out | sort -n | uniq -c | sort -r | more

that some offsets show up twice (for me: 1418, 1459, 1500 ... 1992)


and what's the number in the 4th column (1st %f) ?

I've attached both output files (w/o and with nop in the loop)...


Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
[unhandled content-type:application/x-gunzip][unhandled content-type:application/x-gunzip]
\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.051 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site