Impact of native compilation

[Marc Feeley]

> We tried to compare a big amount of floating point operations (100 millions).  
> The result is greatly improved over standard Erlang.  
> The result is also far from the C execution time.  
>   
> We were wondering why the result was different. Is there many more operations  
> implied by Erlang ?  
>   
> The test are at the bottom of this email.  
>   
> I have not yet tested the same example with ETOS. Does someone know the  
> expected impact with ETOS ?  

The main loop of your Erlang benchmark is

 loop(0) ->
     ok;
 loop(Count) ->
     1.0 * 1.234,
     loop(Count -1).

and in C

 for(long i = 0 ; i < 100000000 ; i ++)
 {
   double x = 1.0 * 1.000234 ;
 }

I am sure the C compiler is completely discarding this loop, as it is
dead code (it doesn't contribute anything useful to the rest of the
program).  This is a standard problem in benchmarks which don't compute
something useful...

The Erlang compiler is probably not transforming the loop function into

 loop(_) ->
     ok.

as might be expected because in fact they are not equivalent (for
example if Count is initially negative, or if Count is not an integer
an exception is raised).  Note that the compiler can't be sure from which
module loop is called, and if the call

   timer:tc(?MODULE, loop, [100000000]).

at the top of the module actually calls the loop function defined in
this module (a new version of the module might be loaded just after
timer:tc is called, and before loop is called).  Optimizing Erlang is
not easy due to such subtle semantic points.

So in fact the performance of your code has nothing to do with
the speed of floating point computation!!!

For the record, ETOS has very good floating point performance, thanks
to Gambit-C on which it is based.  On some complex numerical programs
Gambit-C can compile floating-point code as efficiently as C (see for
example http://www.ccs.neu.edu/home/matthias/Scheme2000/lucier.ps).

Marc