Dag-Erling Smørgrav wrote: > Alan Cox <alc_at_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. AlanReceived on Mon Aug 23 2010 - 15:52:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:06 UTC