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