Haskell Speed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Haskell Speed

Daniel Carrera-2
Hi all,

I'm taking a look at the "Computer Language Shootout Benchmarks".

http://shootout.alioth.debian.org/

It looks like Haskell doesn't do very well. It seems to be near the
bottom of the pile in most tests. Is this due to the inherent design of
Haskell or is it merely the fact that GHC is young and hasn't had as
much time to optimize as other compilers?

For example, another very slow language is Ruby. In Ruby's case, there
is a design factor that will always make it slow. I wonder if Haskell is
in a smilar situation.

Yes yes, I know that a high level language trades CPU time by programmer
time. I'm still interested in the CPU time question though :)

Cheers,
Daniel.
--
      /\/`) http://oooauthors.org
     /\/_/  http://opendocumentfellowship.org
    /\/_/
    \/_/    I am not over-weight, I am under-tall.
    /
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Einar Karttunen
On 23.12 19:14, Daniel Carrera wrote:
> I'm taking a look at the "Computer Language Shootout Benchmarks".
>
> http://shootout.alioth.debian.org/
>
> It looks like Haskell doesn't do very well. It seems to be near the
> bottom of the pile in most tests. Is this due to the inherent design of
> Haskell or is it merely the fact that GHC is young and hasn't had as
> much time to optimize as other compilers?

Some reasons for this include:

* Efficient string handling functions are packaged separately (faststring etc)
  And thus not included in shootout.
* The tests change faster than Haskell people write efficient versions
  of the programs.
* Most of the Haskell results are taking an imperative implementation
  and just translating it.
* In many cases other languages use arrays while the Haskell implementation
  uses lists. Haskell does have efficient arrays.


- Einar Karttunen
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Jared Updike
In reply to this post by Daniel Carrera-2
This "benchmark" only tests specific implementations of these little
tests, tests mostly designed to do imperative things in an imperative
way. What that means is the results are completely subject to (1) how
good the submission for that tests was, (2) the choice of tests in the
first place, and (3) startup times for loading the binaries into
memory (GHC makes big binaries that are arguably much faster if you do
things in "daemon" mode, for example).

>From a glance, I also don't buy that most of this Haskell code is very
idiomatic or optimized, but I could be wrong. It looks like literal
translations of imperative code into Haskell, which is not the way
Haskell works. (It reminds me of Paul Graham's 1-D measure of
programming language expressivity: how hard is it to make a number
incrementer, which assumes very much that side-effects are a good
thing---the Haskell code is quite short considering the fact that this
is not something the language was designed for, and it's not
considered "the right approach" unless you have a good reason to do it
this way.) I'm also not surprised that "true, blue" Haskell folk
haven't necessarily jumped on this and submitted better code, because
it is pretty much a game created to make C win---it already wins!

That being said, I think it's neat that someone but something together
to play with. I also //do// agree that Haskell at its best is still
too slow, and that even implementations of a great language like
Haskell can always be better, but, as you said, the programmer/human
side wins out---for me, for Haskell, anyway.

Plus a lot of this code could be rewritten in C and then just have the
Haskell code foreign function call it--- since that is arguably a very
good way ("the right way"?) to use Haskell to do imperative things,
especially time-sensitive inner loops, especially in large
applications. But notice that none of these programs are big enough to
be considered "large" applications, and none of the tests measure
prototyping, refactoring, design time, mathematical
tractability/provability, or programmer time (or programmer **pain**!
especially for non-trivial programs, which none of these are.

Just my $.02

  Jared.

--
[hidden email]
http://www.updike.org/~jared/
reverse ")-:"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Jeremy Shaw
In reply to this post by Daniel Carrera-2
At Fri, 23 Dec 2005 19:14:46 +0000,
Daniel Carrera wrote:

>
> Hi all,
>
> I'm taking a look at the "Computer Language Shootout Benchmarks".
>
> http://shootout.alioth.debian.org/
>
> It looks like Haskell doesn't do very well. It seems to be near the
> bottom of the pile in most tests. Is this due to the inherent design of
> Haskell or is it merely the fact that GHC is young and hasn't had as
> much time to optimize as other compilers?

Rumor has it that the poor results are due to the inherent design of
the shootout itself. The shootout seems to test how fast specific
algorthims can be executed in various languages. Instead of testing:

 "Write a program that solves this problem quickly"

the tests are:

 "Write a program that solves this problem quickly, using *this* algorithm"

And many of the algorithms that you are required to use are a very
poor match for haskell. If the challenge was simply to solve the
problem using any algorithm you wanted, then Haskell would probably
fair much better.

Another possible factor is known deficiencies in current IO library
used by most haskell compilers. It is my understanding that the
current IO library was not implemented with speed and efficiency as a
top priority. If someone took the time to optimize/rewrite the current
library code, it might be possible to greatly increase the overall
speed of IO intensive haskell programs with out any changes to the
compilers or language.

In theory, compiled haskell code ought to be faster than
C. Optimization techniques like "whole program compilation" allow for
optimizations that would not be possible under most
languages. However, many of these techniques are still being
developed, are hard to implement and are not fully
understood. Projects like jhc aim to figure out which of these
techniques actually work in the real world.

Personally, I think one of the main reasons why haskell is 'slow' is
because it is fast enough for most people. Given a choice of 'more
features' or 'more speed', many people prefer 'more features'. That
said, the GHC maintainers manage to do both somehow.

j.
ps. Everything I said in this email may be wrong...
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Haskell Speed

Simon Marlow
In reply to this post by Daniel Carrera-2
On 23 December 2005 20:07, Jeremy Shaw wrote:

> Another possible factor is known deficiencies in current IO library
> used by most haskell compilers. It is my understanding that the
> current IO library was not implemented with speed and efficiency as a
> top priority. If someone took the time to optimize/rewrite the current
> library code, it might be possible to greatly increase the overall
> speed of IO intensive haskell programs with out any changes to the
> compilers or language.

Not really - the IO library is pretty reasonable, but representing
strings as [Char] is holding us back in many of these "benchmarks"
significantly.  Using the new packed string library will help, though.

Cheers,
        Simon

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Haskell Speed

Simon Marlow
In reply to this post by Daniel Carrera-2
On 23 December 2005 19:15, Daniel Carrera wrote:

> Hi all,
>
> I'm taking a look at the "Computer Language Shootout Benchmarks".
>
> http://shootout.alioth.debian.org/
>
> It looks like Haskell doesn't do very well. It seems to be near the
> bottom of the pile in most tests. Is this due to the inherent design
> of Haskell or is it merely the fact that GHC is young and hasn't had
> as much time to optimize as other compilers?

GHC? young?  We celebrated GHC's 10th birthday a couple of years ago :-)

Also, I would like to draw your attention to the fact that GHC wipes the
floor with nearly everyone in the concurrency benchmark:

http://shootout.alioth.debian.org/benchmark.php?test=message&lang=all

Seriously, it's very difficult to draw any meaningful conclusions from
these benchmarks.

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Peter Simons
In reply to this post by Daniel Carrera-2
Daniel Carrera writes:

 > http://shootout.alioth.debian.org/
 >
 > It looks like Haskell doesn't do very well. It seems to be
 > near the bottom of the pile in most tests. Is this due to
 > the inherent design of Haskell or is it merely the fact that
 > GHC is young and hasn't had as much time to optimize as
 > other compilers?

It's because nobody took the time to write faster entries
for the tests where Haskell is at the bottom of the pile.
The "Computer Language Shootout Benchmark" is a fun idea,
but it's quite pointless to draw any conclusions about
programming languages from those results. If it were
included in the contest, native assembler code would win
every time.

Peter

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Daniel Carrera-2
In reply to this post by Simon Marlow
Simon Marlow wrote:
> GHC? young?  We celebrated GHC's 10th birthday a couple of years ago :-)

How is that possible if Haskell98 is 7 years old? I thought Haskell
itself was a very young language (as far as computer languages can be
young).

Cheers,
Daniel.
--
      /\/`) http://oooauthors.org
     /\/_/  http://opendocumentfellowship.org
    /\/_/
    \/_/    I am not over-weight, I am under-tall.
    /
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Haskell Speed

