igouy2:
> Ketil Malde writes:
>
> > As for code size, the programs are heavily tuned for speed.
>
> iirc there was a community effort 2 or 3 years ago, but now ghc has
> changed enough that the compiler and runtime parameters seem to need
> re-tuning.
Even longer ago -- some of those 'optimize
Ketil Malde writes:
> As for code size, the programs are heavily tuned for speed.
iirc there was a community effort 2 or 3 years ago, but now ghc has changed
enough that the compiler and runtime parameters seem to need re-tuning.
> Is it an idea to go back a few steps to more idiomatic code?
jason.dusek:
> 2010/04/30 Don Stewart :
> > Prior to the upgrade we weren't mostly beaten on speed, so I think a bit
> > of tuning (ghc -server :) should help.
>
> What do you mean by that? I tried searching the flags page:
>
>
> http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/flag
2010/04/30 Don Stewart :
> Prior to the upgrade we weren't mostly beaten on speed, so I think a bit
> of tuning (ghc -server :) should help.
What do you mean by that? I tried searching the flags page:
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/flag-reference.html
I couldn't
ketil:
>
> Don Stewart writes:
>
> > http://shootout.alioth.debian.org/u64q/haskell.php
>
> Observations:
>
> Although we're mostly beaten on speed, and about the same on code size,
> we're using a lot less memory than Java.
Prior to the upgrade we weren't mostly beaten on speed, so I think a
On Thu, Apr 29, 2010 at 12:38 AM, Ketil Malde wrote:
>
> Don Stewart writes:
>
> > http://shootout.alioth.debian.org/u64q/haskell.php
>
> Observations:
>
> Although we're mostly beaten on speed, and about the same on code size,
> we're using a lot less memory than Java.
>
> As for code size, the
Felipe Lessa writes:
> On Thu, Apr 29, 2010 at 10:54:09AM +0200, Ketil Malde wrote:
>> Anyway - it occurs to me that this can fairly simply be sped up by
>> parallelizing: chunk the input, complement chunks in parallel, and
>> reverse. Any takers?
> Do you mean, something like this?
Yes, that'
On Thu, Apr 29, 2010 at 10:54:09AM +0200, Ketil Malde wrote:
> Anyway - it occurs to me that this can fairly simply be sped up by
> parallelizing: chunk the input, complement chunks in parallel, and
> reverse. Any takers?
Do you mean, something like this?
import Data.ByteString.Char8 as S
im
Ketil Malde writes:
> Is it an idea to go back a few steps to more idiomatic code?
I had a whirl at the 'reverse complement' benchmark, where we're in the
Java ballpark for performance and memory, but at twice the code size.
My simple implmentation is down from seventy to about forty lines,
per
Don Stewart writes:
> http://shootout.alioth.debian.org/u64q/haskell.php
Observations:
Although we're mostly beaten on speed, and about the same on code size,
we're using a lot less memory than Java.
As for code size, the programs are heavily tuned for speed. Although it
is nice to show that
The benchmarks game has been updated to use 6.12.2
Please dive in and help tweak/improve/spot any regressions.
Esp. with respect to multicore flags/options/...
- Forwarded message from Isaac Gouy -
Subject: fyi benchmarks game updated to ghc 6.12.2
http://shootout.alioth.debian.org/u64
11 matches
Mail list logo
