[clean-list] Speed of native code
Antonio Costa Pereira
costa@ufu.br
Thu, 04 Jul 2002 15:14:04 -0300
> > I wanted to hear if some benchmarks have been done with Clean.
> > The most serious contender in FP is I think Ocamel. It seems to me that
> > Ocamel compiles to fast native code , much faster than e.g. Haskell.
> > So, what about Clean?
> >
> > Cheers
> >
> > Jan and sorry for the typo's
I have seen a lot of benchmarks comparing Clean to C, Ocaml, Oberon,
Eiffel, Haskell, etc. What I could say is that for a reasonably large
program, Clean is marginally faster than the competition. That said, I would
like to explain the concepts.
A large program is defined as a program that is large enough to allow
automatic memory management and safety mechanisms to be faster or
otherwise more efficient than hand coded tools. Even
an average sized Clean program will be only marginally slower than the
equivalent C program (say, two-three times slower). A large program in
Clean is likely to be faster than the equivalent program in C, since C
programmers
would fail in getting efficient implementations of things like memory
management and safety checks. Let us see a few examples
of average sized programs that I have seen written in Clean, C and Ocaml:
1- FFT transforms, wavelet, LMS and other transforms. If the memory
management of the transform is simple or unecessary, as in the FFT
transform, a good C compiler (gcc, msvc or cw) generates code that is
2-3 times faster than Clean code. If the transform requires complex
memory management (like LMS transform, Ferraz-Mello transform),
Clean code using the default memory manager is faster than C code
using, for instance, Boehm_GC. I am not an expert in the field, but
I think the explanation could be that the person who is implementing,
for instance, Ferraz-Mello transform does not succeed in using gc
algorithms as well as the Clean compiler. In general, people who write
this kind of program in C use a library called Boehm_GC.
There are two papers by Dr. A. Soares comparing Clean with other
languages in implementation a signal processing algorithm quite
similar to the Ferraz-Mello transform. One of them is
An EMG Pattern Recognition System Based on Functional Languages
for Protheses Control. A. Soares and F. Berzin. Proceedings of the
XIV Congress of the International Society of Electrophysiology and
Kinesiology, ISBN 3-900928-06-1.
I do not remember the reference of the other paper, however it was due
to appear sometime this year in the Journal of SAMS. In any case,
the conclusion of the paper is:
"The authors noticed that through a judicious use of matrix and vector
manipulation, a functional language can perform as efficiently as
traditional procedural languages, like C or Oberon."
2- Simple matrix manipulation. In this classe of average sized problems,
I include Finite Element packages, Optimization problems (simplex algorithm,
Katchian algorithm, etc), Linear Algebra packages, etc. Most of the
algorithms
of this class are very simple to implement (the algorithms are well described
in a large number of books), do not require GC or safety tools. In this
case, a language like C is marginally faster than Clean. I have compared
optimization algorithms written in Clean, C and Ocaml. I also compared
an simple Finite Element package written in Clean with David Meeker's
FEMM package, which is written in C. Meeker's original program is about
twice as fast as the Clean version. I also compared optimization programs
in C and Clean, getting about the same result.
If the programs are large and complex, a person who is working with a
language
like C ends up spending a lot of effort in things like GC, safety measures
(for
instance, preventing breach of sharing conditions) that Clean checks
at compiling time. In this case, Clean can be faster than C, and certainly
faster
than OCAML.
My conclusion is that speed is not the main problem with Clean. As Dr. Soares
said, Clean is quite competitive, as far as speed goes. It is certainly faster
than
OCAML and, even when it is slower than C, it is not slower enough to make
any difference. I think that the main problem with the language is that
it requires programming schemes and skils that are very different from
procedural
languages. Unfortunately, people who invent and publish algorithms have
procedural languages in mind. A person who is not a very good programmer
may have difficulty in porting those algorithms to Clean. An example
will make this point clear. I know two or three persons who implemented
small finite element packages in Clean. If they have done it in Oberon,
it would be a trivial task. They would take Meeker's package, written
in C, and follow exactly the same schemes. They would declare matrices,
use for-loops, if-then-else, assigniments, etc. In Clean, the work was
very difficult, since it was necessary to use schemes completely different
from Meeker's programming schemes. At every small modification, Clean
compiler would complain that an array requires and * that was not provided.
If you take a look at the final result, you have the impression that the
Clean program is very simple, but believe
me, it was not easy to arrive at that kind of simplicity.
In F# page, the members of the project say:
"Purely functional languages like Haskell are excellent within certain niches,
but unfortunately some simple programming exercises can quickly turn
into problems that require a PhD. to solve."
I think that this is the problem with Clean, not speed. I would advise Clean
programmers to find out syntactic sugars and prog-schemes that would
allow an easier migration from procedural methods to Clean.
Special attention should be paid to array manipulation, GUI and input/output.
Eduardo Costa
>
> >
> > > -----Message d'origine-----
> > > De: Scott J. [SMTP:jscott@planetinternet.be]
> > > Date: jeudi 4 juillet 2002 13:42
> > > À: Clean-list
> > > Objet: Fw: [clean-list] Speed of native code
> > >
> > > Hello,
> > >
> > > I wanted to hear if some benchmarks have been done with Clean.
> > > The most serious contender in FP is I think Ocamel. It seems to me that
> > > Ocamel compiles to fast native code , much faster than e.g. Haskell.
> > > So, what about Clean?
> > >
> > > Cheers
> > >
> > > Jan and sorry for the typo's
> > >
> > >
> > > ----- Original Message -----
> > > From: Jan Brosius <mailto:jscott@planetinternet.be>
> > > To: Clean-list <mailto:clean-list@cs.kun.nl>
> > > Sent: Thursday, July 04, 2002 2:34 AM
> > > Subject: [clean-list] Speed of native code
> > >
> > > Hello,
> > >
> > > Iwanted to hear if some benchmarks have been done with Clean.
> > > The most serious contender in is I think Ocamel. Itmseems that Ocamel
> > > compile to fast native code , much faster than e.g. Haskell.
> > > So, what about Clean?
> > >
> > > Cheers
> > >
> > > Jan
> >
> > _______________________________________________
> > clean-list mailing list
> > clean-list@cs.kun.nl
> > http://www.cs.kun.nl/mailman/listinfo/clean-list
> >
>
> _______________________________________________
> clean-list mailing list
> clean-list@cs.kun.nl
> http://www.cs.kun.nl/mailman/listinfo/clean-list