Re: Fastcode CompareMem B&V
- From: "Dennis" <marianndkc@xxxxxxxxxxxxxxx>
- Date: Sat, 31 Dec 2005 17:19:07 +0100
Hi Pierre
You need to argue your points, not just claiming something.
> 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.
SetLength initializes all data to zero?
> 2) The largest compare is up to 1000 bytes. There should be a benchmark
with
> a larger range.
Can you argue that case further. We need to know more about compare sizes in
the real world
These constants define the compare sizes.
MAXMEMLENGTH : Integer = 1000;
SPLITMEMSIZE : Integer = 100;
It is very easy to change that.
This is what happens when nobody cares to help me write the benchmarks or at
least have alook at them in proper time.
> 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.
Aligned at what address?
Mem1 and Mem2 are 4 byte aligned by SetLength via the MM in D2005.
The innerloop could be written as
for Align1 := 0 to 15 do
for Align2 := 0 to 15 do
begin
P1 := @Mem1[Align1];
P2 := @Mem2[Align2];
CompRes := CompareMemFunction(P1, P2, MemLength);
end;
from
for Align := 0 to 15 do
begin
P1 := @Mem1[Align];
P2 := @Mem2[Align];
CompRes := CompareMemFunction(P1, P2, MemLength);
end;
> 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.
At which compare lengths would you branch and how much is the cost af a
mispredicted branch versus the number of clocks necessary to compare those
bytes?
> 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.
Why? A Compare is not depending on which data to compare.
> 6) There should be benchmarks with purposely constructed long sequences of
> data that are the same with the exception of a single mismatch somewhere.
Why?
> 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 ;-).
You have not seen all other entries :-)
Regards
Dennis C.
.
- Follow-Ups:
- Re: Fastcode CompareMem B&V
- From: Pierre le Riche
- Re: Fastcode CompareMem B&V
- References:
- Fastcode CompareMem B&V
- From: Pierre le Riche
- Fastcode CompareMem B&V
- Prev by Date: Re: Fastcode CompareMem B&V
- Next by Date: Eric S's sampling profiler.
- Previous by thread: Re: Fastcode CompareMem B&V
- Next by thread: Re: Fastcode CompareMem B&V
- Index(es):
Relevant Pages
|
