[erlang-questions] Erlang arithmetics
Mon Nov 1 08:50:35 CET 2010
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
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.
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?
> For example, according to
> "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:
More information about the erlang-questions