Summary of (dis)agreements on latewst FastCode developments
- From: "Avatar Zondertau" <avatarzt@xxxxxxxxx (please reply to newsgroup)>
- Date: 14 Jun 2005 22:50:26 -0700
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.
> Version numbering without letters
I can live with this
> Caption is inconsistent with our naming conventions.
Please be more specific. Is it the caption of the form or the tab? What do you think it
should have been?
> One B&V for one challenge is our norm.
> Where is the "Benchmark Validate" functionality?
I thought (and still think) that IntToStr and IntToStr64 relate to one-another like
the single/double/extended overloads in some other benchmarks. Perhaps some global
"benchmark all", "validate all" and "report all" features would be nicer though.
> How are benchmark rerun results show? Older B&V's list all results and have
> a button to Clean up by deleting all by the fastest runs of each function.
Currently old results are replaced by new. I can change this. How do you think it
should be? Minimum in the list on the main form and all runs in the report?
> I would like to see all subbench results in main report as normal.
They are there in the report. You can display them on the main form by right-clicking
a column header and selecting "subbenchmarks".
> How do I save results to a .csv?
There is no such feature yet, because appearently i didn't notice it in your
original B&V. I can add it.
> I miss a close button on main form.
I don't miss it; i always use Alt-F4 or the upper-right-corner cross. It's trivial to
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'm open for modification suggestions, like
i've also changed stuff others requested.
> Include 4 versions of functions with different alignment
Like you said yourself somewhere: this should be done in a stable release, not
now yet.
> NO D7 is baseline. We voted for this not long ago. I have repeated it in
> here 27 times today. Please respect all the Fastcode rules and conventions.
Is currently being voted on; it wouldn't have much effect on the B&V tool anyway.
I'll try to maintain Delphi 5 compatibility wherever it isn't harmful to other
versions.
> We normally sort the results so that the winner appears at the top.
On the main form results can be sorted on any column, in both directions. ISTM
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.
>> (post about adding alogrithm to description)
>
> We have function naming conventions.
> I will not help others to spy on my super function :-)
The naming conventions are still obeyed, an algorithm is simply appended to the
names displayed on the B&V. I don't think looking at algorithms used is spying
at all; it's 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.
> All functions released by Fastcode must pass all validations. We do not want
> bug reports on known issues.
Running the large validations is not feasable for now, while stuff still changes.
It simply takes too much time. IMHO it should be done when a stable B&V is released.
> There are no problems in supporting D5 ! ;-)
> Forget about D5. Go download a D2005 trial and use that for Fastcode work.
I still think we should allow people to use their own Delphi version whenever it's
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.
> No problems with having D5 support!
>
> Should we D4 also? Then we only need to run validation on D4,D5,D6,D7 and
> D2005 on 6 PC's this gives you 30 complete validation runs.
Making an effort to support Delphi 5 is not the same thing as officially supporting
it. Even without official support many D5 users will be happy if the FastCode stuff
compiles and runs.
>> Validation is aborted after 256 failures, to prevent validation from
>> filling up the log, taking forever
>
> Exit after 1 error as always.
I think results are more useful if you see multiple log lines reporting failures.
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's 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.
>> I'm considering perhaps copying the source code for the RTL IntToStr
>> into the project. This would solve the problem of the overloading and
>> it would also make sure that the RTL rating is the same for all
>> compilers.
>
> Yes. I sometimes do that also to get all 4 kinds of alignment for RTL code.
> (But we are not allowed to due to license issues?)
I was hoping someone would tell me, because i'm not sure. Replies on this point are
very welcome, especially if they would come from Borland.
> Normally I use the fastest function to set the subbenchmark weigths. I think
> we should continue doing that. Also I normally do it on a P4 which is just
> as incorrect as doing it on a Dothan. We should use blended results as is
> done in Move.
I wasn't sure of the way you did it and didn't have a P4 to test them, so i just
did what seemed right. I guess this is another thing that should be done once the
stable release is released.
> I have made an errortrap in some of my B&V's that can be turned on, but it
> is a good idea to have it in all B&V's. Perhaps the new way is the best one.
> I have not looked at it yet.
You should, it's really neat ;-)
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).
>> Even the solution used by Dennis, copy each function fourfold, is not
>> completely satisfactory, because you can't be sure you're getting all
>> alignments.
>
> You can. Look at the benchmark results where I list alignment. And look at
> the B&V's to learn the technique.
Ok, i hadn't looked into it closely, so i hadn't seen the NOPs. Another stable
release thing i guess.
>>> (suggestion from JOH to include dummy function and
>>
>> That sounds like a very good plan. It will definately result in fairer
>> comparison.
>
>No please do not.
I think you should mostly work this out with JOH, i can live with it either way.
Once you've reached agreement or (if you can't) a poll has been done it can be
changed back if needed.
> Include newest modified JOH function
(just a reminder for myself)
.
- Follow-Ups:
- Re: Summary of (dis)agreements on latewst FastCode developments
- From: Dennis
- Re: Summary of (dis)agreements on latewst FastCode developments
- From: Avatar Zondertau
- Re: Summary of (dis)agreements on latewst FastCode developments
- Prev by Date: Re: New release of IntToStr and Sort Benchmark and validation tools
- Next by Date: Re: Summary of (dis)agreements on latewst FastCode developments
- Previous by thread: Fastcode String Result Rule
- Next by thread: Re: Summary of (dis)agreements on latewst FastCode developments
- Index(es):
Relevant Pages
|
