Jun 27, 2024

There are several ways that costly loops can be parallelized, assuming that the design allows the concurrency. There are four loops that can be independently parallel, and setup synchronization can be accomplished via standard library execution policy on loops such as std::all_of(...) or via BOOST ASIO. As std lib execution is only useful for simple loops, we use ASIO for network concurrency. I've learned in the past that the cost of using std lib execution policy can be very high. I tested it for simple two lane parallelization in RIPEMD and the result was horrific compared to just sequential execution. The only place we use it is in concurrency for scrypt hashing execution. In that case it provides a huge benefit with no ASIO complexities or dependency. The database queries are complex and costly, so I figured it was worth a look. Turns out that using an ASIO thread pool, posting closures to the work queue, and tracking completion, absolutely crushes the much simpler loop vectorization. std lib takes 133 mins to ASIO's 79 mins. I'm pretty sure that this type of performance difference would also impact C++20 co-routines. When I started on the network stack rewrite I looked at coroutines, but unlike the the rest of C++20, the reviews weren't good. A thread pool provide significant performance advantages, and these are now very visible.