Daniel Carrera-2
In reply to this post by Peter Simons
Peter Simons wrote:
> It's because nobody took the time to write faster entries
> for the tests where Haskell is at the bottom of the pile.
> The "Computer Language Shootout Benchmark" is a fun idea,
> but it's quite pointless to draw any conclusions about
> programming languages from those results. If it were
> included in the contest, native assembler code would win
> every time.

If the results could be trusted, they would be useful. You could balance
the expected loss in performance against other factors (e.g. speed of
development).

Cheers,
Daniel.
--
      /\/`) http://oooauthors.org
     /\/_/  http://opendocumentfellowship.org
    /\/_/
    \/_/    I am not over-weight, I am under-tall.
    /
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Antti-Juhani Kaijanaho-2
In reply to this post by Daniel Carrera-2
Daniel Carrera wrote:
> Simon Marlow wrote:
>
>> GHC? young?  We celebrated GHC's 10th birthday a couple of years ago :-)
>
> How is that possible if Haskell98 is 7 years old?

The same way GCC is much older (dates from 1984) than C99 (dates from
2000). Haskell 98 is the newest standard, but it wasn't the first
version of the language. The first public version was Haskell 1.0, dated
in March 1990.  I believe GHC is only a year or two younger.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Peter Simons
In reply to this post by Daniel Carrera-2
Daniel Carrera writes:

 > If the results could be trusted, they would be useful.
 > You could balance the expected loss in performance
 > against other factors (e.g. speed of development).

How do you measure the time it takes to come up with a
QuickSort algorithm that, implemented in Haskell, crushes
the MergeSort algorithm all other languages use? ;-)

Peter

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Haskell Speed

Daniel Carrera-2
Peter Simons wrote:
> How do you measure the time it takes to come up with a
> QuickSort algorithm that, implemented in Haskell, crushes
> the MergeSort algorithm all other languages use? ;-)

:-)

I've been impressed with Haskell so far. Today I implemented a reverse
Polish notation calculator. The code is 55 lines, it's easy to read, and
only took a few hours for this humble newbie to implement.

The second function I wrote in Haskell was quicksort :)

But still... I think that speed benchmarks can be useful. For example, I
really like Ruby, but its speed would really stop me from using it for
many applications even though it's a very expressive language. So it's
good to know what speed limitations the language has.

Right now I'd say that if I need a complex algorithm (e.g. an RPN
calculator) I'd do it in Haskell, but when I have a simple algorithm and
performance is an issue (e.g. modeling the colission of two galaxies)
I'd use C.

Cheers,
Daniel.
--
      /\/`) http://oooauthors.org
     /\/_/  http://opendocumentfellowship.org
    /\/_/
    \/_/    I am not over-weight, I am under-tall.
    /
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Peter Simons
Daniel Carrera writes:

 > when I have a simple algorithm and performance is an
 > issue [...] I'd use C.

