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-git Releases (Code Base v1.4.x) (Read 36803 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #50
Could you perhaps disclose some more details, if necessary via PM, so I can look into this when I have the time?

Compiler bugs are pretty rare, and I find it especially interesting as you say you've run into this previously.
Sorry, I'm not ignoring you!! ;) /Qipo is multifile procedural optimisation which has always been a bit 'flakey'. /Qip is single file procedural optimisation which generally works OK. However, Intel is retiring it's 'Classic' compilers later this year in favour of a 'Clang' base and this only supports /Qipo, and not /Qip. From personal recent testing, the GCC compiles are generally faster than both MSVC and Intel compiles and therefore, where it makes sense, I will probably favour GCC. I will retain the MSVC/Intel compiles where it makes my life easier ( ;) ), and probably for XP friendly compiles using VS2015/Intel 19.0.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #51
However, Intel is retiring it's 'Classic' compilers later this year in favour of a 'Clang' base and this only supports /Qipo, and not /Qip.
Very interesting! Fascinating that very, very large and powerful tech companies all seem to be moving towards Clang/LLVM. ARM, Apple, IBM, Intel, Microsoft, all using LLVM in some form or another in their compilers.
Music: sounds arranged such that they construct feelings.


Re: FLAC-git Releases (Code Base v1.4.x)

Reply #53
However, Intel is retiring it's 'Classic' compilers later this year in favour of a 'Clang' base and this only supports /Qipo, and not /Qip.
Very interesting! Fascinating that very, very large and powerful tech companies all seem to be moving towards Clang/LLVM. ARM, Apple, IBM, Intel, Microsoft, all using LLVM in some form or another in their compilers.
Equally interesting is that these companies, particularly MS and Intel, used to charge vast amounts for the use of their products even for single usage and now they are free for personal use!!


Re: FLAC-git Releases (Code Base v1.4.x)

Reply #55
FLAC-git-4d6d8b34-20230308
Built on Mar 08, 2023, GCC 12.2
(Code Base : 1.4.2)

x64-AVX2 optimised: https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-AVX2.zip

Generic x64: https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-x64.zip

Generic x86(win32-non XP): https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-x86.zip



Re: FLAC-git Releases (Code Base v1.4.x)

Reply #58
Experimenting with some Windows builds (first time).  Curious to see how they perform to other's builds.

flac git-9c83e6e4 20230311 - All built with static libs, GCC 12.2 (MinGW w64) on Debian GNU/Linux

flac-avx.zip and flac-noavx-v1.zip should probably (hopefully) perform on par with similar builds here.

flac-noavx-v2.zip and flac-noavx-v3.zip perform better than v1 on Linux, but seem painfully slower in my Windows VM.  Curious to see if they perform better on real hardware.


Times on Linux with my Ryzen 5850U.  Same options were used for the Windows builds.
Code: [Select]
flac -f -8p NIN_The_Fragile16.wav
NIN_The_Fragile16.wav: wrote 658391469 bytes, ratio=0.599

With AVX:  0m43.889s
No AVX v1:  1m12.704s
No AVX v2:  1m5.146s
No AVX v3:  0m59.930s


Re: FLAC-git Releases (Code Base v1.4.x)

Reply #59
What is the difference between these builds? And what is the reason to leave AVX out of some of these builds?
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #60
The only difference is a couple compiler flags.  The v1 non-AVX build is just a standard build for CPUs without AVX instructions.    v2 and v3 forces the encoder to use multiple threads (via -ftree-parallelize-loops).  Despite the extra threads, the benefit is small, and setting too many threads has a negative impact on performance.  That option doesn't benefit at all with AVX either.   Might be faster for some people without AVX, though it might not be worth the extra CPU power.  On Linux, using a few threads seems to have a small benefit, but hurts performance big-time on my VM.  Not sure if it's because it's a VM, or something Windows might do differently.

Just experimenting and curious to see if they perform any better for Windows on real hardware.  My only Windows machine might be considered an antique by now.  In the future I'll probably stick to Linux builds since I don't use Windows much.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #61
I only checked the AVX compile and it is very fast with CD material but also slow on 24bit material as it was configured with disable-asm-optimizations. Is it?
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #62
It is.  I should have noted that in my post. 

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #63
For a plain build with asm optimizations, there really is no need to disable AVX, FLAC has CPU feature detection. The only problem is when instructing the compiler to use AVX/AVX2/FMA/BMI/etc. for the whole program.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #64
I didn't disable AVX on the non-AVX builds.  I used -march=x86-64-v2.  The build with AVX uses x86-64-v3 (very similar to haswell).  If I use x86-64-v4, flac exits with illegal instruction since my CPU doesn't have any of the AVX512 instructions.