Board index » delphi » Summary of (dis)agreements on latewst FastCode developments

2005-06-15 01:50:26 PM
delphi183
To discuss list for next release. Some more may be added later; still at least 14 posts unread :(
Original points have been marked with '>' for reading ease, though they may not always be literal quotes.
I'm afraid that stuff which i say here is "to do" cannot be done by me soon. I can do it later or any
volunteer can change it before; the B&V source code shouldn't be hard to modify.
should have been?
the single/double/extended overloads in some other benchmarks. Perhaps some global
"benchmark all", "validate all" and "report all" features would be nicer though.
should be? Minimum in the list on the main form and all runs in the report?
a column header and selecting "subbenchmarks".
original B&V. I can add it.
add one though if you really like it.
Keep in mind that i originally released this new B&V tool more as a suggestion
than as a final solution; of course I am open for modification suggestions, like
i've also changed stuff others requested.
now yet.
I'll try to maintain Delphi 5 compatibility wherever it isn't harmful to other
versions.
this is nicer than just sorting on total benchmark score always.
I agree that the report should also be sorted, and consider it part of the
"to do" list now.
names displayed on the B&V. I don't think looking at algorithms used is spying
at all; it is certainly different than copying. In fact i try explicitly to avoid
using algorithms used by others, but i think looking at them can teach you how to
fastcode better and to think of new, better, algorithms.
It simply takes too much time. IMHO it should be done when a stable B&V is released.
not too much trouble. In this case it isn't and i think supporting Delphi 5 in
this case will make FastCode accessible for more people.
it. Even without official support many D5 users will be happy if the FastCode stuff
compiles and runs.
This may allow the writer of the failing function to see what values are failing and
is therefore more useful then getting only one result.
An example on this: many IntToStr64 functions originally fail on $8000000000000000,
which is the first number tested. it is good to know that this is actually the only
failure, because otherwise womething may be more fundamentally wrong. Thus displaying
mulpile validation results may make debugging easier.
very welcome, especially if they would come from Borland.
did what seemed right. I guess this is another thing that should be done once the
stable release is released.
I'm using a memo for logging all B&V actions, including validation failures with
information on what went wrong (result or exception) and when it went wrong (inputs).
release thing i guess.
Once you've reached agreement or (if you can't) a poll has been done it can be
changed back if needed.
 

It turned out the messages left unread were all about call overhead measurement.
I'd like to make a suggestion for a compromise here which i hope satisfies both
parties, unlike the result of a poll, which is likely to disappoint one of the
parties involved.
I suggest we include a conditional define in the application which can enable
dummy function checking, while the default setting in the released B&V tools
has this undefined by default.
This way the application will measure the numbers Dennis wants to show on
FastCode webpages and spreadsheets by default, but JOH and others don't have
to go through any extra trouble to measure results without call overhead. The
result report can display the fact that this define was enabled, so that we
won't confuse the different measurements.
Something like this:
{$UNDEF CompensateCallOverhead}
Default; makes B&V behave as others, just showing the direct measurements.
{$DEFINE CompensateCallOverhead}
Makes B&V subtract call overhead from results, allowing optimizers to see
speed differences more accurately. Adds warning line to result reports
generated.
 

Hi Avatar
The first time anyone claims that he improved the speed of a function with
x% based on a measurement without function calling overhead included, I will
restart the discussion and ask for removal of the feature ;-)
"See speed differences more accurately"
False claim! It will not do this! Remember my calculations. It will just
make the improvements look bigger.
This is important to John because he will abandon optimizations that are
"too" small eg 1% relative to speed of function body.
It is not important to me because I keep all optimizations that gives a
measureable speed improvement. Observe that 8 out of 9 targets do not have a
penalty for size and the fastest function wins. Therefore it does not make
sense to rule out "small" optimizations. In the last target you have you
compare the speed increase to the code size increase. Does the feature help
you do this?
Regards
Dennis
 

Hi Avatar
I only comment if I disagree and you will see that I mostly agree ;-)
It is ok that it takes some time.
y.x
Or all runs everywhere?
Written before we started voting and therefore invalid.
D6-D2005?
But remove functions that fail.
validation. They all have to be fixed anyway. My errortrap gives the
possibility of putting a breakpoint in it and step into the failing function
with the parameters that made it fail.
benchmark runs on all targets to get it rigth.
Regards
Dennis
 

This seems to be an effecitve way of settling differences; the list of
disagreements has been greatly reduced.
Utility" and the tabs say "<<(sub)challenge name>(v<version>)". ISTM
all the information is in there.
replacing the richedit that was used before. It can display the
subbench results by enabling their columns, though by default they are
hidden. IMHO this view provides most clarity, while it is still possible
to get the complete view.
You really think subbenchmark column ought to be shown by default?
function compatible with the old one.
only difference is that CPUID and RDTSC have now been coded using DB
statements (but with comments indicating what the opcode is).
From the programmer POV there are also some conditional compilation
directive, but they are few and IMHO do not harm readability.
Failers on the thorough validation will be removed from the list (and
their authors notified) once that test is done.
That's no solution however. It seems reasonable that Borland allow us
to do that, especially because they benefit from the FastCode project
themselves too. Perhaps you could send an e-mail to the guys at Borland
you know? They may be cooperative and then at least we'll know for sure
what's permitted and what's not.
Do you think we should keep the current scales until then, or is it
neccesairy to already calibrate the scales so that they are based on
the fastest function (be it on only one CPU) instead of the RTL
function?
 

Hi Avatar
Regards
Dennis
 

Hi Again
What do others think?
solution, but do not spend to much time on it. Just use your Dothan for a
start.
Regards
Dennis