--- Ketil Malde [EMAIL PROTECTED] wrote:
Isaac Gouy [EMAIL PROTECTED] writes:
Programmer skill and effort really does matter ;-)
Yes, more so, than any inherent language
disadvantage, perhaps, which
happens to be the general lesson from the ICFP
contests as well. Any
idea if other
Joel Koerwer wrote:
Don, that's a great little mini tutorial, exactly what I was hoping for.
I'm looking forward to learning more tricks.
On an unrelated note, I have an STUArray nbody. I haven't really looked
closely at the chris+dons version, but I suspect they amount to doing
the same
haskell:
Joel Koerwer wrote:
Don, that's a great little mini tutorial, exactly what I was hoping for.
I'm looking forward to learning more tricks.
On an unrelated note, I have an STUArray nbody. I haven't really looked
closely at the chris+dons version, but I suspect they amount to
Hey this is great. Chris your improvements are awesome. I mean the
speed is nice, but you really cleaned up the code.
There's an extraneous call to energy in the second runST block, but it
should be insignificant. Also, -fglasgow-exts is necessary for the
left-hand-side type declarations of size
Donald Bruce Stewart wrote:
This entry in fact runs faster than the original (though not the new
vectorised
entry) optimised C entry (and faster than all other languages):
http://shootout.alioth.debian.org/gp4/benchmark.php?test=partialsumslang=all
So, by carefully tweaking things,
Bulat Ziganshin wrote:
Hello Donald,
Wednesday, February 01, 2006, 8:00:04 AM, you wrote:
DBS Here's a brief introduction. I intend to write up (on the performance
page on
DBS the wiki) a list of things we've done to improve the shootout entries.
N.B
DBS we're now the 3rd *fastest*
--- Chris Kuklewicz [EMAIL PROTECTED]
wrote:
-snip,snip-
It is 3rd fastest.
Looking at Just Memory Use, Haskell is 8th
Looking at Just Lines Of Code, Haskell is 1st
Lookat at the 1:1:1 even balance Haskell is 1st
Programmer skill and effort really does matter ;-)
Congratulations.
joelkoerwer:
Thanks Chris. I was actually asking about analyzing Core
output in general. I'm well aware of the problems we're
having with the nbody entry.
I'm convinced my list based version can go faster than it is
now. That's why I was asking if Don could put together a few
Thanks Chris. I was actually asking about analyzing Core output in general. I'm well aware of the problems we're having with the nbody entry.I'm convinced my list based version can go faster than it is now. That's why I was asking if Don could put together a few notes on how to optimize inner
Joel Koerwer wrote:
On 1/26/06, *Donald Bruce Stewart* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Ah, i just do: ghc A.hs -O2 -ddump-simpl | less
and then read the Core, keeping an eye on the functions I'm interested
in, and checking they're compiling to the kind of
Donald Bruce Stewart wrote:
haskell:
There is a new combined benchmark, partial sums that subsumes several
earlier
benchmarks and runs 9 different numerical calculations:
http://haskell.org/hawiki/PartialSumsEntry
Ah! I had an entry too. I've posted it on the wiki. I was careful to
haskell:
Donald Bruce Stewart wrote:
haskell:
There is a new combined benchmark, partial sums that subsumes several
earlier
benchmarks and runs 9 different numerical calculations:
http://haskell.org/hawiki/PartialSumsEntry
Ah! I had an entry too. I've posted it on the wiki. I
haskell:
There is a new combined benchmark, partial sums that subsumes several
earlier
benchmarks and runs 9 different numerical calculations:
http://haskell.org/hawiki/PartialSumsEntry
Ah! I had an entry too. I've posted it on the wiki. I was careful to
watch that all loops are compiled
13 matches
Mail list logo
