hmm, how much work do you think that would take? Does the current MLTon
thread library take advantage of real threading?
Once, I get my box, I'm more than happy to do some hacking if it is a
resonable amount of work.
Stephen Weeks wrote:
>>Anway, I was wondering is there any quick and dirty way for MLton to
>>take advantage of that extra core...
>>>>>...
>>>>Is there maybe some way to at least pipe-line the compilaition process,
>>such that the frontend is in one thread spit outing code for the rest of
>>the backend to compile and optimize.
>>>>>>Things don't get easily parallelizable until the code generator, which
>does a lot more local stuff than earlier passes. Since native code
>generation takes a big chunk of compile time (~50% for a self
>compile), this could help some. Even easier would be to parallelize
>the calls to gcc when using the C codegen. As the C codegen is even
>slower than the native codegen, parallelization there could help even
>more. But then we already have a native codegen for x86, so this only
>really helps on other platforms that are going multicore where we
>don't have a native codegen.
>>