Parallel thoughts

Eric Wilhelm scratchcomputing at gmail.com
Tue Oct 2 03:37:39 BST 2007


# from Andy Armstrong
# on Monday 01 October 2007 14:41:

>2) Multiplexed parsers.
>3) Forked parsers

>The problem with 2 is that all the parsing is still happening in a
>single process. This bottleneck gets worse as you throw more cores at
>the problem.

This "drawback" is also a benefit if you look at it WRT callbacks and 
other things not having to deal with the forks and/or storable.

The problem with #3 is that you cannot distribute it across machines 
without having (matching) Storable and TAP::Parser installed on the 
nodes.  There's probably also something to do with running a different 
perl version as the harness vs the tests.

If you look at it from the POV of parsing an archive (rather than 
running a harness) I would think multi-threading would be the way to go 
to speed-up the parsing process, otherwise I would guess that IPC 
becomes a real PITA and everything gets really complicated.  Of course, 
it would be nice to just make the grammar run faster and quit trying to 
throw cores at it.

Why is the multiplexer not a subclass of TAP::Harness?

--Eric
-- 
We who cut mere stones must always be envisioning cathedrals.
--Quarry worker's creed
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------


More information about the tapx-dev mailing list