Hi, I can't subscribe to Haskell-Cafe, so I'll post here. I found something interesting. "General wisdom" is that Clean (or OCaml) is faster than Haskell. The claim is often followed by a link to the Debian shootout. But on closer inspection, I question this conclusion. The Debian shoot out actually has four sets of benchmarks: 1) Intel 32-bit one core. 2) Intel 32-bit quad-core. 3) Intel 64-bit one core. 4) Intel 64-bit quad-core. It turns out that Clean is only faster for (1). For the others, Haskell is faster. Here I compare Haskell, Clean, OCaml, Lisp SBCL, C# Mono and Fortran because they are all in the same ball mark: 32-bit sing core [1]: Lisp, Fortran, Clean, Haskell, C# Mono. 32-bit quad-core [2]: Haskell, C# Mono, Lisp, Clean, Fortran. 64-bit sing core [3]: Fortran, OCaml, Haskell, Clean, C# Mono, Lisp. 64-bit quad-core [4]: Haskell, OCaml, Lisp, C# Mono, Fortran, Clean. Notes: * The order is "fast language first". * There are no results for OCaml for 32-bit. * "Lisp" is "List SCBL" whatever that is. Tentative conclusions: 1) Haskell makes very good use of multiple cores. It smokes Clean. 2) For single core, they are neck and neck. Whether Clean is faster depends non the architecture. What do you think? Daniel. P.S. [1]http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&d=data&ghc=on&ocaml=on&sbcl=on&csharp=on&ifc=on&clean=on&calc=calculate&box=1 [2]http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all&d=data&ghc=on&ocaml=on&sbcl=on&csharp=on&ifc=on&clean=on&calc=calculate&box=1 [3]http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all&d=data&ghc=on&ocaml=on&sbcl=on&csharp=on&ifc=on&clean=on&calc=calculate&box=1 [4]http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all&d=data&ghc=on&ocaml=on&sbcl=on&csharp=on&ifc=on&clean=on&calc=calculate&box=1
Daniel Carrera wrote: [..]
* "Lisp" is "List SCBL" whatever that is.
That should probably be SBCL, as in Steel Bank Common Lisp. No? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Sun, 03 May 2009 18:06:33 +0200, Daniel Carrera
I can't subscribe to Haskell-Cafe, so I'll post here.
Thank you for your post.
Here I compare Haskell, Clean, OCaml, Lisp SBCL, C# Mono and Fortran because they are all in the same ball mark:
Which implementation of Fortran? According to "Fortran - Wikipedia, the free encyclopedia" (see http://en.wikipedia.org/wiki/Fortran), there are Absoft, Cray, GFortran, G95, Intel, Lahey/Fujitsu, Open Watcom, Pathscale, PGI, Silverfrost, Sun, XL Fortran, Visual Fortran, and other implementations.
* There are no results for OCaml for 32-bit.
I'll be sure to ask Jon Harrop about that the next time he talks about OCaml and speed comparisons ;). Incidentally, why can't you also subscribe to Haskell-Cafe? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^
Benjamin L.Russell wrote:
Incidentally, why can't you also subscribe to Haskell-Cafe?
Eventually I found that somehow I couldn't get any emails at all from the Haskell server, but the problem magically fixed itself after several hours, so I did subscribe to haskell-cafe and there was a short thread about Haskell vs Clean. The message I got out of it is that it is very difficult to draw any conclusions from the Debian benchmark because there are more Haskell people willing to optimize the Haskell code. Daniel.
On Tue, 19 May 2009 08:02:42 +0200, Daniel Carrera
Benjamin L.Russell wrote:
Incidentally, why can't you also subscribe to Haskell-Cafe?
Eventually I found that somehow I couldn't get any emails at all from the Haskell server, but the problem magically fixed itself after several hours, so I did subscribe to haskell-cafe and there was a short thread about Haskell vs Clean. The message I got out of it is that it is very difficult to draw any conclusions from the Debian benchmark because there are more Haskell people willing to optimize the Haskell code.
Yes, I just read that thread ("[Haskell-cafe] Haskell vs Clean (speed
comparison)" at
http://www.mail-archive.com/haskell-cafe@haskell.org/msg58988.html).
Based on the discussions there, there seem to be two problems with
this benchmark. In reference to Bulat Ziganshin's comments in that
thread,
On Sun, 3 May 2009 22:42:21 +0400, Bulat Ziganshin
Hello Daniel,
Sunday, May 3, 2009, 10:24:52 PM, you wrote:
32-bit sing core [1]: Lisp, Fortran
:) this test measures speed of some programs, not "languages". results are depends mainly on bundled libraries and RTS. by no means it demonstrates speed of compiler-generated code of carefully-written program what is typically considered as "language speed". the reasons are:
1) C++ people (and probably Fortran too) aren't so interested in making fastest possible programs as Haskell community. it becomes popular a few years ago, you can find that Haskell becomes several faster at average since then, which doesn't reflect actual improvements in GHC code generation (10-20%)
What is the reason for this phenomenon, though? If participants don't optimize their programs, then what is the use of the benchmark?
2) Most programs there depend on speed of libraries. Moreover, there is limitation that it should be *bundled* libraries, so results greatly depends on what currently included in one compiler or another
Is there a specific reason that the libraries need to be bundled?
3) it's prohibited to write your own fast code if bundled library is too slow (for example, because it's too general)
Again, this seems to give an advantage to programming languages with a preponderance of optimized bundled libraries. Based on the above arguments, it seems as if this benchmark does not really compare programming languages; rather, it seems to compare combinations of programming languages and their bundled libraries and communities. But then what happens if you have a great programming language with few optimized libraries and a small and relatively inactive community? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^
participants (3)
-
Benjamin L.Russell -
Daniel Carrera -
Magnus Therning