I want to modify jhc to take advantage of mutiple CPUs to help mitigate its prodigious computational requirements and was curious how well ghc compiled programs deal with forking? my initial plan is that once jhc determines which modules need to be recompiled, it will fork(2) off processes down each pass that can be done in parallel. however, I have no idea what the effect of just calling fork on the ghc runtime will be. both parent and child will continue on compiling code, so it won't be immediatly followed by an exec. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham wrote:
I want to modify jhc to take advantage of mutiple CPUs to help mitigate its prodigious computational requirements and was curious how well ghc compiled programs deal with forking?
my initial plan is that once jhc determines which modules need to be recompiled, it will fork(2) off processes down each pass that can be done in parallel. however, I have no idea what the effect of just calling fork on the ghc runtime will be. both parent and child will continue on compiling code, so it won't be immediatly followed by an exec.
We provide System.Posix.forkProcess, which is a "controlled" version of fork. It probably works ok in the single-threaded runtime, but I'd say it's probably slightly dubious in the threaded runtime especially if you're planning on using it for more than just fork/exec. POSIX puts some tight restrictions on what you can do in the child of a fork in a multi-threaded process (only async-signal-safe operations may be used). Cheers, Simon
On Wed, Aug 09, 2006 at 10:15:45AM +0100, Simon Marlow wrote:
We provide System.Posix.forkProcess, which is a "controlled" version of fork. It probably works ok in the single-threaded runtime, but I'd say it's probably slightly dubious in the threaded runtime especially if you're planning on using it for more than just fork/exec.
POSIX puts some tight restrictions on what you can do in the child of a fork in a multi-threaded process (only async-signal-safe operations may be used).
Hmm.. sounds fairly complicated. I think I will forgo that and just have jhc exec multiple copies of itself, it is somewhat more inefficient, as it has to reload the data from files, but it allows the possibility of it execing jhc on many different machines, which could be nice. on another topic, I ran across this old paper online which gives an exceedingly clever method of implementing a functional language compiler doing real garbage collection and efficient tail calls in portable C http://home.pipeline.com/~hbaker1/CheneyMTA.html It is very interesting, I think I might implement it as my 'fast to compile' back end for jhc if I can adapt it to a lazy language. John -- John Meacham - ⑆repetae.net⑆john⑈
On Wed, 2006-08-09 at 16:26 -0700, John Meacham wrote:
on another topic, I ran across this old paper online which gives an exceedingly clever method of implementing a functional language compiler doing real garbage collection and efficient tail calls in portable C http://home.pipeline.com/~hbaker1/CheneyMTA.html It is very interesting, I think I might implement it as my 'fast to compile' back end for jhc if I can adapt it to a lazy language.
Not even marginally portable ;( -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
participants (3)
-
John Meacham -
Simon Marlow -
skaller