You don't have to. You can write very fast programs in
Haskell.

I never really finished the article I wanted to write about
this subject, but the fragment I have might be interesting
or even useful nonetheless:

  http://cryp.to/blockio/fast-io.html
  http://cryp.to/blockio/fast-io.lhs

The text uses one of the Language Shootout's tasks as an
example.

Peter

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Greg Buchholz
In reply to this post by Jeremy Shaw
Jeremy Shaw wrote:

>
> Rumor has it that the poor results are due to the inherent design of
> the shootout itself. The shootout seems to test how fast specific
> algorthims can be executed in various languages. Instead of testing:
>
>  "Write a program that solves this problem quickly"
>
> the tests are:
>
>  "Write a program that solves this problem quickly, using *this* algorithm"

    At one time someone was working on creating the "Computer Language
Shoot-in" to compensate for this deficiency...

    http://shootin.sourceforge.net/

> And many of the algorithms that you are required to use are a very
> poor match for haskell.

    True.  But there are some tests like "fasta" that appear to have a
laziness induced space leak that presumably could be fixed.  

http://shootout.alioth.debian.org/benchmark.php?test=fasta&lang=all


Greg Buchholz
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Haskell Speed

Branimir Maksimovic-2
In reply to this post by Daniel Carrera-2



>From: Daniel Carrera <[hidden email]>
>To: [hidden email]
>Subject: [Haskell-cafe] Haskell Speed
>Date: Fri, 23 Dec 2005 19:14:46 +0000
>
>Hi all,
>
>I'm taking a look at the "Computer Language Shootout Benchmarks".
>
>http://shootout.alioth.debian.org/
>
>It looks like Haskell doesn't do very well.

