You are here: Home > Fastcode project > Conventions

The Fastcode Project

Fastcode function naming 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 Borland), 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? 

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