Fastcode CompareMem B&V
- From: "Pierre le Riche" <pleriche@xxxxxxxxxxx>
- Date: Sat, 31 Dec 2005 17:43:09 +0200
Hi All,
I'm busy writing my entry for this challenge, and will post it later today.
However, since I've started I've noticed that there is a lot of room for
improvement in the benchmarks:
1) Arrays to be compared are not initialized, so the number of compare
iterations needed to hit the first mismatch is down to luck. This badly
affects the scoring depending in which order the entries are benchmarked.
2) The largest compare is up to 1000 bytes. There should be a benchmark with
a larger range.
3) P1 and P2 are always aligned exactly the same, so if you align reads from
P1 then they will automatically also be aligned for P2.
4) The number of bytes to compare (the third parameter) is monotonically
increased in each benchmark run, thus putting no pressure on the branch
predictor in places where the CompareMem routine needs to branch depending
on the number of bytes to compare.
5) The data to compare is exactly the same for all compares in a given
benchmark (of which there are only 2), all that differs is the compare
length. There should be greater variety in the input data.
6) There should be benchmarks with purposely constructed long sequences of
data that are the same with the exception of a single mismatch somewhere.
Validation seems to be in a much much better state than the benchmarks.
I think these are points we should look at in the coming year. For now I am
happy to take the points ;-).
Regards,
Pierre
--
Fastcode Project: http://www.fastcodeproject.org/
.
- Follow-Ups:
- Re: Fastcode CompareMem B&V
- From: Pierre le Riche
- Re: Fastcode CompareMem B&V
- From: Dennis
- Re: Fastcode CompareMem B&V
- From: Dennis
- Re: Fastcode CompareMem B&V
- Prev by Date: Re: New scoring system poll closed
- Next by Date: Re: Fastcode CompareMem B&V
- Previous by thread: Re: Sonorisation et effets lumiÉres Á prix discount
- Next by thread: Re: Fastcode CompareMem B&V
- Index(es):
Relevant Pages
|