Parallel search in Perl and other languages

[Peter J. Holzer]

I seem to be completely unable to find the right keywords to feed into
google, but I vaguely remember that it was mentioned in this group, so
I'm asking here in the hope that somebody has better memory than me:

Some guy has programmed a relatively simple task (I'm almost but not
quite sure it was a search in a file) using multiple processes/threads
in several languages to show that even for such tasks multiprocessing
gives you better performance. Other people contributed equivalent
programs in other languages, so he now has a nice collection of one or
two dozen implementations of the same task in different languages. Last
time I looked, the Perl implementation was the fastest.

Does anyone remember this, and if so, did you bychance bookmark the
site?

hp

 

[J. Gleixner]

I seem to be completely unable to find the right keywords to feed into
google, but I vaguely remember that it was mentioned in this group, so
I'm asking here in the hope that somebody has better memory than me:

Some guy has programmed a relatively simple task (I'm almost but not
quite sure it was a search in a file) using multiple processes/threads
in several languages to show that even for such tasks multiprocessing
gives you better performance. Other people contributed equivalent
programs in other languages, so he now has a nice collection of one or
two dozen implementations of the same task in different languages. Last
time I looked, the Perl implementation was the fastest.

Does anyone remember this, and if so, did you bychance bookmark the
site?

Is this what you're looking for?

Wide Finder Project

http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results

 

[Peter J. Holzer]

Is this what you're looking for?

Wide Finder Project

http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results

Yes, that's it.

Thanks a lot,

hp

 

[John Bokma]

Wide Finder Project

http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results

Thanks, and thanks Peter for reminding me of a site I /should have/
bookmarked (or better: added to my local wiki).

 

[Peter J. Holzer]

Peter J. Holzer wrote: [WideFinder]

Other people contributed equivalent programs in other languages, so
he now has a nice collection of one or two dozen implementations of
the same task in different languages. Last time I looked, the Perl
implementation was the fastest.

Hard to imagine perl winning for execution speed on any task.

Give the programmer a deadline (like "I need that by tomorrow") and perl
is frequently faster than some nominally faster programming language,
because the perl programmer needs to spend less time with "housekeeping"
and can spend more time finding a better algorithm.

In the case of searching and matching (what WideFinder does), the main
factor for performance is the speed of the RegEx engine (and perl's is
apparently quite fast for many cases).

The benchmarks game site [...]
http://shootout.alioth.debian.org/gp4/index.php

[...]

These are a lot of fun but not very relevant for the real world. Almost
all of the benchmarks focus on specific operations, not on doing a task.

has a couple of multi-thread tests where perl does much worse than
most other languages.

If you think you need to use threads in Perl, think again .

Those results aren't totally optimized. perl results are not
using pp,

How would pp make perl faster? It's not a compiler, just a packager.

hp

 

[Isaac Gouy]

-snip-

Thebenchmarks gamesite [...]
http://shootout.alioth.debian.org/gp4/index.php

[...]

These are a lot of fun but not very relevant for the real world. Almost
all of the benchmarks focus on specific operations, not on doing a task.

"Almost all of the benchmarks focus on specific operations..." ?

The focus on specific operations was perhaps apparent in Doug Bagley's
2001 "The Great Computer Language Shootout"

http://web.archive.org/web/20010124090400/http://www.bagley.org/~doug/shootout/


Take the trouble to count how many of the benchmarks in the current
benchmarks game "focus on specific operations, not on doing a task". A
ridiculously broad interpretation of "specific operations" still comes
in around 70% - nothing like "Almost all".


The obvious criticism is that *all* the programs are minuscule
compared to the programs we work on, and we shouldn't just assume that
what's true of minuscule programs would be true of larger programs.