
Hi all, Thank you for all the information on my previous question. I learned a lot, and good pointers to more info. My next question is about speed. How fast would you consider Haskell? (say, for computational work). How would you compare it to C, Python and Ruby? I suggest C, Python and Ruby as a basis of comparison because: 1) C is what I'd use if I wanted something fast. 2) Python or Ruby is what I'd use if I wanted clean code. I know that Haskell can be compiled, thanks to ghc. Ruby is interpreted and I'm pretty sure Python is quasi-interpreted (it's "compiled" on the fly to Java-style bytecode and a VM runs the bytecode). Furthermore, the Haskell page says that ghc produces fast programs. So I would guess that Haskell is faster than Python, but not as fast as C. Would that be correct? For computational work (e.g. a simulation, factoring primes, whatever) does it approach C speed? I would be happy to hear a comparison with any other language you find interesting.:-) As well as any other information you'd like to share. Cheers, Daniel.

Daniel Carrera
My next question is about speed. How fast would you consider Haskell? (say, for computational work). How would you compare it to C, Python and Ruby?
I suggest C, Python and Ruby as a basis of comparison because:
I suggest adding OCaml, because it's similar to Haskell, and because OCaml has a good implementation while Python and Ruby have only slow implementations, and thus being faster than them is not impressive. The OCaml compiler usually generates faster code than GHC, sometimes slower.
Furthermore, the Haskell page says that ghc produces fast programs. So I would guess that Haskell is faster than Python, but not as fast as C.
Would that be correct?
Usually yes. (Python is fast when most of the work is done by libraries written in C. C is slow when dynamic memory allocation or threads are involved.) -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

On Tue, May 03, 2005 at 12:20:45PM -0400, Daniel Carrera wrote:
Would that be correct? For computational work (e.g. a simulation, factoring primes, whatever) does it approach C speed?
I would be happy to hear a comparison with any other language you find interesting.:-) As well as any other information you'd like to share.
I wouldn't consider haskell for a serious numerical problem, although I wish I could. Of course, I wouldn't consider python or ruby, either, except as a wrapper around C or C++. But then, I come from a community where one occasionally has to justify the decision to not use fortran... It's possible to write fast code in haskell, but it's very easy to accidentally write slow code. In C you don't have to try to guess what the compiler's going to do, except with regard to inlining functions and loop optimizations, both of which involve fine-tuning performance at a level way beyond what C can handle. An interesting challenge would be to rewrite fftw in haskell, and see how close one could come to the performance of the original... :) One ought to be able to write self-tuning code like that a lot more cleanly in haskell, but the question is whether you could overcome the GC and lazy evaluation issues to get fast code. (For the level of tuning needed, consider that the fftw folks are careful to avoid the use of negative constants, and thereby achieve a significant improvement in performance.) -- David Roundy

On 2005-05-03, David Roundy
An interesting challenge would be to rewrite fftw in haskell, and see how close one could come to the performance of the original... :)
What precisely do you mean by that? FFTW is C code generated by OCaml? Do you want to retarget ti so that Haskell is generated, or rewrite the generator in Haskell? (Or both?) -- Aaron Denney -><-

Aaron Denney wrote:
On 2005-05-03, David Roundy
wrote: An interesting challenge would be to rewrite fftw in haskell, and see how close one could come to the performance of the original... :)
What precisely do you mean by that? FFTW is C code generated by OCaml? Do you want to retarget ti so that Haskell is generated, or rewrite the generator in Haskell? (Or both?)
Maybe not completely related, but you might find this paper interesting... http://lambda-the-ultimate.org/node/view/652 Greg Buchholz

On Wed, May 04, 2005 at 07:20:20PM +0000, Aaron Denney wrote:
On 2005-05-03, David Roundy
wrote: An interesting challenge would be to rewrite fftw in haskell, and see how close one could come to the performance of the original... :)
What precisely do you mean by that? FFTW is C code generated by OCaml? Do you want to retarget ti so that Haskell is generated, or rewrite the generator in Haskell? (Or both?)
Both. I'd be curious to see how well one could do with pure haskell code. It may be possible to do reasonably well, and would certainly be instructive. FFTW is not simpley C code generated by OCaml, the C code also does runtime timing and optimization, generating new algorithms (by combining existing primitives) on the fly. This sort of code-generation-on-the-fly (or rather code-recombination) is what functional languages ought to be good at, if only there isn't too much overhead. I'd be interested if someone *else* did this. FFTW is an amazing piece of work, and I'd not want to bother duplicating their work. Another (also crazy) idea would be to implement a runtime-optimized version of ATLAS. That would be somewhat more practical, since I find it annoying that ATLAS is compile-time optimized, so you need to recompile it on each computer you use (or if you buy new RAM...). Of course, doing it all in haskell would still be silliness, but it'd be cool... :) And I think the algorithms involved in block matrix multiplies are much simpler than those involved in ffts. I don't know how it would work out in the real world, but it seems like one *ought* to be able to write truly beautiful auto-tuned code in haskell! Perhaps even some sort of a "time it as you go" mechanism could be used (if one had a clock with enough precision), which would eliminate the annoying feature of FFTW that one needs to create and keep track of plans. (Mostly I'm just daydreaming here... if only I were an undergrad again and had the time and energy for excessing hacking with very little hope of any practical benefit.) -- David Roundy

Daniel Carrera wrote:
Hi all,
Thank you for all the information on my previous question. I learned a lot, and good pointers to more info.
My next question is about speed. How fast would you consider Haskell? (say, for computational work). How would you compare it to C, Python and Ruby?
I started a small project in Ruby some time ago. It involved a bit of parsing and moving quite large binary data around. In Ruby speed was real problem so I looked for another language and ended up with... Haskell :) Speed of GHC compiled programs is ok for me, but if you need handling of binaries FFI is your very good friend! I cannot say anything about OCaml or Python, though. -- Gracjan
participants (6)
-
Aaron Denney
-
Daniel Carrera
-
David Roundy
-
Gracjan Polak
-
Greg Buchholz
-
Marcin 'Qrczak' Kowalczyk