# [erlang-questions] Erlang arithmetics

Dmitry Demeshchuk demeshchuk@REDACTED
Mon Nov 1 11:21:15 CET 2010

```Thanks for the explanations, guys. I'll need to fill that empty hole
in my computer science knowledge, along with the other ones :)

At the beginning, I was too stupid to understand the fact that the
whole "arithmetics" question concerns a lot of different conditions,
like what we calculate and which algorithm we use. As well as that
different operations like function calls, arrays or lists walking have
different cost for different platforms.

So, in the "arithmetics" section I'll put this explanation with a note
that some comparison can be seen at the links provided by Isaac Gouy,
but most likely they are also very synthetic and not reliable.

Of course, the comparison of web servers will take place as well. It
won't be fair as well (because the implementations will differ a lot)
but will somehow show how both the platforms can handle this task.

Thank you all again.

On Mon, Nov 1, 2010 at 6:08 AM, Richard O'Keefe <ok@REDACTED> wrote:
>
> On 30/10/2010, at 9:03 PM, Dmitry Demeshchuk wrote:
>
>> Greetings.
>>
>> I'm writing an article comparing Erlang and Node.js and I stumbled
>> upon the performance question.
>
> Jest:  it looks more like you tripped over it.
>>
>> My initial goal was to compare some basic arithmetics speed, like the
>> total distance between randomly distributed points.
>
> It seems strange to see floating point called *basic*.
>
> I see that you did not include random number generation in your
> measurement.  Wise of you.  To give you
> some figures I happen to have for a recent simulation in C:
>
>      "Time with checking and -g  : 16.5 seconds.
>       Time sans checking and -O3 :  9.4 seconds using drand48().
>                                     8.9 seconds using my_drand48().
>                                     7.5 seconds using Mersenne Twister."
>
> drand48() is the classic System V 48-bit linear congruential generator,
> done using 16-bit chunks.  my_drand48() is the same algorithm done using
> 64-bit arithmetic and with no locking.  The Mersenne Twister is the
>
> So within *ONE* language with *ONE* compiler on *ONE* platform there was
> a factor of 1.75 from compiler options and a factor of 1.25 from random
> number generator.
>
> The Erlang random number generator is AS183 (about the speed of drand48()
> or somewhat slower), and it's written in Erlang.  In OSSP js, Version 1.6
> Math.random() is implemented in C.  (It looks pretty much like my_drand48().)
>
> However, the fact that Erlang and JavaScript don't use the same generator
> means you're not measuring the same calculations.
>
>
>> So, I have written
>> the following code for Erlang:
>>
>> =====================================================
>>
>> -module(arith_speed).
>> -export([
>>    test/1
>> ]).
>>
>> test(N) ->
>>    L = lists:seq(1, N),
>>    [{X0, Y0} | Points] = [{random:uniform(1000),
>> random:uniform(1000)} || _ <- L],
>>    Now = now(),
>>    lists:foldl(fun move_to/2, {0, {X0, Y0}}, Points),
>>    timer:now_diff(now(), Now).
>>
>> move_to({X, Y}, {Sum, {X0, Y0}}) ->
>>    {Sum + math:sqrt((X - X0) * (X - X0) + (Y - Y0) * (Y - Y0)), {X, Y}}.
>
> This would not be the fastest way to do it.
>
>        test(N) ->
>            Data = [{random:uniform(1000),random:uniform(1000)}
>                   || _ <- lists:seq(1, N)],
>            Before = now(),
>            _ = path_length(Data),
>            timer:now_diff(now(), Before).
>
>        path_length([{X0,Y0}|Path]) ->
>            path_length(Path, X0, Y0, 0.0).
>
>        path_length([{X,Y}|Path], X0, Y0, Length) ->
>            Dx = float(X - X0),
>            Dy = float(Y - Y0),
>            path_length(Path, X, Y, Length + math:sqrt(Dx*Dx + Dy*Dy));
>        path_length([], _, _, Length) ->
>            Length.
>
> would probably be faster.  In fact, native-compiled on an elderly
> 500MHz UltraSPARC II, this version is 3/7 the time of the original code.
> (Using Dx = float(X - X0) does actually improve the results a fair bit.)
>
> Note that the original Erlang code and the original Javascript code do
> rather different things.
> (1) The Erlang code uses a higher-order function,
>    the JavaScript code does not, even though higher order functions
>    are available in JavaScript.  (Good for JavaScript, bad for Erlang.)
> (2) The Erlang code represents a point by an 2-element array with
>    elements extracted by pattern matching; the JavaScript version uses
>    objects with fields at least notionally found by searching a hash
>    table.  (Good for Erlang, bad for JavaScript.)
>
> Note also that there are *huge* performance differences between JavaScript
> implementations.
>
> I suspect that a much more relevant benchmark for many potential users
> of Node.js would be something like "how many clients can a hello world
> server like the one on the nodejs.org home page serve at once?"
>
> (Hey, if it _isn't_ relevant, what's it doing on the home page?)
>
>
>

--
Best regards,
Dmitry Demeshchuk
```