[erlang-questions] Erlang arithmetics

[Morten Krogh]

Richard,

my comment was for arithmetic on same type integers between 1 and 1000. 
Clearly for bignums, the performance depends on the values.
By type I mean a fixed memory size and machine type. The OP was 
generating random integers between 0 and 1000, so I would assume that
both js and erlang would run with the same speed inpedendently of 
whether he multiplied 500 * 500, say, a million times or random1 * 
random2 a million times.
There could be a difference in the accumulator however, when the 
accumulator reached a critical size.

This statement is interesting.

The actual number of clocks depends on the position of the most
significant bit in the ... multiplier."


I tried testing on a C program that would multiply and sum (and subtract 
to avoid overflow of the accumulator).
The type was int.
It runs with exact same speed whether it is 0 * 0 or 1000 * 1000.

I also tried float multiplication and couldn't see the slightest 
difference between

0*0 and 1000000 * 1000000

in a loop of billions of iterations.

The test was on a intel core duo chip.

But I would be interested in seeing an example of such a difference. I 
guess your link shows that such examples exist.

Cheers

Morten.




On 11/1/10 4:16 AM, Richard O'Keefe wrote:
> On 30/10/2010, at 10:55 PM, Morten Krogh wrote:
>
>> Sorry, I just realized that you are only timing the inner loop, not the random number generation.
>>
>> But why bother with the random numbers then? Shouldn't multiplication and addition run with the same speed for all values of numbers of a given type?
> No.
>
> For example, according to
> http://pdos.csail.mit.edu/6.828/2007/readings/i386/IMUL.htm
> "The 80386 uses an early-out multiply algorithm.
>   The actual number of clocks depends on the position of the most
>   significant bit in the ... multiplier."
>
> Look for "early-out multiply".
>
> Since these numbers were the results of random:uniform(1000)
> they should be particularly nice cases for an early-out multiplier.
> Had they been random:uniform(1000000) the products would have
> been bignums on a 32-bit machine and thus *much* slower;
> bignum operations *definitely* depend on the size of the number.
>
> Nor can you expect the cost of + and * to be uniform for
> floats.  Operations that overflow to +/-infinity may well be
> *very* expensive on some machines.  One popular implementation
> strategy for IEEE arithmetic was to do the easy cases in hardware
> and let the operating system finish the tough jobs.
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>