Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why GNU grep is fast (2010)

lists.freebsd.org

Post reply on HN
Print view View original

111–120 of 133 posts

Re: Why GNU grep is fast (2010)

#111

Post by Danieru »

noonespecial wrote: post #79
badman_ting wrote: post #63

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.

On unix you'll find two programs which do this exact thing: `false` and `true`. False returns 1, and true returns 0.

You might not believe that these are real programs but they are. You can find the binaries using `whereis`. For example on my linux install true is /bin/true.

The command line is pretty awesome.

Re: Why GNU grep is fast (2010)

#112

Post by jamesaguilar »

snogglethorpe wrote: post #108
jtmcmc wrote: post #88

Earlier quoted context omitted.

presumably GNU grep is GPL and incompatible with their BSD license

The GNU GPL is perfectly compatible with their BSD license... :] It's just that the end result is then restricted by the GPL, and they don't want that.

That is what "not compatible" means.

Re: Why GNU grep is fast (2010)

#113

Post by jamesaguilar »

weland wrote: post #86
bane wrote: 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.

With nacl, you could. But I think you're talking about js, and yeah, you are right.

Re: Why GNU grep is fast (2010)

#114

Post by derekp7 »

idupree wrote: post #90
tsm wrote: post #74

Earlier quoted context omitted.

$ 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 tho…

So here's what happens with empty. If you run it from the shell, first the shell will fork, then try to exec empty. But the exec fails, since empty doesn't begin with a magic value. Therefore the exec call returns an error. Now the shell picks up this error, and then tries to run the program again, this time as an argument to an invocation of the shell (i.e., it does an exec of /bin/bash, passing it "empty" as a parameter). This is why empty ends up taking longer to run.

This is the normal pattern, just in case you forget to put "#!/bin/bash" at the top of the script, so that the script can be run anyway. This is also a source of confusion for some sysadmins, when a script works from the command line but not from something like a cron script.

Re: Why GNU grep is fast (2010)

#115

Post by eru »

pmiller2 wrote: post #62
eru wrote: post #15

Earlier quoted context omitted.

You will need some gnu common libraries. I tried building it from scratch recently, as a first step for implementing an extension idea, but didn't succeed. (If anyone is interested, I want to add more operators, like intersection or difference of regular languages.)

The shell, combined with grep already implements these intersection and difference operators. For intersection, all you have to do is pipe into a second grep [1]; for difference, you pipe into a second grep with -v [2]. [1] Intersection: grep regex1 file1 | grep regex2 [2] Difference: grep regex1 file1 | grep -v regex2

Yes, you can do that. But you can only do that at the top level of your expression (ie outside the expression), not intra regular expression.

Re: Why GNU grep is fast (2010)

#116

Post by brongondwana »

badman_ting wrote: post #81
noonespecial wrote: post #79

Earlier quoted context omitted.

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 :)

Yep, boss will turn right around and "do" paying your salary

Re: Why GNU grep is fast (2010)

#117

Post by dalke »

dalke wrote: post #110
nostrademons wrote: post #57

Earlier quoted context omitted.

I think Kent was being sarcastic - his point is that it's rather pointless to optimize until the system is producing correct results. He's also famous for the "Make it work, make it right, make it fast" quote.

Are you sure he's the source of the quote? A quick scholar.google.com search found a match in Byte magazine from 1983: > Furthermore, many C environments contain measurement tools that enable the programmer to identify these critical sections easily. But the strategy is definitely: first make it work, then make it right, and, finally, make it fast. The Google URL is http://books.google.com/books?ei=dtOXUoCVHoegkAef9Y…

Looks like I'm wrong about the attribution. It's in the article "The C Language and Models for Systems Programming" by Johnson and Kernighan.

Re: Why GNU grep is fast (2010)

#118

Post by snogglethorpe »

jamesaguilar wrote: post #112
snogglethorpe wrote: post #108

Earlier quoted context omitted.

The GNU GPL is perfectly compatible with their BSD license... :] It's just that the end result is then restricted by the GPL, and they don't want that.

That is what "not compatible" means.

You can release some software that contains both GNU GPL and BSD-licensed code, and it will be legal to distribute as long as you follow the rules of both licenses; as the rules of these licenses do not conflict, there's no legal problem.

This is what most people mean when they say two FOSS licenses are "compatible."

Post reply on HN