Re: Fastcode MM B&V 0.41
- From: "Robert Houdart" <robert@xxxxxxxxxxxxxx>
- Date: Wed, 1 Jun 2005 11:00:13 +0200
Hello Pierre,
> As the results grid grows, the memory usage scores of the MMs
> drop... The first MM in a benchmark run has a slight advantage, because
> the
> B&V tool uses less memory at that stage.
We clearly don't want that, but are you sure this is significant?
If you run a benchmark batch with MMs in the order BucketMM first ...
FastMM3 last, and then another in the order FastMM3 first ... BucketMM last,
what's the order of magnitude of the change?
The easiest solution to this problem is to use a batch file in which all MMs
are run twice, the second time in inverse order. Like the following for 4
MMs:
MM1-MM2-MM3-MM4-MM4-MM3-MM2-MM1
In that way all MMs would be handled equally.
> I think we should revisit the way in which we calculate the memory usage
> score. I would propose some kind of sliding scale: A benchmark
> that uses a lot of memory should have a higher memory usage
> weight than one that doesn't.
Using maximum memory usage as a "weight" factor does not seem the right
thing to do. It's not because a benchmark uses more memory that it's more
significant... memory usage is very often just a matter of scaling.
IMO the only benchmarks for which we should so some adjustment is the replay
benchmark. There seems to be a constant overhead of around 28 MB, which we
could subtract from the final memory usage.
Kind regards,
Robert
.
- Follow-Ups:
- Re: Fastcode MM B&V 0.41
- From: Pierre le Riche
- Re: Fastcode MM B&V 0.41
- References:
- Re: Fastcode MM B&V 0.41
- From: Pierre le Riche
- Re: Fastcode MM B&V 0.41
- Prev by Date: Re: filling big array of double
- Next by Date: Re: Fastcode MM B&V 0.41
- Previous by thread: Re: Fastcode MM B&V 0.41
- Next by thread: Re: Fastcode MM B&V 0.41
- Index(es):
Relevant Pages
|