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.5.x Performance Tests (Read 7627 times) previous topic - next topic - Topic derived from FLAC v1.4.x Performan...
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.5.x Performance Tests

Reply #25
If I read it right, @C.R.Helmrich observed that new 1.5.0 produces identical encoded bitstream, not different. Except when using -M.

Anyway that is consistent with the changelog.

Re: FLAC v1.5.x Performance Tests

Reply #26
Yes, and I am saying that there might be inputs where outputs aren't the same. Just because a few are, doesn't mean all are.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.5.x Performance Tests

Reply #27
Thanks for the clarification. I meant differences between 1.5.0 (single-threaded, no -M) and the previous release when using the same compiler on the same platform.

Chris
If I don't reply to your reply, it means I agree with you.

Re: FLAC v1.5.x Performance Tests

Reply #28
The primary purpose of this test was to confront the performance of the GCC and Clang builds from the thread related to the "Release" version of Flac v.1.5.0 under the specific conditions of the legacy Intel Optane mobile platform. I later added Case's custom generic GCC build (64bit). I probably don't need to mention that the results are not transferable and cannot be generalized, at the same time they have no extra meaningful value by themselves! There are undoubtedly CPUs where support for fast math or specific instructions will show up in a significant way.
An effort was made to keep the Variance value below 0.4, at the same time it should be added that there were done more than 20 attempts. The Flac encoder was run directly via the command line, not via the fb2k Converter.

Converted audio file: Alyn Cosker - Lyn's One (wav), 1:18h, 24/96
It can be stated that under the given conditions:
- the use of AVX2 did not show a performance shift compared to the generic version
- GCC and Clang are almost identical in terms of performance impact
- MT support has the greatest impact on performance

Once again, kudos to KTF/contributors for working on the Flac 1.5.x version
For the individual compilations, a big thanks to forum members Wombat, John33(RW), NetRanger and Case for their builds!

X

Re: FLAC v1.5.x Performance Tests

Reply #29
Can 1.5.0 really do 128 threads?
On an 8-thread CPU, it throws a warning at -j 65, but not at -j 64. Also -j 64 goes faster, indicating that it does indeed multithread.


Re: FLAC v1.5.x Performance Tests

Reply #31
The primary purpose of this test was to confront the performance of the GCC and Clang builds from the thread related to the "Release" version of Flac v.1.5.0 under the specific conditions of the legacy Intel Optane mobile platform...
For such CPUs i had the idea builds with AVX2 falign-functions=16 that i added to the bundle help a little bit.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC v1.5.x Performance Tests

Reply #32
The primary purpose of this test was to confront the performance of the GCC and Clang builds from the thread related to the "Release" version of Flac v.1.5.0 under the specific conditions of the legacy Intel Optane mobile platform...
For such CPUs i had the idea builds with AVX2 falign-functions=16 that i added to the bundle help a little bit.
Thanks for the reminder.. i thought the build with different compiler settings (falign-functions=16) is relevant and intended for use with even older versions of Core than the one I have (Kaby Lake - Refresh). Never mind, for interest I can test this build as well.

 

Re: FLAC v1.5.x Performance Tests

Reply #33
I don't think it has much to do with old or new. It seems to relate to cache behaviour that may be different with some types of CPU. Mostly older or mobile types. My j5005 intel for example does really not speed up anything up no matter what i compile.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!