🚀 go-pugleaf

P� Thu, 31 Jul 2008 10:01:37 +0200, skrev namekuseijin  
<namekuseijin@gmail.com>:

> I wonder why most functional programming languages fail so badly at
> what should be one of their primary main strengths:  recursive
> functions.
>
> In the well-known benchmarking game called "The computer game
> shootout", most such languages fail miserably in the face of blazing
> fast imperative code during the benchmarking of recursive functions
> such as ackermann or fibonacci:
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=recursive&lang=all
>
> The best is clean, only 1.6 slower than gcc C.
>
> The chart:
> 1.6 Clean
> 3.2 OCaml (just behind Fortran and Java!)
> 3.3 F# (running in mono)
> 3.4 SML on MLton (just after FreeBasic!)
> 3.4 Haskell GHC (just after Java on gcj!  almost a tie-in)
> 3.6 CL on SBCL (almost as good as compiled lazy static Haskell)
> 3.7 Scheme on Chicken (just after sbcl)
> 4.0 SML/NJ (just after C# on mono)
> 4.6 Scheme on Ikarus (just after Java -client!)
> 8.1 Scheme PLT (just after Fortran, again)
>
> Well, that's about it.
>
> I know in the grand scheme of things, such timings are not that bad,
> not orders of magnitude slower like some of the dynamic scripting
> stinkers in the bottom, specially in the face of such classy and easy
> syntax and semantics adding to programmer productivity.  Still, kind
> of a let down, like buying a Playstation 3 and waiting for a killer
> app that never comes...
>
> Any thoughts?

The fastest applicative code is in OCALM and Haskell.
For better performance in CL you might try the series library.
In a nutshell the above mentioned languages were based on experiences and  
reflections on performance in Lisp.
It is based on experience with type inference and lazy evaluation.
SBCL is better at type inference than other Lisp's so perhaps series under  
SBCL would give CL a more faveroable result.
Most compilers today (Allegro Common Lisp, LispWorks) have focused more on  
OO performance under CLOS and fast memory management which matters more to  
many of the users of Lisp. Note that most users of Lisp used a mixed  
paradigm approach and that loop plays a important role in why the  
applicative performance has not been a priority. As in all compiled  
languages it depends more on the quality of the programmer than the  
compiler. Anyhow short example code doesn't accurately reflect the users  
perceived performance running real programs. Java's long loading time and  
memory use tend to shadow algorithm performance in real programs. In this  
sense CL scores a lot better.

--------------
John Thingstad