Hi
>> 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
me.
>> 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.
Thanks
Neil