Simon Marlow wrote:
...
I have seen strange artifacts like this before that turned out to be
caused by one of two things:
- bad cache interactions, e.g. we just happen to have laid out the code in
such a way that frequently accessed code sequences push each other out
of the cache, or
Joost Behrends wrote:
Neil Mitchell ndmitchell at gmail.com writes:
If it can be reproduced on anyones machine, it is a bug. If you can
bundle up two programs which don't read from stdin (i.e. no getLine
calls) or the standard arguments (i.e. getArgs) which differ only by
the Data.Char
Stefan O'Rear stefanor at cox.net writes:
If you can reproduce it on your machine (rm executable *.o *.hi
between tests for maximum reliability), it's definitely a bug.
http://hackage.haskell.org/trac/ghc/wiki/ReportABug
Stefan
Yes, it was the same as before. Had i reboot meanwhile,
Daniel Fischer daniel.is.fischer at web.de writes:
I can't reproduce it, both run in 130s here (SuSE 8.2, 1200MHz Duron).
However, it's running over 30 minutes now trying to factorise 2^88+1 without
any sign of approaching success, which suggests your code has a bug (the
factorization is
Am Samstag, 22. Dezember 2007 20:48 schrieb Joost Behrends:
Daniel Fischer daniel.is.fischer at web.de writes:
I can't reproduce it, both run in 130s here (SuSE 8.2, 1200MHz Duron).
However, it's running over 30 minutes now trying to factorise 2^88+1
without any sign of approaching success,
Am Samstag, 22. Dezember 2007 21:28 schrieb Joost Behrends:
Of course, one minute after I sent my previous mail, I receive this one :(
However, one point, it might be faster to factor out all factors p in found
and only then compute the intsqrt, like
found x = x{dividend = xstop, bound =
On Sat, Dec 22, 2007 at 04:40:00PM -0500, Sterling Clover wrote:
I'm curious if you get the same performance difference importing
GHC.Listinstead of
Data.Char? I chased some dependencies, and Data.Char imports GHC.Arr, which
in turn imports GHC.List, which provides a bunch of fusion rules
Daniel Fischer daniel.is.fischer at web.de writes:
Of course, one minute after I sent my previous mail, I receive this one :(
However, one point, it might be faster to factor out all factors p in found
and only then compute the intsqrt, like
found x = x{dividend = xstop, bound = intsqrt
Here's the Prelude imports I see at the moment. Didn't chase down the
dependencies in all the code initially and now I see that GHC.Show does
import GHC.List. Still, I suspect this has something to do with fusion
nonetheless.
#ifdef __GLASGOW_HASKELL__
import GHC.Base
import GHC.IOBase
import
I'm curious if you get the same performance difference importing
GHC.Listinstead of
Data.Char? I chased some dependencies, and Data.Char imports GHC.Arr, which
in turn imports GHC.List, which provides a bunch of fusion rules pragmas
that would probably optimize your (++) usage. If this is the
Sterling Clover s.clover at gmail.com writes:
I'm curious if you get the same performance difference importing GHC.List
instead of Data.Char? I chased some dependencies, and Data.Char imports GHC.Arr,
which in turn imports GHC.List, which provides a bunch of fusion rules pragmas
that would
Hi
Yes - the same difference: 1.33 minutes vs. 2.30 now.
I was near at reporting this as a bug, but rejected that idea. What does bug
mean here ?
If it can be reproduced on anyones machine, it is a bug. If you can
bundle up two programs which don't read from stdin (i.e. no getLine
calls) or
Am Samstag, 22. Dezember 2007 22:57 schrieb Joost Behrends:
Daniel Fischer daniel.is.fischer at web.de writes:
Of course, one minute after I sent my previous mail, I receive this one
:( However, one point, it might be faster to factor out all factors p in
found and only then compute the
Neil Mitchell ndmitchell at gmail.com writes:
If it can be reproduced on anyones machine, it is a bug. If you can
bundle up two programs which don't read from stdin (i.e. no getLine
calls) or the standard arguments (i.e. getArgs) which differ only by
the Data.Char import, and have massive
Hi again, Daniel
cannot sleep tonight - perhaps from the feeling to loose too much time with
these things.
Yes - it's the wheel. And a dlist made from [3,5,7,11,13,17] was optimal in some
of my experiments too.
You will probably know it - but perhaps there are third-party readers:
A last try to
15 matches
Mail list logo
