in some respects, having fully deterministic builds is a very important goal: a lot of tooling for eg, caching builds of libraries works much much better if you have that property :) 

On Tue, Oct 7, 2014 at 12:45 PM, <p.k.f.holzenspies@utwente.nl> wrote:

________________________________________
From: mad.one@gmail.com <mad.one@gmail.com> on behalf of Austin Seipp <austin@well-typed.com>

So I assume your change would mean 'ghc -j' would not work for 32bit.
I still consider this a big limitation, one which is only due to an
implementation detail. But we need to confirm this will actually fix
any bottlenecks first though before getting to that point.




Yes, that's what I'm saying.

Let me just add that what I'm proposing by no means prohibits or hinders making 32-bit GHC-versions be parallel later on, it just doesn't solve the problem. It depends to what extent the "fully deterministic behaviour" bug is considered a priority (there was something about parts of the hi-files being non-deterministic across different executions of GHC; don't recall the details).

Anyhow, the work I'm doing now exposes a few things about Uniques that confuse me a little and that could have been bugs (that maybe never acted up). Extended e-mail to follow later on.

Ph.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs