Messages in this thread | | | Date | Mon, 15 Sep 1997 19:21:52 +0200 | From | Harald Koenig <> | Subject | Re: 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] | |