V3:
-j1 -8ep - 103s
-j2 -8ep - 118s
-j4 -8ep - 37s
-j8 -8ep - 26s

 -j1: 0m43.917s
 -j2: 0m24.247s
 -j3: 0m18.118s
 -j4: 0m14.752s
 -j5: 0m12.700s
 -j6: 0m11.321s
 -j7: 0m10.283s
 -j8: 0m9.496s
 -j9: 0m9.571s
-j10: 0m9.408s
-j11: 0m9.359s
-j12: 0m9.231s
-j13: 0m9.094s
-j14: 0m9.077s
-j15: 0m8.990s
-j16: 0m8.954s

v1 vs v3 vs v4
j1 103x  104x  106x
j2 106x  115x  207x
j3 203x  225x  306x
j4 298x  326x  402x
j5 381x  426x  492x
j6 460x  521x  566x
j7 543x  615x  645x
j8 620x  670x  705x
j9 685x  710x  768x
j10 705x  625x  765x
j11 725x  670x  699x
j12 740x  680x  688x
j13 750x  675x  683x
j14 752x  670x  676x
j15 750x  650x  675x

My results with the v4 binary:
[...]
Excellent scaling here up to -j6 (having 6 cores here...)

flac git-f8cb7f08.  The times are very similar to flac git-1357f844. 

[...]
Abusing 16 threads gives the same time as real 8.

Again my simple numbers. Looks fast and scaling is fine.
[...]

When going above j12 with my 12core/24thread CPU -8ep still sees small benefits up to j16 but from j17 on it  becomes extremely slow to 1 thread it seems. Was there a mention of this limit i did overread?

#define FLAC__STREAM_ENCODER_MAX_THREADS 16
#define FLAC__STREAM_ENCODER_MAX_THREADTASKS 34

Nice find, thanks. Lets wait for ktf what is the reason for this.

It might make sense for the thread count to track consumer x86_64 physical cores, which currently tops out at 24 with the 13900k, or track consumer threads which currently tops at 32.

Is there any scope to reduce the per-core memory footprint?

~$ sleep 1; for I in {1..3}; do for J in {1..16}; do echo -n "$J "; /usr/bin/time -v ./flac-v4 -fsj$J -8 /media/test.wav /media/test.wav /media/test.wav /media/test.wav /media/test.wav 2>&1 | grep "Maximum resident"; done; done
1 	Maximum resident set size (kbytes): 3584
2 	Maximum resident set size (kbytes): 7264
3 	Maximum resident set size (kbytes): 7816
4 	Maximum resident set size (kbytes): 8372
5 	Maximum resident set size (kbytes): 8164
6 	Maximum resident set size (kbytes): 11196
7 	Maximum resident set size (kbytes): 12600
8 	Maximum resident set size (kbytes): 13516
9 	Maximum resident set size (kbytes): 14052
10 	Maximum resident set size (kbytes): 16736
11 	Maximum resident set size (kbytes): 19920
12 	Maximum resident set size (kbytes): 18620
13 	Maximum resident set size (kbytes): 19632
14 	Maximum resident set size (kbytes): 23604
15 	Maximum resident set size (kbytes): 24572
16 	Maximum resident set size (kbytes): 25028

1 	Maximum resident set size (kbytes): 5456
4 	Maximum resident set size (kbytes): 26384
8 	Maximum resident set size (kbytes): 63704
12 	Maximum resident set size (kbytes): 78156
16 	Maximum resident set size (kbytes): 108120

1 	Maximum resident set size (kbytes): 7552
4 	Maximum resident set size (kbytes): 45320
8 	Maximum resident set size (kbytes): 84968
12 	Maximum resident set size (kbytes): 126768
16 	Maximum resident set size (kbytes): 159012

Wombats CPU is 12c24t.

The 13900k is 8p+16e aka 24c32t.

A rule of thumb for hyperthreading is that it normally provides a -5 to +30% benefit relative to no SMT depending on the workload, with outliers in both directions. It's no surprise that wombat shows a +13% benefit from -j12 to -j24.

@Replica9000 for CDDA with -8ep your compile seems 13-28% slower on my i7-4790K.

