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
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
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,
I'm trying to add a method to Data.Bits, which requires that I
implement versions for 16 and 32-bit platforms. I was trying to find
some examples to model my code on and randomly picked (==) for Word32.
(==) for Word32 is implemented in terms of stg_eqWord32, but I cannot
find that function de
On Tue, Aug 23, 2011 at 3:40 PM, Johan Tibell wrote:
> Hi,
>
> I'm trying to add a method to Data.Bits, which requires that I
> implement versions for 16 and 32-bit platforms. I was trying to find
> some examples to model my code on and randomly picked (==) for Word32.
> (==) for Word32 is impleme
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
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
Hello,
recent "GHC build times on newer MacBook Pros?" thread makes me
wondering if someone already attempted to build GHC on a cluster of
machines using for example PVM GNU make[1] for this or any other tool (
or even custom generated bin/ghc-stageX scripts using rsh?) which is
suitable for
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
Edward,
On first glance at your email I misunderstood you as asking about using
GHC's optimizer as a source-to-source operation (using GHC as an optimizer,
retrieving "partially evaluated" Haskell code). That's not what you were
asking for -- but is it possible?
-Ryan
P.S. One compiler that
An Array# of size zero is a perfectly reasonable thing. If it doesn't
work, it should (and I vaguely recall making it work at some point in
the past, but perhaps I failed to add a test and as a result it has
rotted...)
Cheers,
Simon
On 22/08/11 17:08, Johan Tibell wrote:
I agree (un
It could well be that it's some later primop that's failing due to the
empty size, like my new copyArray# primop. If that's the case I could
fix it but I would probably would have to add a branch to the
copyArray# primop, which I'm reluctant to do.
On Tue, Aug 23, 2011 at 9:47 PM, Simon Marlow wr
You could make it a precondition of copyArray#, although that's slightly
less pleasant from a user's perspective.
Cheers,
Simon
On 23/08/11 21:04, Johan Tibell wrote:
It could well be that it's some later primop that's failing due to the
empty size, like my new copyArray# primop. If th
Right. That's an option.
On Tue, Aug 23, 2011 at 10:31 PM, Simon Marlow wrote:
> You could make it a precondition of copyArray#, although that's slightly
> less pleasant from a user's perspective.
>
> Cheers,
> Simon
>
> On 23/08/11 21:04, Johan Tibell wrote:
>>
>> It could well be that it
Since most of GHC's optimizations occur on core, not the user-friendly
frontend language, doing so would be probably be nontrivial (e.g.
we'd want some sort of core to Haskell decompiler.)
Edward
Excerpts from Ryan Newton's message of Tue Aug 23 13:46:45 -0400 2011:
> Edward,
>
> On first glance
15 matches
Mail list logo