ODD SMALL BLOCK SIZES (and a couple more normal-sized)

Because I didn't pay sufficient attention to my own testing, I ran something more - testing blocksizes that nobody wants to use. (Reason for that: make sure there is no partitioning for the residual, so there are no differences in that.)

Took the 219 minute CDDA .wav file and made 30 .flac files:
-0 and -5 at fifteen distinct block sizes, all odd numbers to be sure I didn't test different handling of partitioning.
Most are too low to be interesting! (Why? I'll explain at the end.)
17, 23, 31, 45, 65, 97, 147, 223, 341, 523, 803 <in between here is the -0 to -2 preset blocksize!> 1237, 1907, 2941 <in between here are the other presets> 4537 (ffmpeg uses the subset upper bound of 4608)

Those were encoded repeatedly using different FLAC releases (Xiph builds ... I hope I didn't get that wrong!). Timings for the -0b<N> and -5b<N>:

To the right end of both diagrams, you see that 1.4.3 has gotten rid of the slowdown around the 4096 blocksize, which is good because that is a default.



Then decoding. Note, here the flac versions are different! Because the results were a bit surprising, I dug up 1.3.1 too (a tinytiny bit slower than 1.3.4, I deleted the latter to get the number of curves down) and also 1.2.1. Omitted is also 1.4.2 which is as good as tied to 1.4.3. Kept in both the 32-bit and 64-bit version of 1.4.3 (it being the current release).
And here the block sizes are visible, I lost them from the encoding charts ...

1.3 is much faster at the small block sizes! At the very smallest, 17 samples, it decodes at at 22 seconds, 1.4 needs 40, 1.4 32-bit needs 60. That is a little bit of difference?!
The observation that 1.4.3 32-bit crosses 1.2.1 this way also indicates that something got lost since 1.3.

Note the difference between 64-bit builds is pretty much nothing at the reasonable block sizes. Don't overinterpret this
Imgur album: https://imgur.com/a/JDAccOD


* Comparison with ffmpeg - which spends bonkers amounts of time at small blocks - at https://hydrogenaud.io/index.php/topic,125791.msg1044102.html#msg1044102

* Why these block sizes? I tried the minimum block size over in that thread, and since ffmpeg did so horrible, I set out to check (1) where it would start to behave normal, and (2) what is then ... normal? Reference implementation for comparison. And then it turned out, differences between versions ... and a new run.


Corpus: I took twenty-one of the CDs in my signature (7 in each broad subdivision), the first ten and a half minute of each, merged to a 219 minute WAVE file.
Timing was done overnight with hyperfine, warmup + 5 runs with 30 seconds cooldown in between (ffmpeg last), and times are median of 5.

If you haven't found it out yourself so far, it is found in the Misc-Tab under "Display" → "Columns UI" → "Layout", see screenshot:

Regards
Michelist

Thanks for the infos. GCC 14 looses most here with 16bit audio and disabled asm optimizations.
24bit files encode way to slow with disabled asm optimizations with all versions imho.

                Generic Build  |  No ASM Optimzations
GCC-12 1 thread:    1m25.343s  |  1m9.162s
GCC-13 1 thread:    1m24.958s  |  1m9.218s
GCC-14 1 thread:    1m25.622s  |  1m9.629s

GCC-12 8 threads:   0m17.890s  |  0m14.816s
GCC-13 8 threads:   0m18.637s  |  0m15.656s
GCC-14 8 threads:   0m18.854s  |  0m15.820s

GCC-12 16 threads:  0m16.536s  |  0m13.916s
GCC-13 16 threads:  0m17.404s  |  0m14.802s
GCC-14 16 threads:  0m17.598s  |  0m14.985s

GCC-12 1 thread:    6m14.467s
GCC-13 1 thread:    6m13.127s
GCC-14 1 thread:    6m12.464s

GCC-12 8 threads:   1m17.415s
GCC-13 8 threads:   1m17.558s
GCC-14 8 threads:   1m17.088s

GCC-12 16 threads:  1m16.173s
GCC-13 16 threads:  1m15.234s
GCC-14 16 threads:  1m14.989s

https://sqlitebrowser.org/

edit: I hope it goes without saying that fb2k should be closed before any edits are made. Also, I'd make backups just to be safe.