Compile time calculations?

[schmide]

There seems to be a trend to pre-calculate sequences that determine the order of operations for many implementations.

Should there be distinctions between the bitmaps and sequences?

If precomputing primes or reusing memory has been declared off the table, where does constexpr and static data fall into the rules?

[rbergen]

Should there be distinctions between the bitmaps and sequences?

I don't think I understand the question, as in why and how this would make sense?

If precomputing primes or reusing memory has been declared off the table, where does constexpr and static data fall into the rules?

They are allowed, as long as they don't break the rules. But again, maybe I don't understand the question.

[schmide]

The point I am poorly trying to make. Pushing execution into the preprocessor may skews results.

The effect may be greater if you run a full dataset (size) through the preprocessor, then measure on the routines created by that simulation.

At some point per-baking factors prior to runtime fundamentally changes the algorithm.

I'm not trying do detract from some of the great innovations (ex striped), but what a preprocessor can do may not always lend itself to real world applications.

The algorithm is relatively simple, other algorithms may not produce such optimizations.

Should this at the very least be quantified? Run with or without constexpr and the like?

[rbergen]

This project started as a comparison between the execution speed of programming languages, by comparing the execution count of the very basic algorithm that the sieve of Eratosthenes is. In that comparison ("drag race"):

1. a basic premise has been from the beginning that the question is how "clever" a particular language can be made at turning code written in the language into sieve runs, using whatever the language in question has in its toolkit. However,
2. some specific implementation boundaries were chosen, that basically represent aspects that are important to the instigator of the whole thing. Those boundaries are now captured in the criteria for the main leaderboard of the project: base algorithm, faithful, 1 bit per prime. The definitions of "base algorithm" and "faithful" are as described in the contributing guidelines, and have stabilized some time ago.

Setting aside that I wouldn't know what a comprehensive definition of "real world applications" would look like and therefore what would be a "proper" algorithm to compare the performance that programming languages can offer when implementing them, my view is that:

1. the sieve of Eratosthenes algorithm clearly does not properly represent many real word applications, and
2. the aforementioned definitions/rules are somewhat arbitrary, and can be argued with (as quite a few have)

That being said, we do use the sieve of Eratosthenes as the comparison algorithm in this project, with the definitions/rules being what they are. This does limit the "real-word application" relevance of the project's benchmark results, and that just is what it is.

In that context, my opinion is that there is no need to make quantification of the impact of inherent language constructs a requirement. At the same time, contributors are free to provide implementation variations that do illustrate this, if they want to do so.

[schmide]

That's fair