 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Dennis
Guest
|
 Posted: Wed Feb 16, 2005 10:55 am Post subject: Re: Fastcode MM Rules |
 |
|
Hi
Is this voting count correct? If it is I will publish the rule later today.
"It is not allowed to use the patching principle for using any functions
such as FastMove and FastFillChar".
For the rule in RTL target: 6 Dennis, Borland, Anders, Bruce, Frederik,
John
For the rule in Free target: 5 Dennis, Anders, Bruce, Frederik, John
Against: 1 Robert
Regards
Dennis
|
|
| Back to top |
|
 |
Dennis
Guest
|
| Posted: Wed Feb 16, 2005 10:57 am Post subject: Re: Fastcode MM Rules |
|
|
Hi Robert
| Quote: | My suggestion of using the System move is for the sole purpose of making
the
benchmarking process fair and transparent, creating "laboratory"
conditions.
Clearly the final published MM could and should use an optimised move
function.
|
Did you read my arguments about what we test is what we sell?
You want to benchmark and validate something and release something else.
This way all benchmarking and validation is not valid for the MM's we
release.
Regards
Dennis
|
|
| Back to top |
|
|
Dennis
Guest
|
| Posted: Wed Feb 16, 2005 2:38 pm Post subject: Re: Fastcode MM Rules |
|
|
Hi John
| Quote: | Observe that the Move functions in the unofficial FastMove patching
library
are not necessarily the winner functions. They are also not officially
validated and benchmarked by the Fastcode project.
|
See below.
| Quote: | We have no officail benchmark results for the FastMove unit and do not
know
how fast it is.
It's easy to test. Just include the FastMove unit (the latest version was
placed in the attachment group today) into the B&V project, and benchmark
the MoveRTLASM function.
On Presscot
MoveDKCSSE3_1
9063
MoveJOH_SSE_5
8738
I could add SSE2 and SSE3 versions, but I am conncerned about code bloat.
DKCSSE3 alone is much larger than all of the FastMove functions added
together.
|
I just follow the rules we have agreed upon. We have decided not to optimize
against size in the any targets except RTL. Also remember that only the used
paths of a big move function are loaded and compete for the small code cache
on P4. The rewerse move section migth not be used at the same time as the
forward move section etc. But sure - a bigger function is more likely to
take up more space in the code caches than a small one.
| Quote: | I could also speed up FastMove by not sharing the common code
between IA32, MMX and SSE, but again, more code bloat.
|
Code bloat is not just code bloat. Only called code will get loaded into the
L1 code cache which is the only resource that is so small that it matters.
Your IA32, MMX, SSE code paths will not be called on the same CPU and will
not compete for the L1.
Adding a SSE3 version will take up place in your .Pas file on the harddrive
only. It will only be loaded on Prescott and in this case the SSE or
whatever slower version will not be loaded.
| Quote: | FastMove is in some respects a compromise between the fastest possible
code
and a practical implementation. i.e.. small (more likely to be in cache),
|
And your functions submitted to the challenge is optimized for speed only -
except the RTL version. If people want maximum speed they should use the
official libraries - I guess.
| Quote: | easy to debug, etc.
|
Very easy to debug which such a great B&V ;-)
Regards
Dennis
|
|
| Back to top |
|
|
Dennis
Guest
|
| Posted: Wed Feb 16, 2005 2:42 pm Post subject: Re: Fastcode MM Rules |
|
|
Hi John
| Quote: | Contrary to popular belief, I too am totally against using RTL patching in
the RTL category (Borland would just not accept it).
|
Fine
| Quote: | I am also against RTL patching in the free target category (but only for
benchmarking reasons). FastMove could always be uses alongside any MM at
a
later time if desired.
|
OK
| Quote: | If FastMove speeds up the MM, then the MM could have been coded better in
the first place.
|
Yes - but not by all  You can all use any of my Move code as you please.
| Quote: | In my opinion, the winning candidate in each category is likely to be
identical, except for the coding of the Move and Fill procedures. I do
not
see any reason for disallowing local CPUID based function selection of
these
local procedures in the free target category.
|
No and we do not
"Free blended: CPU ID based selection of code is allowed. All possible
instructions are allowed. Must run on all processors from 486 and forward"
Regards
Dennis
|
|
| Back to top |
|
|
Robert Houdart
Guest
|
| Posted: Thu Feb 17, 2005 10:34 am Post subject: Re: Fastcode MM Rules |
|
|
Hi all,
Wouldn't it be interesting to have a rule on backward compatibility with
older versions of Delphi ? Nothing so frustrating as finding a great
library/component and not being able to use it because it requires the very
latest Delphi version.
Surely there must be plenty of people still using Delphi 5 or 6.
Robert
|
|
| Back to top |
|
|
Dennis
Guest
|
| Posted: Thu Feb 17, 2005 10:45 am Post subject: Re: Fastcode MM Rules |
|
|
Hi Robert
Yes this is something we have not adressed directly yet. I think it is a
general issue that applies to all challenges.
Regards
Dennis
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
