Sergey Mechveliani [EMAIL PROTECTED] wrote:
>> [..]
>> E.g. if one uses GHC to compile Haskell code into native code what
>> speed performance can be expected versus a same program written in
>> C [..]
>My experience with the program of generating permutations on
>[1..10]
>showed that the code produced by ghc-4.04 is 22 times slower than
>certain specially written C program.
>Only the C program algorithm was taken very different from Haskell's
>one. For each system has its own best algorithm and appropriate data
>structure.
>But this example task was chosen as unlucky for Haskell.
>In other, average case, I expect the ratio of 6-10.
This seems that Haskell cannot be considered as a language for real world
applications but merely
as a toy for researchers .
Do Ocaml or MLTon (SML) beat Haskell by a factorof 3?
See e.g.
####> What is MLton's efficience versus C?
Here are the times in seconds for a few small benchmarks on my
400 MhZ
Pentium II. For benchmarks that use arrays, I have also included
the
time when compiling with the -unsafe flag, which turns off bounds
checking.
gcc -O2 mlton mlton -unsafe
------- ----- -------------
fft 18.69 31.66 28.69
fib 7.44 9.97
matrix mult 2.65 13.27 6.15
quicksort 17.69 27.80 20.94
tak 15.86 21.99
As you can see mlton -unsafe is within a factor of 2 on all the
benchmarks except matrix multiply, which is 2.3 times slower.
> P.S. As I understand the CPS (continuation passing style ) used
to implement
> SML/NJ will be abandoned as it did not produce small and fast
standalone
> executables
I don't think that CPS is entirely the cause of this. Although, I
do
believe that their use of the heap for allocating stack frames does
slow them down. As to size, I think they just haven't gone to
enough
effort to clean up the exported heaps.
> Is MLton portable to other OSes?
Yes, but it hasn't been done yet. Right now, there is a Windows port
underway by [EMAIL PROTECTED], using a crosscompiler from
Linux (http://www.devolution.com/~slouken/SDL/Xmingw32/). He just
started, so I'm not sure how it will turn out.
I am not aware of any other porting efforts. The current focus of
our
development efforts are improving the performance with an X86 native
backend and adding functionality.
###
>But I am not so sure.
>It is easy to mistake with such comparison.
Cheers
Jan Brosius
