-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 8-Feb-07, at 1:07 PM, Vincent wrote:
--- Marc Feeley feeley@iro.umontreal.ca wrote:
Here's a simple test I ran to give a rough idea of the GC costs.
....
The average GC pause is 4 milliseconds, and GC time represents 2.4% of the total run time ....
Thank you for the sample code. That's a good way to get a rough idea. Thinking further about the requirements of a global P2P network, I think the response times for each node have to be measured in microseconds rather than milliseconds. In telecom networks, packets can travel over long distance fiber links, with fewer nodes to introduce delay. In a global P2P network, packets would have to travel through maybe 100 times more nodes, with shorter distances between nodes, and each node introducing delay. If a packet has to hop through 1000 nodes, the total delay will be the per node delay times 1000. If each node takes 200 microseconds to recieve a packet, and 200 microseconds to send a packet, that's about half a second latency right there.
But 4 milliseconds is the GC pause time and the GC is called infrequently. So very few of the hops in your 1000 node chain will require an extra 4 milliseconds from GC. On such a long chain, the average impact on the latency will be very close to an overhead of 2.4% (so if you assume it takes 400 microseconds worth of pure CPU work to handle a packet, it will take 409.6 milliseconds instead of 400 milleseconds of total latency for 1000 hops). Such a small overhead will be negligible compared to the quality of the generated code, the memory management overhead, the I/O overhead, the process scheduling overhead, etc.
Marc