Celero v2.0.5

This release re-adds the code to automatically compute some reasonable iteration count and sample size.

The documentation was updated for this as well. In short, simply set your sample size to zero and Celero will attempt to do your job for you.

BENCHMARK(DemoSimple, Complex1, 0, 0)
{
    celero::DoNotOptimizeAway(static_cast<float>(sin(fmod(UniformDistribution(RandomDevice), 3.14159265))));
}

Will produce something like:

-----------------------------------------------------------------------------------------------------------------------------------------------
     Group      |   Experiment    |   Prob. Space   |     Samples     |   Iterations    |    Baseline     |  us/Iteration   | Iterations/sec  |
-----------------------------------------------------------------------------------------------------------------------------------------------
DemoSimple      | Complex1        | Null            |              30 |         4194304 |         1.00535 |         0.20928 |      4778189.16 |

You can see that the specification of 0 samples and 0 iterations produced 30 samples and 4194304 iterations when it runs. This is based on making numerous measurements before actually running the experiment to determine reasonable values for these two numbers.

Celero v2.0.4

This release updates the "Sorting Random Ints" example and updates the documentation accordingly.

Celero v2.0.3

This release contains minor documentation updates and compiler-specific fixes.

Celero v2.0.2

This version changed the default problem space value created when no problem spaces are specified by a benchmark. In the previous release, if no problem space value was defined, then Clero would create a problem space with a default value of zero. This release changed this to the constant TestFixture::Constants::NoProblemSpaceValue. The core problem is that if nothing is done at all to add a default problem space, then the number of iterations for a result is not set, and the benchmark code is ran only a single time. There is a better solution for this, but this should be an improvement for now.

This release also added a new demo for finding the fastest way to convert an integer to a std::string.

Celero v2.0.1

The update to v2.0.0 improved the way experiment values and units were implemented. However, there was an oversight in that if these more complex features were not used, only a single iteration of the code under test was executed. This was resolved in v2.0.1. No API changes were implemented. Minor documentation updates were also performed.

Celero v2.0.0

This release adds a few great new features. First, it allows for automatic threading of test cases using fixtures and a user-defined number of concurrent threads.

Second, this version allows the user to define a hard-coded baseline measurement for measuring performance against real-world measurements, hardware, or time requirements.

Finally, Celero now allows for dynamic control of the number of iterations based on the problem space value. This means that you can ramp-down the number of iterations as problem complexity increases which can decrease the amount of time required to make the measurements while maintaining accuracy for both large and small data sets.

Celero v1.2.0

This release includes multithreaded tests and user-defined units for expressing results. This was tested using GCC, Clang, and Visual Studio on x64 architectures.

Celero v1.1.1

• This release fixes the previous release not properly running benchmarks which lacked a problem space definition.
• Console output was completely revamped.
• Table output was completely revamped and expanded.
• README.md and CONTRIBUTING.md were updated.

Celero v1.1.0

This version of Celero includes two new test fixture functions: onExperimentStart and onExperimentEnd. Unlike setup and teardown, these functions are called each once for ever N calls to the benchmarking function and are included in the measurement.

Celero v1.0.9

This version adds a new directory structure to support demo projects as well as experiments. Users are encouraged to submit their own demo and experiments projects (following the project naming convention and general CMake format) on the "develop" branch.