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.
Yeah, but try telling your boss that :)
81–90 of 133 posts
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.
Yeah, but try telling your boss that :)
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!
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.
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…
[0] https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string_sea...
Does this still work in Unicode? It seems like it'd cause the Boyer-Moore lookup tables to blow up in size.
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.
The inverse is this...what is modern software doing that makes them so slow?
Good luck pulling this off in Chrome.
Impressive, but if the goal is for BSD to have a faster grep then clearly the solution is to use GNU grep instead of rolling their own redundant and inferior clone.
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
$ 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.)