Live data from Hacker News

Why GNU grep is fast (2010)

lists.freebsd.org

81–90 of 133 posts

Re: Why GNU grep is fast (2010)

#81

Earlier quoted context omitted.

The fastest programs return 0 immediately and don't do shit.

Returning 0 is technically doing something. It might not be something that you find useful but it is something.

> Returning 0 is technically doing something.

Yeah, but try telling your boss that :)

Re: Why GNU grep is fast (2010)

#82

Earlier quoted context omitted.

In the past, there were semi-automated accounts that did this, but they made more people upset than happy. I would also prefer to see this happen on every story.

hey hey hey, if you want hacker news to stay fast you should't make it do too much!

Stay? When was HN ever fast? It's a tech demo for a language that's been more-or-less abandoned, that accidentally grew into a popular website.

Re: Why GNU grep is fast (2010)

#83

The fastest programs are the ones that don't prepare themselves to do something and then don't do that thing. Another way to say just do one thing well.

Well not really because the "do one thing well" leads to shell scripting where you join together dozens of separate tiny programs. Shell scripting is not exactly fast, nor is it robust.

Re: Why GNU grep is fast (2010)

#84
post #60

I'm actually more familiar with the KMP algorithm than BM. So I looked it up to see what the difference was: The classic Boyer-Moore algorithm suffers from the phenomenon that it tends not to work so efficiently on small alphabets like DNA. The skip distance tends to stop growing with the pattern length because substrings re-occur frequently. By remembering more of what has already been matched, one can get larger sk…

You would inspect characters multiple times only in a very naive implementation of Boyer-Moore. The Galil Rule[0] fixes this and is also required for proving linear worst-case runtime.

[0] https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string_sea...

Re: Why GNU grep is fast (2010)

#85

Does this still work in Unicode? It seems like it'd cause the Boyer-Moore lookup tables to blow up in size.

You can use Unicode code points for the shift table(s -- the Horspool variant has only one table) but make them sparse, that way the tables only contain characters that exist in the pattern. Hash tables make for easy lookups, but with a bit blob of a few hundred kB you can also use a bitmask.

Of course, you can also just reduce the Unicode pattern to bytes, so your alphabet is never larger than 256. This will run slower, but not as much as you'd think: Boyer-Moore does benefit from larger alphabets, but only to the extent that the alphabet is actually used.

Re: Why GNU grep is fast (2010)

#86
post #45

The inverse is this...what is modern software doing that makes them so slow?

> GNU grep also tried very hard to set things up so that the kernel could ALSO avoid handling every byte of the input, by using mmap() instead of read() for file input. At the time, using read() caused most Unix versions to do extra copying.

Good luck pulling this off in Chrome.

Re: Why GNU grep is fast (2010)

#90
post #74

Earlier quoted context omitted.

I'd imagine the fastest programs don't always return 0, since that's an extra MOV instruction.

$ touch foo $ chmod +x foo $ ./foo $ echo $? 0

For me, the trivial C program appears to run faster than the empty file:

    $ touch empty
    $ chmod +x empty
    $ time ./empty

    real    0m0.002s
    user    0m0.000s
    sys     0m0.000s

    $ echo "int main(){return 0;}" > trivial.c
    $ gcc trivial.c -o trivial
    $ time ./trivial

    real    0m0.001s
    user    0m0.000s
    sys     0m0.000s
Timing results are consistent over several repetitions (provided everything's in cache from disk). Linux x86_64. `mov` takes ten thousand to a million times less than a millisecond ( https://gist.github.com/jboner/2841832 ), so I can't find out this way whether removing 'return 0' changes anything.

(If I use my default zsh shell to execute ./empty, it gives me

    zsh: exec format error: ./empty
    ./empty  0.00s user 0.00s system 0% cpu 0.008 total
So I used bash for this.)
Post reply on HN