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 <mvanb1 at gmail.com>
wrote:
> Op wo 6 jul. 2022 om 18:34 schreef Scott Brown <scottcbrown at
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20220706/0356667e/attachment-0001.htm>