Of course, first example uses [String] instead of Data.HashTable as other
languages do. Imagine C program does not use hash ,rather list, how it
will perform:)
I didn't look further after that.

Greetings, Bane.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

S Koray Can
In reply to this post by Daniel Carrera-2
Daniel Carrera wrote:
> It looks like Haskell doesn't do very well. It seems to be near the
> bottom of the pile in most tests. Is this due to the inherent design of
> Haskell or is it merely the fact that GHC is young and hasn't had as
> much time to optimize as other compilers?

I don't think it's that bad. It depends on the particular test, but it's
  almost comparable to Java, iirc. On some tests, it's terrible, though.

> For example, another very slow language is Ruby. In Ruby's case, there
> is a design factor that will always make it slow. I wonder if Haskell is
> in a smilar situation.

Haskell's syntax and type system are powerful enough that technically
there are a lot of optimizations possible without involving FFI. It may
become ugly, though, and less and less safe e.g. if you have to use
unsafeWrite's to update arrays to eliminate boundchecks, etc.

A lot of the benchmark problems (at least the ones GHC seems to do worse
than usual, e.g.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=revcomp&lang=all)
involve some sort of string processing. Idiomatic Haskell dictates that
one uses a linked list of Char's because FastString is not  part of the
language. That is a lot of overhead for values as small as one byte.
Also, the input string is 25M characters long in the revcomp case, thus
there's a lot of difference between reversing it with and without
in-place updates. If you look at the OCaml implementations, they usually
use references, in-place updates and compile with boundchecks disabled
(but that is idiomatic ocaml code).

However, I don't think it is right to downplay these benchmarks. Such
little tasks exist in one form or another in bigger programs. Perhaps we
should include mutable arrays in 'idiomatic' Haskell as well. Otherwise
it is similar to proposing std::getline() take a std::List<Char> as an
argument from a performance point of view.

And it's not right to blame naive implementors, either. I couldn't have
guessed that the see the difference between the two haskell
implementations for sum-file would be so massive. It's a pity that the
super-slow version could very well be the version your coworker would
have written even if you wouldn't.

Cheers,
Koray
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Chris Kuklewicz-2
In reply to this post by Greg Buchholz
Greg Buchholz wrote:
>
>     True.  But there are some tests like "fasta" that appear to have a
> laziness induced space leak that presumably could be fixed.  
>
> http://shootout.alioth.debian.org/benchmark.php?test=fasta&lang=all
>

Playing with the space-leaking code did not show any obvious reason to
expect the space leak.  By commenting out the third output in main it
did not leak space.

Could some look at the original code at the link above and let me know
why there is a 300 MB space leak?

But if you never express huge lists, then it won't leak space.  Here is
a tweaked version, called tweak6.hs, that interleaves making and writing
a line of output.  It runs in 2.16 MB of RSIZE instead of over 300 MB.

Still slow, however.  If you want more speed without extra libraries,
then use an unboxed array of Word8 (length of one line: 60 bytes), since
Unicode Char and linked lists are overkill.

The other killer is probably the array of tuple linear lookup to find
the chosen symbol.  Hand coded if/then branches could be used to speed
that up.  For even faster speed, do not use 0.0 to 1.0 probabilities at
all.  Instead of normalize :: Int -> Double and then lookup (Double ->
Base) remove the use of Double and do (Int -> Base) lookup.

