Bravo!  I would only add that if the same development effort were expended
optimizing Haskell code, as is spent just getting C or C++ code to work, the
6-10 factor would be dramatically reduced.
--PeterD

-----Original Message-----
From: Ch. A. Herrmann [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 20, 2000 10:46 AM
To: [EMAIL PROTECTED]
Subject: Re: speed of compiled Haskell code. 


Dear Haskellites,

    >> My experience with the program of generating permutations on
    >> [1..10] showed that the code produced by ghc-4.04 is 22 times
    >> slower than certain specially written C program.  Only the C
    >> program algorithm was taken very different from Haskell's
    >> one. For each system has its own best algorithm and appropriate
    >> data structure.  But this example task was chosen as unlucky for
    >> Haskell.  In other, average case, I expect the ratio of 6-10.

    Jan> This seems that Haskell cannot be considered as a language for
    Jan> real world applications but merely as a toy for researchers .

some people from the FORTRAN community could say:
"C is far too slow, use FORTRAN! Many computationally expensive
 problems do not need dynamic data structures!"


In my opinion, the speed argument has to be relativated:

- Not all applications require full speed.

- Haskell programming saves you a lot of development time
  compared with C. You can use Haskell as an executable 
  specification language and, if really necessary, charge
  some programmers with the task to convert it to C. 

- You need not use exclusively either Haskell or C. Time critical, 
  interactive, or hardware accessing parts can be implemented in C, 
  but your sophisticated algorithms are programmed in Haskell.

- The ratio 6-10 is the state of the art today.
  I believe that if as much research were spent on Haskell compilation as
  on C compilation, Haskell would outperform C.
  Haskell has the advantage to C that due to referential transparency
  more powerful optimization rules can be applied.
  Thus, giving up referential transparency would mean to get a small 
  improvement now but sacrifice the chances of the future.

Cheers
-- 
 Christoph Herrmann
 E-mail:  [EMAIL PROTECTED]
 WWW:     http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html





Reply via email to