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^