Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC v1.4.x Performance Tests (Read 109693 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: FLAC v1.4.x Performance Tests

Reply #525 –
Quote from: Porcus on
Suggestion, if you don't mind running another round for the sake of the sport: Measure speed and size on the same corpus, for each of these runs on the "inexact" build, and post it here? 
flac -8per7 -A "subdivide_tukey(4);flattop"
flac -8er7 --lax -l15 -A "subdivide_tukey(4);flattop"
flac -8pr7 --lax -l15 -A "subdivide_tukey(4);flattop"
flac -8pr7 -A "subdivide_tukey(5);flattop"
I took "track 2" from each of my 38 and ran those 2x4 multiple times overnight, and -8pr7.
Sizes total to around 1 GB compressed. 
Table in size order first:
WAVE1950649336secondskiB saved over previous
Inexact, no "-p"/"-e"103251626768
Exact, no "-p"/"-e"1032260218141250
Inexact -p1031759702213489
Inexact -p "A5+"1031432685664319
Exact -p103140691760025
Inexact -pe "A4+"10312567363809147
Exact -p "A5+"10310021202023249
Exact -pe "A4+"103080333514817194
Inexact -el15 "A4+"103073984296162
Exact -el15 "A4+"10303449162391386
Inexact -pl15 "A4+"10301515831431189
Exact -pl15 "A4+"10297523222235390
Everything is run with -8r7 -j4 --no-padding in addition to the above, where "A4+" means -A "subdivide_tukey(4);flattop" and "A5+" bumps the 4 up to 5.
Times indicated are "Process time" (so clock times are about 1/4 of this) and a fishy matter on this throttling CPU, but I tried to run it hot first, and then they are median of four (because then it was morning and i got up).

Numbers indicate, starting out from the top:
* exact-rice appears to be "-p-alike" in cost/gains.
* exact-rice atop -p is much better than -pe, but we already knew that -pe is hopeless value for money, and I should likely have used less windowing functions on that one to keep numbers sane.
Anyway, you could argue then that an exact-rice option is better.
* For -l15, I am surprised over the -p vs -e timings, but it might be due to the order of runs and CPU throttling. Anyway it is not that far from consistent with what is going on with -l12 as found in standard -8.

Breaking it down on genres, classical music benefit much more. Like, twice as much as the rest. Two  files consistently benefit above 0.1 percent: Bruckner (that's vocal music) and Cage (percussion). Also Jordan Rudess (solo electric keyboard) benefit that much except for one run (-el15)

Re: FLAC v1.4.x Performance Tests

Reply #526 –
Or viewed with different glasses. Here I did not do any timing nor anything slower than -8pe.
But split into genre divisions:
total - classical - heavier - "other"

settingtotalclassicalheavierother|pct-pointswithbaseline:inexact -8
inex -753.0 %40.7 %70.7 %58.3 %|-.032 pts-.013 pts-.029 pts-.065 pts
ex -7.008 pts.012 pts.005 pts.007 pts|-.024 pts-.001 pts-.024 pts-.058 pts
inex -8.024 pts.001 pts.024 pts.058 pts|0 0 0 0
inex -8e.013 pts.018 pts.011 pts.011 pts|.013 pts.018 pts.011 pts.011 pts
ex -8.001 pts-.010 pts-.006 pts.024 pts|.015 pts.008 pts.005 pts.035 pts
ex -8e.017 pts.022 pts.014 pts.015 pts|.031 pts.030 pts.019 pts.049 pts
inex -8p.008 pts.003 pts.024 pts-.001 pts|.039 pts.033 pts.043 pts.048 pts
inex -8pe.016 pts.009 pts.006 pts.038 pts|.055 pts.042 pts.048 pts.086 pts
ex -8p.002 pts.013 pts.011 pts-.021 pts|.057 pts.055 pts.059 pts.065 pts
ex -8pe.019 pts.013 pts.008 pts.041 pts|.076 pts.067 pts.068 pts.106 pts
* Sorted by "total" size.
* Leftmost column: First compression ratio (lower is better) and then: how much, in percentage points, the setting gains on the one immediately over it. You see that exact -8 beats inexact -8e by 0.01 percentage points, but that is only due to the "other" (and I guess, Jordan Rudess ...) And that exact -8p narrowly beats inexact -8pe despite something going on in the other section.
* The rightmost panel are just cumulative percentage-points relative to inexact "-8", which is a natural "slowest reasonable" benchmark.

Seems that going "exact" is, ballpark:
* half as efficient as going "-7" to "-8".
* half as efficient as -p, when the baseline is -8 and not heavier.

Re: FLAC v1.4.x Performance Tests

Reply #527 –
Quote from: Porcus on

flac -8per7 -A "subdivide_tukey(4);flattop"
flac -8er7 --lax -l15 -A "subdivide_tukey(4);flattop"
flac -8pr7 --lax -l15 -A "subdivide_tukey(4);flattop"
flac -8pr7 -A "subdivide_tukey(5);flattop"


It took almost two days..
ParamsAVG sizeAVG ratioAVG speed
-8 -per7 -A "subdivide_tukey(4);flattop" -j2826 168 05569,304%88,983x
-8 -er7 --lax -l15 -A "subdivide_tukey(4);flattop" -j2826 153 38669,265%306,023x
-8 -pr7 --lax -l15 -A "subdivide_tukey(4);flattop" -j2826 140 68869,231%212,109x
-8 -pr7 -A "subdivide_tukey(5);flattop" -j2826 170 40269,310%453,227x
Also i have found same sizes for different parameters:
Spoiler (click to show/hide)
 

Re: FLAC v1.4.x Performance Tests

Reply #528 –
Yeah it takes time - and this is all with the inexact-rice, right? Using exact-rice would take even more - if you have the patience to do that for comparison? You could of course skip the one with "-pe".
(What you see now is that -p with the extra windowing function so nearly catches -pe.)

The observation that some files have identical sizes, is not so strange, but I am a bit surprised which ones.
Not surprising: 34276. One of these allow for prediction order up to 15 instead of merely 12, but it turns out it doesn't find that 13/14/15 improves compression.
More surprising: All those where -e gives the same as a -p with extra windowing. The latter allows more attempts, while the former brute-forces the fewer - so it will then be that the it picks the right one by a cruder method (so that brute-forcing doesn't help) and that the extra windows are not "the right one".

Note, the only ones that have - potentially - extra layers of complexity in the file (for decoding), are the -l15. The others don't work by "packing heavier with more complexity" - they work by
* making more attempts, each at similar complexity, and then cherrypicking the best,
and/or:
* spending more time fine-calculating which one is actually the best.
The "exact-rice" build does even more of that.