🚀 go-pugleaf

namekuseijin wrote:
> 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.

Actually the best is F#, only 1.2x slower than Visual 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,

I think 3x slower is bad. These languages should be at most 2x slower.

> 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?

OCaml is slow on the int versions because integer arithmetic is slow in
OCaml because it uses tagged 31-bit integers for the GC that require extra
shifts and tests, e.g. OCaml is 3x slower than F# on the int-based Monte
Carlo part of the SciMark2 benchmark (see the OCaml Journal article for
details). OCaml is slow on the float versions because it is unable to unbox
floats passed by recursive function calls. The latter problem can be solved
without leaving OCaml by rewriting in Fortran 77 style but it is ugly.

.NET's JIT-time monomorphization solves these problems in F# and,
consequently, F# on .NET is often much faster than any other FPL including
OCaml. Moreover, the designs of all of those FPLs predate VMs like the JVM
and .NET which is why none of them are capable of these kinds of
optimization.

This is not rocket science but, despite the availability of excellent
solutions like LLVM, there are no longer any modern open source functional
programming language implementations. This is a great shame because
functional programming is really taking off right now and a lot of people
would benefit from a decent foundation. The problem is that the programming
language researchers are the only people who know what they are doing but
they have no incentive to build decent foundations for the next generation
of functional programming languages. So they are all building separately on
sand, Greenspunning uninteroperable run-time environments and garbage
collectors. Mono is the nearest thing to an alternative (the JVM lacks tail
calls) but it is a joke compared to .NET, as you have shown.

So Microsoft now have a monopoly over modern functional programming
languages.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u