Dag-Erling Smørgrav wrote:
Alan Cox <a...@cs.rice.edu> writes:
Here is what actually puzzles me about these results. With
traditional I/O, even after the optimizations to bsdgrep, the system
time for gnugrep is still less than half that of the optimized
bsdgrep. I haven't looked at the changes, but I would have thought
the system time for gnugrep and bsdgrep would be almost the same.
Two reasons:
1) BSD grep does tons of unnecessary memory-to-memory copy operations in
grep_fgetln().
2) GNU grep has its own highly optimized regex code.
Umm, not really. Notice that I said "system time" not "user time".
Even after the recent changes to optimize the I/O in bsdgrep, Dimitry's
results show that bsdgrep is spending more than twice as much time in
the kernel as gnugrep. That said, in the end, you may be right in the
sense that the user space inefficiencies may indirectly result in more
cache misses in the kernel because the additional user space memory used
by bsdgrep displaces more kernel data from the cache between system
calls. However, I would not jump to that conclusion. The explanation
for the difference in system time may be more straightforward and easy
to fix.
It would be nice to see a comparison of bsdgrep and gnugrep using
pmcstat to profile L2 cache misses. That might be enlightening.
Alan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
