runhaskell a parallel program

Neil Mitchell ndmitchell at
Thu May 7 10:12:21 EDT 2009


>> Isn't ghc -e using the byte-code interpreter?
> Yes; apparently it "works", though we still haven't stress-tested it running
> real parallel programs using GHCi with +RTS -N2.

It seemed perfectly stable when I tried, on a few examples I had
knocking around.

>>> Still, parallelism
>>> is about performance, and if you want performance you should start by
>>> compiling your program.
>> This is a test framework that spawns system commands. My guess is the
>> Haskell accounts for a few milliseconds of execution per hour. Running
>> two system commands in parallel gives a massive boost.
> That still doesn't explain why you need +RTS -N2.  You can spawn multiple
> processes by making multiple calls to runProcess or whatever. If you want to
> wait for multiple processes simultaneously, compile with -threaded and use
> forkIO.

I do need to wait for them - so I don't end up firing too many at
once. I was hoping to avoid the compile, which the ghc -e will give

>> A related question I wanted to ask. Is there any way to have my
>> Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At
>> the moment I've set this up with a shell script to translate the -j3,
>> but a nicer method would be preferable. Even something as sledgehammer
>> like as restartWithNProcessors :: Int ->  IO (), which aborted the
>> program entirely and restarted main with a completely fresh heap but a
>> given number of processors.
> We don't have anything like that right now.  Personally I think the shell
> script method is quite reasonable.

My shell script also does -g1, so for the moment it's not too bad. But
for example I added parallel execution to HLint over the weekend - I
don't want to add a shell script to invoke it, and I'm not entirely
comfortable with documenting +RTS -N2 -RTS as the way to -j3 it. If a
nicer way ever turned out to be relatively pain free to implement, it
would be nice. I'll raise a feature request bug.



More information about the Glasgow-haskell-users mailing list