s.clover:
Was this with tossing the partial sums code into the optimised bangs
program? Weird. I wonder if profiling will help explain why? In any case,
If nobody comes up with any other tweaks, I'll probably submit the
optimised bangs version to the shootout this weekend.
Don Stewart wrote:
Please go ahead and submit. :) and remember to upload also to our wiki,
so we have a permanent record of the attempt,
http://haskell.org/haskellwiki/Shootout
Note down any ideas you have.
Now that GHC 6.6 is available, please you it?
Last time I looked at the
andrewcoppin:
Don Stewart wrote:
Please go ahead and submit. :) and remember to upload also to our wiki,
so we have a permanent record of the attempt,
http://haskell.org/haskellwiki/Shootout
Note down any ideas you have.
Now that GHC 6.6 is available, please you it?
Looks
Don Stewart wrote:
andrewcoppin:
Now that GHC 6.6 is available, please you it?
Looks like something broke in an edit. Feel free to correct it.
Oh well. ;-)
But then, the GHC wiki still says The 6.8 branch is the current STABLE,
and we are in the 6.8.1 release candidate phase.
Sterling Clover wrote:
I'm still curious if the pre-calculation of partial sums that I did
works well across processors, as I don't see why it shouldn't. My
less-strictified version of Don's code is attached, and below are the
functions you'll need to insert/replace to make the partial-sums
Was this with tossing the partial sums code into the optimised bangs
program? Weird. I wonder if profiling will help explain why? In any case, If
nobody comes up with any other tweaks, I'll probably submit the optimised
bangs version to the shootout this weekend.
--S
On Nov 30, 2007 1:30 PM,
| If, after investigation (and perhaps checking with Don) you find that
adding bangs makes your program go
| slower, even though the function is in fact strict (otherwise it might go
slower because it's just doing more
| work!) then I'd love to see a test case.
|
| I wonder if this could be
| There may well have been changes to the strictness analyser that make
| some of the bangs (or most) unnecessary now. Also, its very likely
| I didn't check all combinations of strict and lazy arguments for the
| optimal evaluation strategy :)
|
| If it seems to be running consitently faster (and
Simon Peyton-Jones wrote:
You might think that unnecessary bangs shouldn't lead to unnecessary work --
if GHC knows it's strict *and* you bang the argument, it should still only be
evaluated once. But it can happen. Consider
f !xs = length xs
Even though 'length' will evaluate
Sterling Clover wrote:
...
Finally, there's fasta.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fastalang=ghcid=2
This one really depresses me. It outperforms the previous version by
roughly 20% on my machine (PPC) but underperforms by roughly the same
amount on the shootout
| Something I found with Dons version on my machine was that if I removed
| all the exclamation marks and the -fbang-patterns bit at the top it went
| about 20% faster as well as being much cleaner code, but with my very
| rudimentary understanding of Haskell I wasn't entirely sure it would
|
Simon Peyton-Jones wrote:
| Something I found with Dons version on my machine was that if I removed
| all the exclamation marks and the -fbang-patterns bit at the top it went
| about 20% faster as well as being much cleaner code, but with my very
| rudimentary understanding of Haskell I wasn't
Simon Peyton-Jones wrote:
| Something I found with Dons version on my machine was that if I removed
| all the exclamation marks and the -fbang-patterns bit at the top it went
| about 20% faster as well as being much cleaner code, but with my very
| rudimentary understanding of Haskell I wasn't
r.kelsall:
Simon Peyton-Jones wrote:
| Something I found with Dons version on my machine was that if I removed
| all the exclamation marks and the -fbang-patterns bit at the top it went
| about 20% faster as well as being much cleaner code, but with my very
| rudimentary understanding of
Oops forgot to hit reply-to-all.. resending..
N-body is looking good. I am running and amd64 3000+ on ghc 6.8.1. The
debian shootout is showing a huge gap between ghc 6.6 and g++ but I am not
seeing that gap. One concern though is that the code doesn't look very
haskellish. So much pointer
Never mind. I screwed up the timings.
The new haskell timings are still a huge improvement but they are:
-0.169075164
-0.169031665
real0m27.196s
user0m19.688s
sys 0m0.163s
On Nov 27, 2007 11:25 AM, Ryan Dickie [EMAIL PROTECTED] wrote:
Oops forgot to hit reply-to-all.. resending..
Don Stewart wrote:
...
There may well have been changes to the strictness analyser that make
some of the bangs (or most) unnecessary now. Also, its very likely
I didn't check all combinations of strict and lazy arguments for the
optimal evaluation strategy :)
I suspect the optimum details
I tried the same thing on my box, and indeed the version that isn't
strict in the rand function outperforms the original by a fair
margin, and seems to do slightly better than my own as well. Killing
the bangs in the unroll function also seems to help (especially that
in (s!, Just r')).
s.clover:
In some spare time over the holidays I cooked up three shootout
entries, for Fasta, the Meteor Contest, and Reverse Complement. I
Yay!
First up is the meteor-contest entry.
http://shootout.alioth.debian.org/gp4/benchmark.php?
test=meteorlang=ghcid=5
This is the clear win
19 matches
Mail list logo
