Benchmarks game updated to ghc 6.12.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Benchmarks game updated to ghc 6.12.2

Don Stewart-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Simon Marlow-7
On 28/04/10 21:05, Don Stewart wrote:
> 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/...

chameneos is using -N5, which is probably killing it.

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Ketil Malde-5
In reply to this post by Don Stewart-2

Don Stewart <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Ketil Malde-5
Ketil Malde <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Ketil Malde-5
Felipe Lessa <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Jason Dagit-2
In reply to this post by Ketil Malde-5


On Thu, Apr 29, 2010 at 12:38 AM, Ketil Malde <[hidden email]> wrote:
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Don Stewart-2
In reply to this post by Ketil Malde-5
ketil:
>
> Don Stewart <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Jason Dusek
2010/04/30 Don Stewart <[hidden email]>:
> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Benchmarks game updated to ghc 6.12.2

Don Stewart-2
jason.dusek:
> 2010/04/30 Don Stewart <[hidden email]>:
> > 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe