Multithreading on asymmetric multiprocessing systems

[vnair81]

The multithreading support on zstd is a great performance booster on modern multi-core CPUs. We've been getting favorable results utilizing it by setting ZSTD_c_nbWorkers to be equal to the number of threads the system can execute simultaneously.

However for hardware like Apple Silicon Macs, where not all cores are built for performance, it can be tricky deciding number of threads to specify in ZSTD_c_nbWorkers. Specify too many threads and some which get assigned to efficiency cores would lag behind the others. Specify too little and you might be leaving potential gain on the table. Even if you manage to find the number of performance cores and only create that many threads, there is still no control on which thread gets executed on which core.

Apple recommends using GCD for Apple Silicon (https://developer.apple.com/news/?id=vk3m204o), but that would mean moving away from the generic pthread implementation which works on all posix systems.

Has there been any explorations on how to optimize zstd performance for such asymmetric multiprocessing systems?

[terrelln]

Multithreaded Zstd breaks the input up into chunks, and each chunk gets compressed independently in parallel. These chunks get sent to a queue, and the first free thread picks up the next chunk.

The only problem I can imagine with using the slower cores, is that the newest job can only get so far ahead of the oldest job. That limit is + 2 to limit memory usage, under the assumption that all threads will compress at about the same speed. With asymmetric multithreading, that is no longer the case, and we may need to allocate more slack space, like + nbWorkers + 2.

zstd/lib/compress/zstdmt_compress.c

Line 1264 in 413b319

size_t const nbSlackBuffers = 2 + (mtctx->targetPrefixSize > 0);

[vnair81]

Interesting @terrelln!

Does this mean that we can avoid potential slowdown on asymmetric multiprocessing systems without modifying ZSTD_c_nbWorkers, by allocating more memory for the queue?

[terrelln]

Yeah, I think so. But, it would need to be measured to pick the right tradeoff of memory usage vs. speed.