Fastcode conventions

Challenge state definitions


The description and specific requirements for the challenge are defined. Initial benchmarks and validations are created but are not yet considered thorough enough for proper testing. Initial results are not published and no points are awarded at this stage. The B&V version number starts at 0.1 and remains below 1. Functions are not considered ready.


Validation and benchmarks are considered to be very good, but can still be improved. Benchmark results are published. Points are assigned and winners are elected. Points are entered in the competition. The B&V Version number is greater than 1 and the minor version number increments by 1 for each release. i.e. 1.1 -> 1.2 -> 1.3.
If the benchmark changes then the major version number is rounded up and the minor version number starts at zero again.
i.e. 1.2 -> 2.0


Validation and benchmarks are considered to be thorough. The challenge is closed if we think we have reached the maximum possible speed on all targets If there are significant (definition to be discussed) new entries/benchmarks/validation requirements (perhaps from CodeGear), a competition may be reopened. The major version number increments by 1 and the minor version number restarts at 1. For example, a competition that closes as 1.9 reopens as 2.1. I'm not sure how points would be managed. Would they replace the points awarded previously or should this be considered a new competition? 

Fastcode function naming conventions

A Fastcode challenge entry function must be named like this:


X is the function name.
Y is the initials of the developer. It can be 2,3 or 4 characters.
Z is Pas or the maximum instructionset used.
N is the unique function version identifier.

Some examples of X: Pos, ArcCos, Move

Some examples of Y: DKC, JOH, SHA

Some examples of Z: Pas, IA32, IA32ext, MMX, SSE, SSE2, SSE3, 3dNOW, 3DNOW+

Some examples of N: 1, 2, 3, 4, 5..

Some function name examples


Fastcode B&V version conventions

A Fastcode B&V version consists of three digits like this:


The first digit X is the major version number. This number is incremented when a major change to the B&V tool is made. (i.e.. where the benchmarking code is changed, invalidating all previous results).

First digit X still remains zero for versions that are not considered ready.

The second digit Y is the minor version number. This digit is incremented when a minor change is made, such as adding new validation code or bug fixes. (i.e.. changes that do not affect the previous results).

The third digit Z is for changes that do not affect the B&V tool directly, such as the addition of new user functions.