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.
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, pleas
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
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.
>
P
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, Rich
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
op
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 evalu
| 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
| > 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 rel
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')). Why
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 wi
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
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 man
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
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 en
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 en
| 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
| produ
Sterling Clover wrote:
...
Finally, there's fasta.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=ghc&id=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 bo
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=meteor&lang=ghc&id=5
>
> This is the
In some spare time over the holidays I cooked up three shootout
entries, for Fasta, the Meteor Contest, and Reverse Complement. I
should probably have tossed them to haskell-cafe before submission,
for review and ideas, but they're up now. In any case, all three were
great learning experien
20 matches
Mail list logo