 Up |
|
|
  |
Author: namekuseijinnamekuseijin Date: Jul 31, 2008 01:01
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.
|
| Show full article (1.33Kb) |
|
| | 43 Comments |
|
|
Author: Torben Ægidius MogensenTorben Ægidius Mogensen Date: Jul 31, 2008 01:28
namekuseijin gmail.com> writes:
> 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...
|
| Show full article (1.68Kb) |
|
| | no comments |
|
|
Author: Kjetil S. MatheussenKjetil S. Matheussen Date: Jul 31, 2008 03:50
On Thu, 31 Jul 2008, 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...
|
| Show full article (2.18Kb) |
| no comments |
|
|
Author: John ThingstadJohn Thingstad Date: Jul 31, 2008 04:39
På Thu, 31 Jul 2008 10:01:37 +0200, skrev 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...
|
| Show full article (2.61Kb) |
| no comments |
|
|
Author: Kjetil S. MatheussenKjetil S. Matheussen Date: Jul 31, 2008 04:50
On Thu, 31 Jul 2008, Kjetil S. Matheussen wrote:
> On Thu, 31 Jul 2008, namekuseijin wrote:
>
>> I wonder why most functional programming languages fail so badly at
>> what should be one of their primary main strengths: recursive
>> functions.
...
|
| Show full article (2.32Kb) |
| no comments |
|
|
Author: Abdulaziz GhuloumAbdulaziz Ghuloum Date: Jul 31, 2008 08:50
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.
>
> 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) ...
|
| Show full article (2.61Kb) |
| no comments |
|
|
Author: Abdulaziz GhuloumAbdulaziz Ghuloum Date: Jul 31, 2008 08:54
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.
>
> 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) ...
|
| Show full article (2.60Kb) |
| no comments |
|
|
Author: Espen VestreEspen Vestre Date: Jul 31, 2008 08:20
Pah. This challenge screams for a Gordian Knot solution:
With the most simple memoization applied to the functions, the run
time of the common lisp version is down to a few milliseconds.
--
(espen)
|
| |
| no comments |
|
|
Author: Kjetil S. MatheussenKjetil S. Matheussen Date: Jul 31, 2008 10:42
On Thu, 31 Jul 2008, Abdulaziz Ghuloum wrote:
>
> Now modifying the program to use fixnum and flonum operations when
> appropriate, the run time becomes:
>
> real 0m4.508s
> user 0m4.421s
> sys 0m0.077s
>
In addition, you can probably shave off a few more ms by using
bitwise-ior in tak:
(define (ack x y)
(if (= 0 x)
(+ y 1)
(ack (- x 1)
(if (= 0 (bitwise-ior y 0))
1
(ack x (- y 1))))))
|
| Show full article (0.55Kb) |
| no comments |
|
|
|
|
|
Author: namekuseijinnamekuseijin Date: Jul 31, 2008 11:07
On 31 jul, 05:28, torb...@pc-003.diku.dk (Torben Ægidius Mogensen)
wrote:
> I think the difference is not due to the speed of recursive function
> calls but due to the speed of arithmetic. Most functional languages
> check for overflow at every arithmetic operations, which adds a
> considerable overhead. C does not.
Hmm, I thought languages like Ada, Oberon-2 or Java did check for
arithmetic overflow as well.
|
| |
| no comments |
|
|
|
