> 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 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 G
>> 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 GHC --make process would do
>> t
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
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 suppo
>> 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 i
On Thu, Sep 1, 2011 at 8:49 AM, Simon Marlow 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. There
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 compile
On 1 September 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?
Yes. With Scion I'm in the process of moving away from using GHC's
compilation manager (i.e., --make) towards a multi-p
> 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
http://www.haskell.org/mailman/listinfo/glasgow-haskell
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 th
On 30 August 2011 01:16, Evan Laforge 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 re-entrantly...
On Mon, Aug 29, 2011 at 1:50 PM, Max Bolingbroke
wrote:
> On 27 August 2011 09:00, Evan Laforge 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 seem
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 b
On 27 August 2011 09:00, Evan Laforge 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 parallelizing at the f
> 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 .
On Sat, Aug 27, 2011 at 5:25 AM, Brandon Moore
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
> http://hackage.haskell.org/trac/ghc/tic
> From: Evan Laforge
> 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
> wrote:
>> I have a 16 core machine at work (with 48GB of ram, a perk of the job
>> :)).
On Tue, Aug 23, 2011 at 10:24 AM, David Terei wrote:
> I have a 16 core machine at work (with 48GB of ram, a perk of the job
> :)). GHC can saturate them all. Can validate GHC in well under 10
> minutes on it.
To wander a bit from the topic, when I first saw this I thought "wow,
ghc builds in par
I have a 16 core machine at work (with 48GB of ram, a perk of the job
:)). GHC can saturate them all. Can validate GHC in well under 10
minutes on it.
I also just got the 15" core i7 2.3GHz less then a week ago, it's a
very nice machine so I would recommend it. But yeah just getting the
2.2GHz is
Sounds promising. Now I just have to decide whether to get the 2.2 or
2.3 GHz version. I suspect the latter is a bit overpriced.
On Tue, Aug 23, 2011 at 4:36 PM, austin seipp wrote:
> I'm using a MBP with a quad core 2gHz Core i7; it has 8 overall
> hardware threads. GHC's build process using 'ma
I'm using a MBP with a quad core 2gHz Core i7; it has 8 overall
hardware threads. GHC's build process using 'make -j9' or 'make -j12'
totally saturates all my cores. I believe I can clock in a full build
at well under 10 minutes (with BuildFlavor = quick in mk/build.mk.)
For comparison, I also have
On 23 August 2011 10:27, Johan Tibell wrote:
> but I don't know if I can get enough parallelism out of GHC's build to
> use all 4 cores in the 15" model.
You can. On my Mac Pro I build with -j12 and regularly see all 8 cores
pegged at 100%.
Max
___
Gl
Hi,
go for 4 cores if the price is not prohibitive. I'm using Q6600 here and
all cores are quite busy except for the configuration and compilations
which is done by cabal (if only this cabal would be parallel too!). On
ARM/Linux -- 2 cores cortex-a9 (OMAP4430) I've noticed that sometimes
bui
Hi!
I'm looking to upgrade my laptop so that I can (among other things)
compile GHC faster. I'll either get the 13" 2.7GHz dual-core Intel
Core i7 model or the 15" 2.2GHz quad-core Intel Core i7 model. Anyone
know if it's worth to get the 15" model? According to these benchmarks
it should be quite
25 matches
Mail list logo