• If I download an album as .wav (there are still sources who only offer that as lossless format), I might want to run flac -8pr7 *.wav and be done ASAP - in execution time ("wall time"). Even if the CPU might throttle at the end of the process, I might save time if the encoder starts firing all guns at once.
  
• Longer job: overhead matters more. Likely you want as many cores to run as keeps a reasonable thermal equilibrium.
• Testing right now. A more complicated task, where we want both total time measured and threadseconds (to scrutinize idle time vs overhead).
  The answer to the first question on top might - for all that I know - suggest that <certain consideration> is not particularly interesting, it will be gone once the user runs multiple input files, so ... ? 
   
  

timer64, "Global time" surely but also "Process time" - or some other utility?
Powershell measure-command returns execution time, but nothing else?

If you call the encoder to process multiple files, isn't that where you can multi-thread with very little overhead?

Reason to ask this first is this question about what we should measure - and what utilities to use and read off the numbers.

For setting -8, using 4 threads gives a 3.9x speedup and on -5 it gives a 3.75x speedup.

Another thing is that my Linux vs Windows benchmarks indicate that Linux seems to perform better with lower thread count while Windows do the opposite, I don't know if it is expected or due to differences in measurement methods. With a built-in benchmark I don't need to worry about this.

-j1:    Average time =  14.054 seconds (3 rounds), Encoding speed = 769.30x
-j2:    Average time =   7.637 seconds (3 rounds), Encoding speed = 1415.74x
-j3:    Average time =   5.364 seconds (3 rounds), Encoding speed = 2015.79x
-j4:    Average time =   4.172 seconds (3 rounds), Encoding speed = 2591.36x
-j5:    Average time =   4.166 seconds (3 rounds), Encoding speed = 2595.30x
-j6:    Average time =   4.817 seconds (3 rounds), Encoding speed = 2244.71x
-j7:    Average time =   5.061 seconds (3 rounds), Encoding speed = 2136.34x
-j8:    Average time =   5.175 seconds (3 rounds), Encoding speed = 2089.41x

-j1:    Average time =   9.710 seconds (3 rounds), Encoding speed = 1113.53x
-j2:    Average time =   5.570 seconds (3 rounds), Encoding speed = 1941.00x
-j3:    Average time =   4.194 seconds (3 rounds), Encoding speed = 2578.17x
-j4:    Average time =   5.593 seconds (3 rounds), Encoding speed = 1933.02x
-j5:    Average time =   6.210 seconds (3 rounds), Encoding speed = 1740.97x
-j6:    Average time =   6.525 seconds (3 rounds), Encoding speed = 1657.01x
-j7:    Average time =   6.838 seconds (3 rounds), Encoding speed = 1581.09x
-j8:    Average time =   6.995 seconds (3 rounds), Encoding speed = 1545.68x

Lets be careful not to wander into FLACCL territory where it encodes at 999999x rate but initializes for several seconds on every file, ending down slower than FLAC.

Quote from: Porcus on 2023-07-22 18:10:12

If you call the encoder to process multiple files, isn't that where you can multi-thread with very little overhead?

Yes, of course. But that would only benefit the flac command line tool, and I was worried how console output should be made easy to understand.

Also, multithreading over files is already possible with various utilities like GNU parallel. The approach with multithreading over a single file can benefit all libFLAC users, and is not achievable with other tools.

• If it is just one single file, it will be done in one second anyway, you can get it down to half a second but who cares if you cannot get it down to a third of a second - end-users get impatient over seconds to wait, not over percentages;
• Yes it would matter if user has 300 such small files and start encoding them all by invoking flac -0 *.wav, but then speed-up is better achieved by passing one file to one thread
• So for -0 encoding, maybe not spawn too many threads per file? Maybe even just one?
• ... well maybe if the input is big, there is a gain? Which you might not even know in advance, it could be piped. Is there some read buffering going on? What about: for light enough settings (fixed-predictor encoding or so, taking into account whether stereo decorrelation is invoked), do not assign a new thread until you have read B bytes, B being quite a sizable chunk.
  So: a file that would be done in the blink of an eye (or where the potential time saved is just the blink of an eye) won't get more than a thread or two anyway.

Quote

Reason to ask this first is this question about what we should measure - and what utilities to use and read off the numbers.

Most importantly wall time.