[erlang-questions] how much time required to pass messages.

[Vikrant]

Thanks Per, for pointing out the typo!
and you all right on time resolution side. After correcting the problem
pointed above, it turns out that, time taken to pass message is indeed very
small  and it is less than timer resolution (on my machine it is coming out
to be average of 0.6 microseconds per message).

very impressive :) it does it very fast!

Now next stuff I wonder, will the time required to pass message depends on
what is being passed through message? guess is that it should. Because on
process boundaries the data is copied.... copying will take time which will
depend on the data itself.

I will experiment on it further....

thanks all!

(Vikrant)

2009/4/2 Per Gustafsson <perjgus@REDACTED>

> It's because you are dividing the measured time by N. Otherwise sending
> messages in Erlang would be very fast indeed (less than a clock cycle).
>
> Per
>
> 2009/3/31 Vikrant <vikrant.patil@REDACTED>
>
>> even if timer resolution is the reason why we don't see the change in
>> time, question remains same. why the change in time scales with M(number of
>> messages) and NOT with N (number of processes + number of messages)!
>>
>> 2009/3/29 Carsten Schultz <carsten@REDACTED>
>>
>>> Vikrant schrieb:
>>> >
>>> > 26> tokenring:tokenring(10000,1).
>>> > Time required to pass message 10000 times=3.00000 (4.40000) microsecond
>>> > .ok
>>> > 27> tokenring:tokenring(20000,1).
>>> > Time required to pass message 20000 times=3.00000 (4.65000) microsecond
>>> > .ok
>>> > 28> tokenring:tokenring(30000,1).
>>> > Time required to pass message 30000 times=3.33333 (4.63333) microsecond
>>> > .ok
>>> >
>>> > (time in bracket is system time and time outside bracket is user time
>>> in
>>> > microseconds.)
>>> >
>>> > This is surprising to me! I expected that time required to pass token
>>> > along N processes should be proportional to N!
>>>
>>> My guess here is that the resultion of the timer is 1/3.  So your
>>> results are 9, 9, 10.  Considering that these are rounded and that your
>>> function will have a constant term, these numbers are just to small to
>>> allow you to deduce much about your runtime function.  Change the second
>>> parameter into, say, 1000000 in all cases and see what happens.
>>>
>>> --
>>> Carsten Schultz (2:38, 33:47)
>>> http://carsten.codimi.de/
>>> PGP/GPG <http://carsten.codimi.de/%0APGP/GPG> key on the pgp.net key
>>> servers,
>>> fingerprint on my home page.
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090402/436acd7c/attachment.htm>