I got the latest from git and compiled it. the output from config looks like this:
Configuration summary : FLAC version : ............................ 1.3.4 Host CPU : ................................ aarch64 Host Vendor : ............................. apple Host OS : ................................. darwin21.5.0 Version string : reference libFLAC git-7e0a0e57 20220701 Compiler is GCC : ......................... no Compiler is Clang : ....................... yes SSE optimizations : ....................... yes Neon optimizations : ...................... no Asm optimizations : ....................... yes Ogg/FLAC support : ........................ no Stack protector : ........................ no Fuzzing support (Clang only) : ............ no note: Asm optimizations are ON with this vs the release version from feb But this version is even *slower* than the released 1.3.4. Running the native arm build from the latest code took 3:54 (3 minutes, 54 seconds) (3:10 on the released 1.3.4 code). Compiling for intel from the latest code, the intel build through emulation took 3:02 (1:50 on the released 1.3.4 intel build) Again, I'm on an M1 Max MacBook Pro So it looks like the latest code is slower all around compared to the February released version of 1.3.4. Are there some compilation flags I should be setting that I may be missing? My fastest encode is still the released 1.3.4 intel version through emulation. Note, configure shows that Asm optimizations are NOT on for the feb release version: Configuration summary : FLAC version : ............................ 1.3.4 Host CPU : ................................ arm Host Vendor : ............................. apple Host OS : ................................. darwin21.5.0 Compiler is GCC : ......................... no Compiler is Clang : ....................... yes SSE optimizations : ....................... yes Asm optimizations : ....................... no Ogg/FLAC support : ........................ no Stack protector : ........................ no Fuzzing support (Clang only) : ............ no On Wed, Jul 6, 2022 at 1:17 PM Martijn van Beurden <mva...@gmail.com> wrote: > Op wo 6 jul. 2022 om 18:34 schreef Scott Brown <scottcbr...@gmail.com>: > >> Martijn filled me in that recent changes (since the official 1.3.4 >> source) have added ARM improvements, and that if I get the most recent >> code, I should be good. >> > > Huh, I have no clue why my mailing program decided replies to this > shouldn't go through the mailing list, but it did and I didn't notice. > > Anyway, Apple's x86-64 to arm64 translation uses FLACs routines with SSE > intrinsics and is able to translate them into corresponding NEON code. When > compiling FLAC from source, the compiler isn't able to create these NEON > routines, at least not with the same efficiency as the NEON translated from > SSE. Since FLAC 1.3.4, NEON intrinsics powered routines have been added to > FLAC. > > Kind regards, > > Martijn van Beurden > > (I can't get the most recent code to compile, but that's a different story >> I suppose) >> > > If you suspect that compilation doesn't succeed because of some issue with > the FLAC code, please let me know. >
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev