as usual, i forgot to use the magical reply to all and under the
impression I'm still talking to the list had bothered dons personally
(heresy/sacrilege/deathwish , i know)
to rectify it a bit at least, i'm posting a summary, in hopes someone find
it useful.
-- this
Hello wman,
Tuesday, October 7, 2008, 8:44:48 AM, you wrote:
btw, why is the example #2
(http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcollang=ghcid=2)
(which kicks collective asses of all other participants) not
considered in the shootout ? Too much optimizations ?
it's
Hello Brandon,
Tuesday, October 7, 2008, 7:59:06 AM, you wrote:
is there a reason why -O2 shouldn't be made the default (and
allowing to turn off optimizations by -O0 perhaps) ?
it compiles ~2x slower and firces more recompilation (because it does
inter-module inlining). so it's not perfect
On Mon, 2008-10-06 at 21:06 -0500, Mike Coleman wrote:
There's a readInt method, which I guess I could use, but it returns a
Maybe, and I don't see how I can easily strip that off.
You can use Data.Maybe's 'mapMaybe' function
The mapMaybe function is a version of map which can throw out
Hi,
I could use a little help. I was looking through the Real World
Haskell book and came across a trivial program for summing numbers in
a file. They mentioned that that implementation was very slow, as
it's based on String's, so I thought I'd try my hand at converting it
to use lazy
On Mon, Oct 6, 2008 at 7:06 PM, Mike Coleman [EMAIL PROTECTED] wrote:
Hi,
I could use a little help. I was looking through the Real World
Haskell book and came across a trivial program for summing numbers in
a file. They mentioned that that implementation was very slow, as
it's based on
Am Dienstag, 7. Oktober 2008 04:21 schrieb Jason Dagit:
On Mon, Oct 6, 2008 at 7:06 PM, Mike Coleman [EMAIL PROTECTED] wrote:
Hi,
I could use a little help. I was looking through the Real World
Haskell book and came across a trivial program for summing numbers in
a file. They
a slight modification to compile it :
change:
where sumFile = sum . map read . L.words
to :
where sumFile = sum . map (read . L.unpack) . L.words
but it's actually _slower_ than the non-bytestring version.
i did a little test, three versions of the same script and manufactured
meself a ~50 MB
666wman:
a slight modification to compile it :
change:
where sumFile = sum . map read . L.words
to :
where sumFile = sum . map (read . L.unpack) . L.words
but it's actually _slower_ than the non-bytestring version.
Never unpack a bytestring.
import qualified
Thanks for your replies. Hoogle is pretty cool--I didn't know about that.
I ended up with this, which is pretty close to the original (it will
also bomb if given non-integer input):
import qualified Data.ByteString.Lazy.Char8 as L
import qualified Data.Maybe as M
main = do
contents -
the problem is that using readInt is actually _as slow_, at least using my
test script :-((
On Tue, Oct 7, 2008 at 5:12 AM, Don Stewart [EMAIL PROTECTED] wrote:
666wman:
a slight modification to compile it :
change:
where sumFile = sum . map read . L.words
to :
where
tutufan:
Thanks for your replies. Hoogle is pretty cool--I didn't know about that.
I ended up with this, which is pretty close to the original (it will
also bomb if given non-integer input):
import qualified Data.ByteString.Lazy.Char8 as L
import qualified Data.Maybe as M
main = do
new figures, after updating bytestring (0.9.0.1.1 - 0.9.1.2) using -O2
time Main nums
real0m2.531s
user0m0.015s
sys 0m0.015s
time Main2 nums
real0m13.999s
user0m0.015s
sys 0m0.015s
time Main3 nums
real0m2.796s
user0m0.015s
sys 0m0.015s
thats more like
On 2008 Oct 6, at 23:54, wman wrote:
just for the kicks i tried the new version of bytestring without -O2
and the results were even worse:
Yep, ByteString does a lot of stuff that is really bad when GHC isn't
performing stream fusion --- but when it is, the code compiles down to
tight
666wman:
just for the kicks i tried the new version of bytestring without -O2 and
the results were even worse:
Note that without -O or -O2 no strictness analysis is performed. So that
tail recursive loop ... won't be. You could try -Onot -fstrictness just
for kicks, to see why strictness
ghc -Onot -fstrictness --make Main1.hs ghc -Onot -fstrictness --make
Main2.hs ghc -Onot -fstrictness --make Main3.hs
time Main1 nums
real0m39.530s
user0m0.015s
sys 0m0.030s
time Main2 nums
real0m14.078s
user0m0.015s
sys 0m0.015s
time Main3.exe nums
real
666wman:
ghc -Onot -fstrictness --make Main1.hs ghc -Onot -fstrictness --make
Main2.hs ghc -Onot -fstrictness --make Main3.hs
time Main1 nums
real0m39.530s
user0m0.015s
sys 0m0.030s
time Main2 nums
real0m14.078s
user0m0.015s
sys
17 matches
Mail list logo
