[Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-05-05 Thread Isaac Gouy
Ketil Malde ketil at malde.org 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?  Perhaps as a 
 separate track? 

There's always room for 2 or 3 Haskell programs per task - not necessarily The 
Good, the Bad and the Ugly - but you'll already find the cliched example of a 
faster more convoluted Haskell program and a more concise but slower Haskell 
program.

(Idiomatic code? Aren't there idioms for writing fast Haskell too?) 


 I also worry a bit that source code optimization for a specific
 compiler makes it more difficult to take advantage of compiler
 optimization improvements. 

These are tiny tiny programs - when those compiler optimization improvements 
arrive re-write the programs to take advantage of them ;-)


  

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-05-05 Thread Don Stewart
igouy2:
 Ketil Malde ketil at malde.org 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 'optimized' programs date to 2005 if I
recall.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-05-01 Thread Jason Dusek
2010/04/30 Don Stewart d...@galois.com:
 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 find a server flag.

--
Jason Dusek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-05-01 Thread Don Stewart
jason.dusek:
 2010/04/30 Don Stewart d...@galois.com:
  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 find a server flag.

Java has a server flag, sort of like defaulting to -H1G -N4 etc.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-30 Thread Don Stewart
ketil:
 
 Don Stewart d...@galois.com 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 bit
of tuning (ghc -server :) should help.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-29 Thread Ketil Malde

Don Stewart d...@galois.com 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 we can indeed be fast, Haskell's forte is being
almost as fast while clear and compact.  Is it an idea to go back a few
steps to more idiomatic code?  Perhaps as a separate track?  I also
worry a bit that source code optimization for a specific compiler makes
it more difficult to take advantage of compiler optimization
improvements. 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-29 Thread Ketil Malde
Ketil Malde ke...@malde.org 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,
perhaps thirty-five if I remove comments etc.  The bad news is that it's
about twice as slow, my benchmark takes about 0.45s vs 0.25 for the
shootout entry.

One interesting observation is that 'map' from Data.ByteString working
directly on Word8 is actually *slower* than 'map' from
Data.ByteString.Char8.

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?

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-29 Thread Felipe Lessa
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
  import Data.ByteString.Lazy.Char8 as L
  import Data.ByteString.Lazy.Internal as LI

  map' :: (Char - Char) - L.ByteString - L.ByteString
  map' f = go
where
  go LI.Empty= LI.Empty
  go (LI.Chunk x xs) = let fx  = S.map f x
   fxs = go xs
   in fxs `par` LI.Chunk fx fxs
   -- Chunk is strict in fx.

Cheers,

--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-29 Thread Ketil Malde
Felipe Lessa felipe.le...@gmail.com 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's exactly what I mean (you also need to reverse each chunk for
this particular problem). 

Of course, it remains to see how well it performs in practice - it's not
something I would expect to get right at the first attempt (I haven't
used parallelism much so far).

Several of the shootout benchmarks suffer from using only one CPU, so
given Haskell/GHCs claim for easy concurrency, there should be some
relatively low-hanging fruit there.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-29 Thread Jason Dagit
On Thu, Apr 29, 2010 at 12:38 AM, Ketil Malde ke...@malde.org wrote:


 Don Stewart d...@galois.com 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 we can indeed be fast, Haskell's forte is being
 almost as fast while clear and compact.  Is it an idea to go back a few
 steps to more idiomatic code?  Perhaps as a separate track?  I also
 worry a bit that source code optimization for a specific compiler makes
 it more difficult to take advantage of compiler optimization
 improvements.


I was thinking the same thing with regard to the code being idiomatic
Haskell.  Then I took a look at the top entry (in GCC C), which has special
malloc/free functions to achieve cache alignment.  Then I realized just how
nice the current Haskell version is :)

Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-28 Thread Don Stewart
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/u64q/haskell.php

best wishes, Isaac

- End forwarded message -
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe