Re: Garbage collection

"Nick Roberts" <nick.roberts@acm.org>
23 Aug 2004 12:06:40 -0400

          From comp.compilers

Related articles
[7 earlier articles]
Re: Garbage collection vbdis@aol.com (2004-08-10)
Re: Garbage collection gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-08-11)
Re: Garbage collection nick.roberts@acm.org (Nick Roberts) (2004-08-13)
Re: Garbage collection t.zielonka@zodiac.mimuw.edu.pl (Tomasz Zielonka) (2004-08-13)
Re: Garbage collection antti-juhani@kaijanaho.info (Antti-Juhani Kaijanaho) (2004-08-15)
Re: Garbage collection gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-08-15)
Re: Garbage collection nick.roberts@acm.org (Nick Roberts) (2004-08-23)
Re: Garbage collection sk@z.pl (Sebastian) (2004-08-23)
Re: Garbage collection sk@z.pl (Sebastian) (2004-08-23)
Re: Garbage collection nick.roberts@acm.org (Nick Roberts) (2004-09-03)
Re: Garbage collection sk@bez.spamu.z.pl (Sebastian) (2004-09-07)
Re: Garbage collection usenet@leapheap.co.uk (2004-09-13)
Re: Garbage Collection eifrig@blaze.cs.jhu.edu (1992-08-09)
[5 later articles]
| List of all articles for this month |

From: "Nick Roberts" <nick.roberts@acm.org>
Newsgroups: comp.compilers
Date: 23 Aug 2004 12:06:40 -0400
Organization: Compilers Central
References: 04-08-032 04-08-054 04-08-071 04-08-081 04-08-094
Keywords: GC, performance

On 15 Aug 2004 22:16:47 -0400, glen herrmannsfeldt <gah@ugcs.caltech.edu>
wrote:


>>> There is a story of someone testing the cache memory
>>> characteristics of a machine with C code like:
>
>>> int *a,*b,i;
>>> a=malloc(100000000);
>>> b=malloc(100000000);
>>> for(i=0;i<100000000;i++) a[i]=b[i];
>
>>> It would seem that this would require moving enough data to
>>> completely flush the cache, but it might not.
>
>> An interesting test, but not really a fair test of a machine's
>> speed, since it is somewhat unrepresentative of real workloads.
>
> You mean moving 1e8 bytes isn't fair, or copying the same
> page many times, inside the cache?


I didn't mean copying the same page many times, since I didn't
realise that was what the above code would do (it presumably would
while reading the b array, under the regime you mention).


I simply meant that copying a very large (100 MB?) linear chunk of
memory is not a fair test of a machine's speed, because real
applications will very rarely do this (I'm sure it will be done
occasionally, but not very often).


I understand that one measure made by suites designed to
realistically test out the performance of a machine is of a very
large number of small block moves, say 50 bytes each, spread around
an assumed working set of 10 to 20 MB.


--
Nick Roberts


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.