On 03/09/2011 02:05, Evan Laforge wrote:
Another way to do this would be to have GHC --make invoke itself to
compile each module separately. Actually I think I prefer this method,
although it might be a bit slower since each individual compilation has
to read lots of interface files. The main
Ah, but you're measuring the startup time of ghc --make, which is not the
same as the work that each individual ghc would do if ghc were invoked
separately on each module, for two reasons:
Excellent, sign me up for this plan then :) ghc on a single file is very
quick.
On 01/09/2011 18:02, Evan Laforge wrote:
It's an interesting idea that I hadn't thought of. There would have to be
an atomic file system operation to commit a compiled module - getting that
right could be a bit tricky (compilation isn't deterministic, so the commit
has to be atomic).
I
Hi,
Am Freitag, den 02.09.2011, 09:07 +0100 schrieb Simon Marlow:
On 01/09/2011 18:02, Evan Laforge wrote:
It's an interesting idea that I hadn't thought of. There would have to be
an atomic file system operation to commit a compiled module - getting
that
right could be a bit tricky
Yes, the plan was to eventually have a parallel --make mode.
If that's the goal, wouldn't it be easier to start many ghcs?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
On 1 September 2011 08:44, Evan Laforge qdun...@gmail.com wrote:
Yes, the plan was to eventually have a parallel --make mode.
If that's the goal, wouldn't it be easier to start many ghcs?
Yes. With Scion I'm in the process of moving away from using GHC's
compilation manager (i.e., --make)
On 01/09/2011 08:44, Evan Laforge wrote:
Yes, the plan was to eventually have a parallel --make mode.
If that's the goal, wouldn't it be easier to start many ghcs?
It's an interesting idea that I hadn't thought of. There would have to
be an atomic file system operation to commit a compiled
On Thu, Sep 1, 2011 at 8:49 AM, Simon Marlow marlo...@gmail.com wrote:
On 01/09/2011 08:44, Evan Laforge wrote:
Yes, the plan was to eventually have a parallel --make mode.
If that's the goal, wouldn't it be easier to start many ghcs?
It's an interesting idea that I hadn't thought of.
It's an interesting idea that I hadn't thought of. There would have to be
an atomic file system operation to commit a compiled module - getting that
right could be a bit tricky (compilation isn't deterministic, so the commit
has to be atomic).
I suppose you could just rename it into place
On 30/08/2011 00:42, Thomas Schilling wrote:
The performance problem was due to the use of unsafePerformIO or other
thunk-locking functions. The problem was that such functions can
cause severe performance problems when using a deep stack. The
problem is that these functions need to traverse
On 27 August 2011 09:00, Evan Laforge qdun...@gmail.com wrote:
Right, that's probably the one I mentioned. And I think he was trying
to parallelize ghc internally, so even compiling one file could
parallelize. That would be cool and all, but seems like a lot of work
compared to just
The performance problem was due to the use of unsafePerformIO or other
thunk-locking functions. The problem was that such functions can
cause severe performance problems when using a deep stack. The
problem is that these functions need to traverse the stack to
atomically claim thunks that might
On Mon, Aug 29, 2011 at 1:50 PM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
On 27 August 2011 09:00, Evan Laforge qdun...@gmail.com wrote:
Right, that's probably the one I mentioned. And I think he was trying
to parallelize ghc internally, so even compiling one file could
parallelize.
On 30 August 2011 01:16, Evan Laforge qdun...@gmail.com wrote:
Interesting, maybe I misremembered? Or maybe there was some other guy
who was trying to parallelize?
Just out of curiosity, what benefit does a thread-safe ghc provide? I
know ghc api users have go to some bother to not call
On Sat, Aug 27, 2011 at 5:25 AM, Brandon Moore
brandon_m_mo...@yahoo.com wrote:
I'm confused by this as well. Parallelizing --make was one of the
first case studies in the smp runtime paper, section 7 in
Haskell on a Shared-Memory Multiprocessor
There's also a trac ticket
From what I remember someone tried to parallelize GHC but it turned
out to me tricky in practice. At the moment very trying to parallelize
Cabal which would allow us to build packages/modules in parallel using
ghc -c and let Cabal handle dependency management (including
preprocessing of .hsc
From: Evan Laforge qdun...@gmail.com
Sent: Friday, August 26, 2011 6:35 PM
Subject: Re: GHC build times on newer MacBook Pros?
On Tue, Aug 23, 2011 at 10:24 AM, David Terei davidte...@gmail.com
wrote:
I have a 16 core machine at work (with 48GB of ram, a perk of the job
:)). GHC can
17 matches
Mail list logo
