Inspired by this post I looked at the language shootout. There is one thing
which strikes me: On
http://shootout.alioth.debian.org/u64/performance.php?test=spectralnorm#about
It sais for the spectralnorm benchmark that both Haskel GHC #4 and HaskellGHC
produce "bad output". For GHC I connt see
On a similar note, there was no parallelized implementation for
spectral-norm, even though Haskell had been doing rather well on the
single-core benchmark. Heh.
Louis Wasserman
wasserman.lo...@gmail.com
http://profiles.google.com/wasserman.louis
On Tue, Jun 1, 2010 at 10:38 AM, Gwern Branwen w
On Tue, Jun 1, 2010 at 10:25 AM, David Leimbach wrote:
> I'm still trying to figure out what the point of the shootout really is. If
> there's no dedicated folks working with a language there, trying to make
> things run faster, a language will come out looking inefficient potentially.
> There's
I'm still trying to figure out what the point of the shootout really is. If
there's no dedicated folks working with a language there, trying to make
things run faster, a language will come out looking inefficient potentially.
There's a lot of compile flags and optimizations that can make a differ
Hey,
I was looking at the reverse-complement benchmark on the Language Shootout,
and among other things, I noticed that the Haskell implementation was using
(filter (/= '\n')) on ByteStrings, and also using lists as queues.
I had a few improvements which using -fasm seem to yield about a 19%
impr