But the space leak was the embarrassing part.  So I just fixed that.

--
Chris Kuklewicz
---------------


-- The Great Computer Language Shootout
-- http://shootout.alioth.debian.org/
-- contributed by Jeff Newbern
-- Modified to tweak6.hs by Chris Kuklewicz

import Control.Monad.Trans
import Control.Monad.State
import System.IO (hFlush,stdout)

{- original
$ time ./fasta.ghc_run 2500000 > /dev/null

real    1m17.596s
user    0m44.838s
sys     0m3.322s

330+ Megs! Space leaking all over the place.  No idea why.

$ time ./fasta.tweak6 2500000 > /dev/null

real    0m30.477s
user    0m23.356s
sys     0m0.744s

2.2 Megs RSIZE
-}

-- Uses random generation code derived from Simon Marlow and Einar Karttunen's
-- "random" test entry.

-- Orignal version note: This code has not been optimized *at all*.
-- It is written to be clear and to follow standard Haskell idioms as
-- much as possible (but we have to match the stateful PRNG idiom in
-- the test definition, which is oriented toward an imperative
-- language).  Performance is decent with ghc -O2, but if it can be
-- improved without sacrificing the clarity of the code, by all means
-- go for it!

-- Mondified tweak6.hs version note: Use a StateT around IO to manage
-- the seed.  This makes interleaving the generation and output of the
-- sequence easier.  It is only *minimally* abstracted.

import System(getArgs)

type Base = Char
type Sequence = [Base]

alu :: Sequence  -- predefined sequence
alu = "GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGG" ++
      "GAGGCCGAGGCGGGCGGATCACCTGAGGTCAGGAGTTCGAGA" ++
      "CCAGCCTGGCCAACATGGTGAAACCCCGTCTCTACTAAAAAT" ++
      "ACAAAAATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCA" ++
      "GCTACTCGGGAGGCTGAGGCAGGAGAATCGCTTGAACCCGGG" ++
      "AGGCGGAGGTTGCAGTGAGCCGAGATCGCGCCACTGCACTCC" ++
      "AGCCTGGGCGACAGAGCGAGACTCCGTCTCAAAAA"

type BaseFrequency = (Base,Double)

iub :: [BaseFrequency]
iub = [ ('a', 0.27), ('c', 0.12), ('g', 0.12), ('t', 0.27),
        ('B', 0.02), ('D', 0.02), ('H', 0.02), ('K', 0.02), ('M', 0.02), ('N', 0.02),
        ('R', 0.02), ('S', 0.02), ('V', 0.02), ('W', 0.02), ('Y', 0.02) ]

homosapiens :: [BaseFrequency]
homosapiens = [ ('a', 0.3029549426680), ('c', 0.1979883004921),
                ('g', 0.1975473066391), ('t', 0.3015094502008) ]

-- select a base whose interval covers the given double
chooseBase :: [BaseFrequency] -> Double -> Base
chooseBase [(b,_)]    _ = b
chooseBase ((b,f):xs) p | p < f     = b
                        | otherwise = chooseBase xs (p-f)

type Seed = Int
type Pseudo a = StateT Seed IO a

