Innbundet

I recently realized that I could try to implement the reuse-oriented distributions from part 2 using libdivide instead of native (hardware) division (modulo).

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.

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.

`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+ %.

Without talking about Gustafson's law and the assumptions both make.

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.

Due to maintaining Catch2 and generally caring about SW correctness, I spend _a lot_ of my time thinking about tests. This has left me with many opinions about tests, some conventional and some heterodox.

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.

There is a lot of confusion about floating-point numbers and a lot of bad advice going around. IEEE-754 floating-point numbers are a complex beast, and comparing them is not always easy, but in this post, we will take a look at different approaches and their tradeoffs.

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.

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.

This post is based on an internal training I prepared for my employer, Locksley, and showcases some source-level techniques for improving C++ compilation times.

Last week I wrote about the various problem with using C++'s standard library (mainly <random>) to generate random numbers. This week I will outline what I think are the (standardizable) solutions to fix the functionality in <random> and make it widely usable.

I found myself once again writing a long forum post about the problems with standard-provided random number generation facilities (both C++'s <random>, and C's rand) in C++. Since I keep writing these, I decided to write it all down into one blog post so that I can link it to people later.

In part 1 of this series, we built a Sudoku solver based on translating Sudoku to SAT and then giving the resulting SAT instance to a SAT solver. We also benchmarked our solver and found out that it, unsurprisingly, loses to the state of the art of Sudoku solvers. Since

I just got home from the second conference I gave a talk at during September and decided to write about my experiences while I am slowly decompressing.

In the previous two parts we used a SAT solver as a black box that we feed input into, and it will (usually quickly) spit out an answer. In this part, we will look at how SAT solvers work and what heuristics and other tricks they employ in their quest for performance.