Fastcode Status

Hi Friends

It has been increasingly hard to manage the project lately. This is due to a
number of reasons. We have become famous and many new people are
contributing to the project or asking about many things. The amount of old
challenges that have to be maintaned grows steadily. D2005 introduced
changes to the compiler and the RTL that we need to handle. The MM challenge
is very big and difficult to handle.

I am currently spending most of my time in this newsgroup. This leaves
nearly no time or energy to make real work. I find that I am being derailed
very often. Many times it is ok because we have to deal with all possible
issues to achieve our high quality standard goal. Sometimes it is not ok.

When is it ok? We need to decide how to handle the MM quality label, the
inline issue, the Delphi version problem etc.

When is it not ok? We decided to support D5 based on a voting. Then we
decided not to support D5 based on a new voting. What went wrong? People did
not consider the huge impact D5 support would have on validation. I spent a
lot of time on this issue. The UpperCase and LowerCase B&V's have given me a
lot of headache too.

My main problem is that programmers tend to forget the overall picture. They
find it very natural to throw in a couple of IFDEF's but fail to consider
the huge impact this has on validation. No one in this forum seems to
understand that one IFDEF creates to versions of a function. Both versions
needs to be validated and benchmarked on all Delphi's and OS's we support.
Two IFDEF's in an MM creates 4 different MM's that all has to be validated
on Win95, Win98, WinMe, WinNT, Win2000, WinXP and Win2003. These 4 MM's
needs to be validated and benchmarked on all processors from 386 and up.
They also need to be compiled in D6, D7 and D2005. This makes 4 * 7 * x * 3
= 84 * x validation and benchmark runs. X is the number of processors. We
have 6 official target processors, but the RTL and Blended categories
contains many processors. We officially support 386, 486, Pentium, Pentium
MMX, Pentium Pro, P2, P3, K6, Athlon etc. This is 15 processors. This makes
4 * 7 * 15 * 3 = 84 * 15 = 1260 validation and benchmark runs. If you throw
in one more IFDEF then this doubles to 2520 runs. The normal solution to
this problem is simply to ignore the 1259 combinations and state that "It
should work". My solution is to start from and end and buy as many PC's as I
can afford, install all the OS's I can get, Compile with all Delphi's and
start doing the tests and writing down results in a spreadsheet.

I have not managed to do many validations and benchmarks in the MM challenge
because I need to spend my time explaining why it is a good idea to do any
validation. Then I need to spend the rest of my time excusing that MMx not
written by me has a "bug".

I sicerely hope that not all of you are against validation.

Currently the Fastcode MM's are released without being tested on most of the
OS's they claim to support. They have not been tested on any old processors
either.

Is this the way you understand the term "high quality"?

I have asked all MM contributors these questions: Is your MM valid at the
Free target? Is your MM valid at the RTL target?
People forget to answer. Sometimes it is obvious that they have not even
read the rules.

Do you have any idea how much effort it takes to sort out all the claims
made by a post like this, by Eric Grange?

"Yes, when we placed D6 to D2005 in the targets and decided to benchmark
against D2005: it introduced the concept of some Delphi version being
faster by using or not using certain RTL functions, and ASM sections
being IFDEF'ed to support version with different BASM capability.
Both of these introduce Delphi version specific optimization (ie. even
if a particular codepath compiles on another Delphi version, it may not
be optimal for that Delphi version)."

"Yes, when we placed D6 to D2005 in the targets and decided to benchmark
against D2005:"

Did we place D6 to D2005 in the targets? Yes kind of - we decided to
validate against them. This is probably the same as placing them in the
targets.

"it introduced the concept of some Delphi version being faster by using or
not using certain RTL functions"

I have a problem understanding this and its relation to our project.

"and ASM sections being IFDEF'ed to support version with different BASM
capability"

Such a sentence raises some very important issues that I have to follow up
upon. Eric claims something - is he right - read old threads - read rules.
Did we make a rule that allows or disallows IFDEF's around a single line of
BASM or around multiple lines of BASM? If we have no rule, and we need one,
then we have to start a discussion and a voting.

"Both of these introduce Delphi version specific optimization"

Which has a huge impact on validation and benchmarking. This is the reason
for skipping D5 support. If a function compiles into different code based on
compiler dependent IFDEF's then the D6 and D7 versions are never
benchmarked. We need to discuss how to handle this. If Eric is correct in
his claim then our concept/rules enables people to realease functions under
the Fastcode brand that compiles into something very slow (or even into a
call to the RTL function) under D6 and D7. Only the D2005 version is a real
part of the challenge. This is an unwanted situation that we need to handle.
This raises a huge discussion, but we need to take it.

(ie. even if a particular codepath compiles on another Delphi version, it
may not be optimal for that Delphi version)."

On and on it goes.

Unofficial libraries: We have had two bugreports lately. Both of them were
related to unofficial libraries. One library did not run on a certain PC due
to an error in the DB'ed version of an SSE3 instruction. The reason that
such a library is unofficial is that it has not been tested under Fastcode.
This particular bug had a big impact because it was causing trouble to a
customer of a SW provider that used the library. We did not test the code.
The SW provider did not test the code. The customer had a breakdown in his
business. Do you understand how big a problem it is to release untested SW
under the Fastcode label?

Would this bug have been discovered in our official testing process? If not
then we have to improve it.

The programmer probably thinks that is was a very innocent bug. Only one
wrong byte value in a DB'ed instruction. The end user had a very different
meaning I think.

The second bug was code that did not compile. How well was this tested?

I think that a general problem is that programmers do not understand what it
takes to create quality SW. We see so many examples of this.

In short: I have big troubles keeping the project on the track and need your
help.

Best regards
Dennis


.

Relevant Pages

  • Re: Fastcode D5 Support
    ... I think D5 support should be voluntary, ... Fastcode is already a part of D2005). ... Validation is only valid for the Delphi version that compiled the source, ...
    (borland.public.delphi.language.basm)
  • Re: Fastcode Baseline Compiler Voting 2
    ... Delphi 5 is unsupported; make sure you validate the functions yourself ... Either we support D5 or not. ... > and generally double the effort of validating and benchmarking. ... validation issue i'll vote blank. ...
    (borland.public.delphi.language.basm)
  • Re: Fastcode MM B&V 0.41
    ... > -The new benchmark by Avatar ... > -Fragmentation validation by Dennis ... - The MM B&V, when opened in Delphi 7, causes some error messages ... because ExplicitLeft and ExplicitTop properties aren't know. ...
    (borland.public.delphi.language.basm)
  • RE: XML Validation problem
    ... the errors for each validation in each webmethod call, ... Microsoft MSDN Online Support Lead ... nature are best handled working with a dedicated Microsoft Support Engineer ... I have a web servicce which receives an XMLDocument and then uses the ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: Summary of (dis)agreements on latewst FastCode developments
    ... Mainform caption = IntToStr Benchmark & Validation Tool for Fastcode Version ... >> I would like to see all subbench results in main report as normal. ...
    (borland.public.delphi.language.basm)