Board index » delphi » Fastcode IntToStr B&V version 0.31

2005-10-03 02:01:49 AM
delphi82
Released on attachments.
This includes the fixed JOH functions.
 

Released
www.fastcode.dk/fastcodeproject/fastcodeproject/61.htm
I still see FastMM4.
I still see 3 different benchmarks for IntToStr32.
I still see two challenges in one B&V.
Best regards
Dennis
 

there.
ones to remove and which one to keep.
functions which have different accuracies: they have the same name and
most algorithms are portable between the two subchallenges. Therefore i
think these belong together in the same B&V.
 

Hi Avatar
It is very easy to pick the best benchmark based on these results. No voting
needed.
There are so many details to take care of in a challenge :-)
Regards
Dennis
 

"Dennis" <XXXX@XXXXX.COM>writes
more logical to just maintain just one B&V (the RTL only contains one
IntToStr function).
I would prefer simlar functions to be grouped into a single B&V wherever
practical (ie Pos, PosEx and PosIEx) since these functions will often be
very similar or even use each other.
eg. My preferred (and very small) Pos replacement function is:-
function PosJOH_IA32_X(const SubStr : AnsiString; const Str : AnsiString) :
Integer;
asm
mov ecx, 1
jmp PosEx_JOH_IA32_X;
end;
where PosEx_JOH_IA32_X is my fastest PosEx function.
This function may be 1-2% slower than the fastest possible Pos replacement ,
but is real-world use the saving in cache usage make the speed difference
insignificant.
regards,
John
 

Hi John and Avatar
Then you suggest that we rework all previous B&V's and challenges and the
point system?
Best regards
Dennis
 

Hi John
hit with a smile.
Regards
Dennis
 

Hi
IntToStr32 and IntToStr64?
Should we have one B&V per challenge?
Regards
Dennis
 

Hi John
Post like this makes me feel bad ;-)
It is like you throw a bomb into the middle of the entire project setup.
It is like I should spend my time reworking the concept every two days. I
can think of something more fun and productive.
We have always had the three overloaded floating point functions collected
in one challenge.
We have always had Int and Int64 functions separated into each own
challenge.
We have never had combined challenges for CharPos and CharPosEx etc.
If this should change and we also want consistency then you ask me to rework
around 50 challenges and B&V's. This is the last 3 years work. I can see the
argument for keeping IntToStr32 and IntToStr64 in the same challenge, but it
will introduce inconsitency into our project.
Your last suggestion will seriously mess everything up. I think that you
conclude that we should change the entire Fastcode setup just because you
want to reuse PosEx in your own library.
If I should answer politely to all suggestions like this everyday then there
will be no new challenges or libraries.
I think that we all had a decent communication about these issues in the
last status thread. Should we repeat that again?
Best regards
Dennis
 

changes. Points can simply be awarded per sub-challenge.
 

single B&V program. This challenge has two sub-challenges: IntToStr32
and IntToStr64. This is the current situation (except that the first
sub-challenge should be renamed to IntToStr32 which more clearly marks
it as a subchallenge of IntToStr).
 

Hi
What about consistency with previous challenges such as MaxInt versus
MaxInt64? Should we throw that away?
Why is it a problem to have two challenges?
Tell me how you want to give points.
Best regards
Dennis
 

"Dennis" <XXXX@XXXXX.COM>writes
open or already closed challenges. I am just making proposals for what I
would like to see in future challenges (2006 challenges?).
If I have to choose between a 300 byte function and 10 byte function which
is 1% slower, I'd choose the smaller version. I know you disagree with
this.
We now have many very fast functions but do not even reuse them ourselves
(because the Fastcode rules do not apply size limitations or penalties for
Non-RTL function). This effectively prevent us from reusing them within
other Fastcode functions. (Pos can use PosEx, CharPos can use CharPosEx,
IntToStr64 can use IntToStr etc).
If I create a 10-Byte Pos function which simply uses the current system
PosEx it would be slow but only count as 10 bytes in size. If I instead use
my own faster PosEx function with it, it would be fast but count as approx.
200 bytes in size. This couldy make a winning function into a losing one.
When Borland release Dexter with a faster PosEx, the 10-Byte function could
then become a winner again (but only on Dexter).
I therefore propose that using existing Fastcode RTL replacement functions
should not be counted as part of the code size of any function, and that all
functions (not just RTL candidates) should have some degree of
size-weighting.
regards,
John
 

Hi John
Regards
Dennis
 

Hi John
Regards
Dennis