flac dev - Jul 2022 - slow on apple silicon?

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 brianw <brianw at audiobanshee.com> wrote:
> You raise excellent questions. I have not been paying attention to
Apple's
> compiler support for the M1, M1 Pro, and M1 Max.
>
> Do you have the latest compiler from Apple?
>
> Are you sure that -O3 is the best option? I seem to recall that the
'best'
> has changed over the years.
>
> I also recall that Apple support for SSE was slow to be delivered, at a
> time when AltiVec support was highly performant. Could it be possible that
> Apple's compiler doesn't support the M1 Max vector instructions as
well as
> it support SSE? My experience may not be related to the compiler, though,
> because I was using the vecLib framework, part of the Accelerate framework.
> Initially, Apple provided routines for Intel that were functionally
> correct, but not optimized. Later, those routines were optimized, and
> programs linked against the framework automatically inherited the
> improvements. flac does not use these frameworks, so my example may not be
> relevant.
>
> For comparison, how long does your test set take when going through
> emulation?
>
> Brian
>
>
> On Jul 5, 2022, at 9:48 AM, Scott Brown wrote:
> >
> > Hi everyone,
> >
> > I've got a question regarding Apple Silicon chips and flac
encoding. I'm
> not seeing the speed I think I should be seeing
> >
> > I compiled a universal flac 1.3.4 for Apple Silicon and 64 bit intel
> like so:
> >
> > ./configure -enable-static -disable-shared CFLAGS=" -arch arm64
-arch
> x86_64 -isysroot
>
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
> -mmacosx-version-min=10.9 -O3" ; make
> >
> > Encoding 24/96 wav files to flac level 8 for a fileset i've been
testing
> takes about 3 minutes and 10 seconds on an M1 Max processor using the
> native arm build.
> >
> > Using the intel build on the M1 Max (which goes through Apple's
Rosetta
> emulation) takes 1 minute and 50 seconds.
> >
> > I would expect the native Arm build to be much faster since it's
not
> going through emulation. What am I missing? Some compilation flag?
> >
> > Thanks,
> > Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20220706/ed5da23d/attachment.htm>

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/fb877018/attachment.htm>