> If I were doing the benchmark, I would just run it on a VM with a single physical core. I think that's definitely an environment worth benchmarking on - but

> If I were doing the benchmark, I would just run it on a VM with a single physical core. I think that's definitely an environment worth benchmarking on - but I don't think that it should be the only environment to benchmark on. Also, I don't think it's a good reason to limit implementations to a single thread, even if that is your benchmark environment. It can be worth seeing how well an implementation that's capable of taking advantage of multiple cores/CPUs, does when it's only given one core to work with. It's probably worth optimising for and benchmarking different threading strategies too - does your implementation create one thread per "work unit" and let the scheduler work them all out, or does it create one a one thread per core (or maybe, one thread per core, plus one), thread pool, and assign work units to each each thread until they're done? And how do those strategies work if they're only given a single core? The single core case is definitely worth testing, but it seems odd to limit implementations to a single thread because of it. If you think you can go faster with a threaded implementation, you should be able to try that out.