Parallel thoughts

[Michael G Schwern]

Eric Wilhelm wrote:
> it would be nice to just make the grammar run faster and quit trying to
> throw cores at it.

There's a common development fallacy that development is a zero-sum game.  The
"either/or" fallacy:  EITHER we speed up the grammar OR we develop parallel
processing.

There's no reason we can't do both.  Arguing about which is "better" as if
it's a zero-sum game is silly.


> I realize the below implementation is an oversimplification, but given 
> that we seem to be stuck on the subject of the parser speed, I think it 
> is worth noting that "parses_tap.pl" parses the Regexp::Common archive 
> in 0.4s while the `runtests -r --exec cat $spooldir` takes 38s.  That's 
> missing some features, but it's about 7500% faster.
> 
>   http://scratchcomputing.com/tmp/parses_tap.pl
> 
> Does it have 7500% more features?

As a lower performance bound that's an interesting exercise, but to make any
performance projections about a full TAP grammar with extendability and
customizable display is dangerous.  Sort of like taking two data points and
drawing a 50 year projection off of it.

Devil's in the details when it comes to TAP (and software).  It's all too easy
to slap together a fast prototype doing "80%" of the features while ignoring
that the last 20% takes 80% of the effort.  Also error handling.

Handling pluggable grammars, directives, descriptions, TODO tests, SKIP tests,
future directives, plans at the end, bailouts, not to mention customizable
display of results, error handling, parallel processing, selective execution
of tests, switch processing and TAP archive handling... that adds up to about
7500%. :)

A more useful performance comparison would be to take a look at a some of the
existing, complete, simpler TAP parsers like Test::Harness and t/TEST.  We've
already shown we can match or beat Test::Harness under the worst conditions
(Regexp::Common) AND do a better job of it.

Finally, don't go crazy optimizing a pathological case.  Andy's right, for the
vast majority of current testing the bottleneck is the test, not the parser.
Regexp::Common is a very special case, and we're doing a good job with it.  In
the future, when running TAP archives becomes more common, then we can focus
more on the parser.

But right now throwing cores at it seems to work pretty well.

So now Eric and Andy can switch places.  Eric will work on the grammar
performance for a while and Andy will do the parallel stuff. :)


-- 
Stabbing you in the face for your own good.