Random distributions are not one-size-fits-all (part 2.5)
I recently realized that I could try to implement the reuse-oriented distributions from part 2 using libdivide instead of native (hardware) division (modulo). … »
Random distributions are not one-size-fits-all (part 2)
In this part, we will look at different algorithms for generating uniformly distributed random numbers and determine whether they fit specific use cases better than Lemire's algorithm. … »
Random distributions are not one-size-fits-all (part 1)
Recently I was again on CppCast, and again I talked about C++'s standard library support for random numbers. One of the things I said was that random distributions are not one-size-fits-all. This post is about how this applies to Lemire's algorithm for generating uniformly distributed integers. … »
The Little Things: The Missing Performance in std::vector
`std::vector` is often said to be the default container, because it provides good baseline performance for common operations. Recently, I experimented with a simple API change that can improve the performance of a common usage pattern by 10+ %. … »
The Little Things: Why you should always have benchmarks ready
At the end of January, I removed some low-hanging allocations from Catch2. This meant that running the SelfTest binary in v3.3.1 made 8k fewer allocations, but it also made section tracking in v3.3.1 ~4x slower. This post is about how that happened and what we can learn from this. … »
NDC TechTown 2022: Trip Report
Last week I was at NDC TechTown 2022, and I decided to write down my thoughts on the talks I saw (including the two talks given at the meetup before the conference) and other related things. … »
The Little Things: Testing with Catch2
In this post, we will take a look at testing with Catch2. First, we will go over the basics, and then we will take a closer look at three more advanced features: Matchers, Generators, and Benchmarking. … »
The Little Things: Everyday efficiencies
Premature optimization is often said to be the root of all evil, because it makes future maintenance harder. I want to show some cases where the faster code is just (or more) as maintainable as the slower one. … »