Same list of cputype errors
On Wed, Jul 6, 2022 at 3:30 PM Martijn van Beurden wrote:
> Op wo 6 jul. 2022 om 21:21 schreef Scott Brown :
> > Configure for just arm64 gives neon optimizations, but "make" gives a
> bunch of cputype errors:
>
> What happens if you run 'make clean all' instead of
Op wo 6 jul. 2022 om 21:21 schreef Scott Brown :
> Configure for just arm64 gives neon optimizations, but "make" gives a bunch
> of cputype errors:
What happens if you run 'make clean all' instead of just 'make'?
___
flac-dev mailing list
Ok, so the latest being slower on both builds at level 8 than the Released
1.3.4 makes sense with recent compression improvements. Thanks. I was using
level 8 for all tests.
As for the Neon optimizations, it seems that if I configure for Universal
binary ( -arch arm64 -arch x86_64),the neon
Op wo 6 jul. 2022 om 20:45 schreef Scott Brown :
> Neon optimizations : .. no
It seems for some reason NEON is not enabled by configure. Can you
provide the config.log file so I can check what goes wrong?
> But this version is even *slower* than the released 1.3.4.
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 :
Op wo 6 jul. 2022 om 20:36 schreef Martijn van Beurden :
>
> I am aware that the following changes affect decoding speed
> - https://github.com/xiph/flac/commit/1bec35e33757fc38261b0acfa3c032e720d2baf0
> - https://github.com/xiph/flac/commit/63ac1c37bebbda5ca61ad5a05a1d8fba2883f629
>
Sorry, small
Olivier,
On a more general note, do you experience the decoding speed of libFLAC as
a bottleneck in your application? Decoding speed of FLAC is already
best-in-class among lossless audio codecs, so I actually wasn't expecting
anyone to object to a (small) decrease in decoding speed. There have
Op wo 6 jul. 2022 om 18:34 schreef Scott Brown :
> 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
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.
(I can't get the most recent code to compile, but that's a different story
I suppose)
Thanks,
Scott
On Tue, Jul 5, 2022 at 2:44 PM
