jack@boring.UUCP (08/21/85)
I'm posting this to unix-wizards too, since I can't pin the problem on 'bm', so there might be something funny going on in the V7 kernel. I observed some very weird behaviour of the Boyer Moore program posted to net.sources recently. The problem is: user time is significantly less than that of grep, but system time is preposterous. Times are as follows, on an 11/34, running more-or-less v7m, 1Mb, Ampex Capricorn: --- + time bm Zurich /usr/dict/words Zurich real 1:00.0 user 3.5 sys 42.7 + time fgrep Zurich /usr/dict/words Zurich real 33.0 user 18.5 sys 6.6 + time grep Zurich /usr/dict/words Zurich real 22.0 user 11.2 sys 6.4 --- I tried fiddling with the buffer size being read (512,1024,2048), but timing stays the same. Also, profiling shows that the program spends 90% of the time in read(), so there are no other system calls that could account for the time difference. So, what is going on that's making bm 8 times slower than everyone else? Anyone out there who can give me a hint on where to look? -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
ron@unrvax.UUCP (Ron Sheen) (08/22/85)
We also found bm to be slow under 2.9. The problem is that bm
reads from its input file into a buffer at possibly and odd
address and possibly (usually) not a multiple of 512 bytes.
The following changes brought bm's performance more in line
with what was expected:
In Execute.c:
line 42 reads from the input file into Buffer, change:
read(TextFile,Buffer + ResSize + NRead, NWanted);
to:
read(TextFile,Buffer + ResSize + NRead, (NWanted>>9)<<9);
In MoveResidue.c:
lines 29-31 move the residue in Buffer to the beginning of buffer.
t=Buffer; f=Residue;
for(i=ResSize;i;i--)
*t++ = *f++;
add the following to insure the next read occurs on a word boundary:
/* check if next word is at an odd address */
if((int) (t - Buffer) & 1) {
*t = '\0';
ResSize++;
}
Ron Sheen
seismo!unr70!ron