prng :: Pseudo Double
prng = let nextSeed s = (s * ia + ic) `mod` im
           normalize n = (fromIntegral n) * (1.0 / fromIntegral im)
           im = 139968; ia = 3877; ic = 29573
       in do seed <- get
             let seed' = nextSeed seed
             put seed'
             return (normalize seed')

prngN count = sequence $ replicate count prng

-- write a sequence in Fasta format
writeFasta :: String -> String -> Sequence -> IO ()
writeFasta label title sequence =
  do putStrLn $ ">" ++ (label ++ (" " ++ title))
     writeWrapped 60 sequence
  where writeWrapped _   []  = do return ()
        writeWrapped len str = do let (s1,s2) = splitAt len str
                                  putStrLn s1
                                  writeWrapped len s2

writeFastaHeader :: (MonadIO m) => String -> String -> m ()
writeFastaHeader label title = liftIO $ putStrLn $ ">" ++ (label ++ (" " ++ title))

writeWrapped' :: Int -> Int -> (Double->Base) -> Pseudo ()
writeWrapped' wrap total trans =
    let work c = case c of
                   0 -> return ()
                   n -> do let c' = min wrap n
                               nextC = c - c'
                           s <- liftM (map trans) (prngN c')
                           liftIO $ putStrLn s
                           work nextC
    in work total

writeWrapped = writeWrapped' 60

main = do args <- getArgs
          let n = if (null args) then 1000 else read (head args)
          writeFasta "ONE" "Homo sapiens alu" (take (2*n) (cycle alu))
          writeFastaHeader "TWO" "IUB ambiguity codes"
          seed' <- execStateT (writeWrapped (3*n) (chooseBase iub))  42
          writeFastaHeader "THREE" "Homo sapiens frequency"
          execStateT (writeWrapped (5*n) (chooseBase homosapiens)) seed'

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Haskell Speed

Paul Moore-2
In reply to this post by Peter Simons
On 23 Dec 2005 22:29:02 +0100, Peter Simons <[hidden email]> wrote:

> Daniel Carrera writes:
>
>  > when I have a simple algorithm and performance is an
>  > issue [...] I'd use C.
>
> You don't have to. You can write very fast programs in
> Haskell.
>
> I never really finished the article I wanted to write about
> this subject, but the fragment I have might be interesting
> or even useful nonetheless:
>
>   http://cryp.to/blockio/fast-io.html
>   http://cryp.to/blockio/fast-io.lhs

One of the interesting points that this illustrates (to me) is that
the "obvious" approach in Haskell can be seriously non-optimal in
terms of performance. Add to this the fact that tuning functional
programs is a non-trivial art, and it becomes quite easy to see why
Haskell might come across as slow.

Your wcLazy implementation is (as you say) the "obvious" approach.
Your two other approaches aren't particularly obvious, althought they
are far more efficient. It would be interesting to see standalone code
for wcIOB (where you're allowed to assume that any helpers you need,
like your block IO library, are available from the standard library).
This would help in comparing the "obviousness" of the two approaches.

Paul
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Haskell Speed

Joel Reymont

On Dec 24, 2005, at 6:02 PM, Paul Moore wrote:

> One of the interesting points that this illustrates (to me) is that
> the "obvious" approach in Haskell can be seriously non-optimal in
> terms of performance. Add to this the fact that tuning functional
> programs is a non-trivial art, and it becomes quite easy to see why
> Haskell might come across as slow.

I got totally burned by this trying to write a heavily threaded,
heavy networking app in Haskell. The obvious approach was a dead-end.

        Joel

--
http://wagerlabs.com/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Re: Haskell Speed

Bulat Ziganshin
Hello Joel,

Saturday, December 24, 2005, 9:29:17 PM, you wrote:
>> One of the interesting points that this illustrates (to me) is that
>> the "obvious" approach in Haskell can be seriously non-optimal in
>> terms of performance. Add to this the fact that tuning functional
>> programs is a non-trivial art, and it becomes quite easy to see why
>> Haskell might come across as slow.

JR> I got totally burned by this trying to write a heavily threaded,
JR> heavy networking app in Haskell. The obvious approach was a dead-end.

your problem is not Haskell or GHC, your problem is just lack of
experience in this area. remember how i decreased number of your
threads in 4 times, remember that i found simple and obvious solution
for problem, what you tried to fix 2 weeks and ended with attempt to
write your own scheduler. remember that you start low-optimizing
"functional pickling" library, which is inefficient by its functional
composition design instead of give chances to all serialization
libraries and select the most effective one

so i think that your problems is due to bad design decisions caused by
lack of experience. two weeks ago when you skipped my suggestions
about improving this design and answered that you will use "systematic
approach", i foresee that you will fail and say that Haskell is a bad
language

Haskell is really slow language. but even if it will be 100 times
better, it can't write programs itself, some help from programmer
anyway is needed :)


--
Best regards,
 Bulat                            mailto:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
123