Flac v1.5.0 introduced -j# or --threads=# to encode a single flac file with multiple threads (up to 128 according to the documentation).
While adding support for this new feature to flacr, I ran a few performance tests with the new multi-threaded encoding.
I thought it might interest a few people how the new multi-threaded encoding compares to the alternative approach of encoding multiple files at the same time with 1 thread each in terms of real world speed.
For this test I've used 100 standard flac files (16Bit/44.1KHz) on a local pci/e 4.0 m2 SSD. The CPU is a Ryzen 5950x (16c32t).
Individual results with screenshots
Baseline with 1 thread: 1.23 files/s
Multi-threaded with 2 threads: 2.36 files/s
Multi-threaded with 3 threads: 3.44 files/s
Multi-threaded with 4 threads: 3.60 files/s
Multi-threaded with 5 threads: 3.55 files/s
Using anything higher than 4 threads actually decreased speed in my testing.
So much so, that using 32 threads (max. on my CPU) is slower than using 2.
Multi-threaded with 32 threads: 2.04 files/s
When using the alternative approach of encoding multiple files at the same time with 1 thread each instead of using multi-threading on one file at a time is significantly faster.
Concurrent encoding with 4 threads: 4.76 files/s
Concurrent encoding with 8 threads: 8.83 files/s
Concurrent encoding with 16 threads: 13.75 files/s
Concurrent encoding with 32 threads: 18.14 files/s
Results summary:
multi-threaded single encode:
| Threads | Speed (files/s) |
|---|---|
| 1 | 1.23 |
| 2 | 2.36 |
| 3 | 3.44 |
| 4 | 3.60 |
| 5 | 3.55 |
| 32 | 2.04 |
concurrently encoding files with 1 thread each:
| Concurrent encodes | Speed (files/s) |
|---|---|
| 4 | 4.76 |
| 8 | 8.83 |
| 16 | 13.75 |
| 32 | 18.14 |
Conclusion and my thoughts:
- When using multi-threaded encoding of a single file, using 3-4 threads seems to be the sweet spot (at least for my CPU). Using more actually decreases the encoding speed.
- Encoding multiple files concurrently with 1 thread each outperforms multi-threaded single file encoding when more than 3-4 threads are available and the storage medium is an SSD. The more threads, the higher the difference in speed (at 32 threads it's already 5.03x faster).
However I think there are still valid use cases for using sequential multi-threaded encoding:
- When fragmentation is unwanted (like on zfs file systems), encoding multiple files at the same time is not recommended as it heavily fragments the files. In this case, encoding one file at a time 2.92x faster than before (using 4 threads vs 1 thread on a single encode) is a huge performance gain.
- When spinning rust (old hard drives) are used, encoding multiple files at once increases seek times and fragments the files, leading to slow read times when the finished files are accessed. This can also be avoided by using multi-threaded sequential encoding.
- When a single very large file is encoded, this is the only possible speedup.
Encoding multiple files concurrently shines in this case:
- When many files are encoded at once, the cpu has many threads available and the storage medium is an SSD. Fragmentation and random reads and writes are fairly irrelevant for SSDs, so in this case the huge performance gain of encoding multiple files at once has no real downside.
Let me know what you think of the new flac cli feature and also if you found different results in your own tests.