You are here

New Macs

For current or would-be users of Apple Mac computers, with answers to many FAQs.

Moderator: Moderators

Re: New Macs

Postby Agharta » Mon Nov 23, 2020 11:41 pm

desmond wrote:
Agharta wrote:Here's the shadow side:
https://www.forbes.com/sites/patrickmoo ... t-to-pass/

TL;DR; "I ran a bunch of non-optimised, non-Apple industry/PC applications on day one that haven't been updated yet and performance is not as good as Apple promises."

From the stuff I read - eg people compiling Webkit twice as fast as an £6K iMac Pro, *silently*, without the machine *getting warm*... using a fifth of the power... and I just think "Oh my god so much yes..!" :crazy: :clap: :thumbup:

The issue is more that some software that is very important to others isn't working at all.
My general sense is that Rosetta2 is doing a great job performance wise, but as expected there are some exceptions and teething problems.
It amazes me that some people have bought one for orchestration without checking if Kontakt will run.
It can't be authorised because Native Access won't work.

I'm not trying to put a damper on what is a tremendous release but trying to install some common sense.
Apple have a history of breaking compatability anyway, so with a new ISA, be cautious and more than ever do the due dillegence.
I fancy the new Mini, but I will give it 3 years to let the industry catch up. :)
I will leave the bleeding edge for those with plasma to spare.
Agharta
Jedi Poster
Posts: 4264
Joined: Sat Oct 30, 2004 12:00 am

Re: New Macs

Postby CS70 » Tue Nov 24, 2020 10:41 am

desmond wrote:
CS70 wrote:So long the OS of Apple stays similar, it's mostly a matter of recompiling. Since for decades now compilers have been far better than human programmers in optimizing, it's also unlikely that there's a lot of assembly in the codebases. Sure there can be a few traps if the codes not first quality, but for big, popular apps it's unlikely.

Yes, but not necessarily for very tight performance loops, when developers use all kinds of clever tricks and clever hand optimising to eek out as much performance as possible.

Now it is difficult to discuss this without referencing facts and literature and knowing how much you know specifically about this stuff over generalities, so it becomes easily a "who's got it longer" discussion, which is not the intention at all.

But briefly: while in theory what you say is true, and it certainly was once upon a time, in practice there's really no such thing anymore. Heck, I remember well the time when accessing a matrix in RAM by columns instead of rows made a difference (I had access to some 70s equipment back in the times), but these times are long gone. Optimizations are made by compilers, not human people, in practically any relevant case, and there's almost no practical exception.

To put it as a metaphor, it's like a car being faster than even the faster human runner. The car can do things that a human can't. There's always space for improvement, but you will improve over the last car, not the last human.

The rest is mythology, founded on something that was true long ago, when real programmers didn't use Pascal.

Of course, all within reason: algorithms have to be efficient in the first place (and you dont need no CPU to assess that), so if your way of doing something is fundamentally inefficient, no optimizer can do much about it.

if your audio loop utilises particular techniques that Intel chips have to eek out more performance,

There's no such thing. There's no "particular techniques that Intel chips have" (even assuming that the Intel chip microcode stays the same all the time, which it doesn't since it gets occasionally updated). At least, not techniques that a programmer can understand and an optimizer can't.. rather the opposite, in average.

Of course that may not stop a naive programmer from trying, but usually people who bother to learn that kind of stuff know better than that. Hopefully. :)

For example, the Sculpture synth in Logic is benchmarking with great performance on Apple Silicon versus intel - we're seeing the expected performance boost that the chip suggests. Alchemy, on the other hand, isn't seeing as good a performance boost to the lvel we'd expect based on the chip performance alone. It may be that Alchemy had very optimised loops under Intel, and it hasn't quite been optimised as well yet under ARM. Or it might have used tricks that aren't available on Arm. Or it might be they haven't quite got around to tuning it yet, and it'll get better.

If it's not been recompiled, it's not so much Alchemy that has the "optimized loops", but that it's using algorithms that - when originally compiled - resulted in an optimization not suitable to the changed underlying hardware.

For example, say that you have an algorithm which is the most efficient for a task, and requires moving 4 values, and that you have 4 registries: the optimizer will examine the combination space and come out with a sequence of registry allocations that suits your 4 registries hardware pretty well. Now you move it to an hardware platform that has only 2 registries and a virtualization layer. The VL will have to do many more swaps - taking more time for what originally was an atomic action. So it's slower and the overall result does not improve much even if the underlying hardware is a bit faster, because the machine is doing more work.

Another algorithm, that requires moving only 2 values, will be much faster on the faster hardware because even thru the virtualization it's still doing the same work.

Before recompilation, it's only natural that certain algorithms will adapt better and others worse.

But if you recompile the 4 values algorithm the optimizer will explore a very different combination space and produce a different list of actions which will be optimized for the new hardware.

Again, what really makes a huge difference is the OS and how it packages and presents its services. The rest is just a temporary inconvenience (so long software houses can be assed to maintain a product.. now that can be an issue).
User avatar
CS70
Jedi Poster
Posts: 7014
Joined: Mon Nov 26, 2012 1:00 am
Location: Oslo, Norway
Silver Spoon - Check out our latest video and the FB page

Re: New Macs

Postby desmond » Tue Nov 24, 2020 12:23 pm

CS70 wrote:
if your audio loop utilises particular techniques that Intel chips have to eek out more performance,

There's no such thing. There's no "particular techniques that Intel chips have" (even assuming that the Intel chip microcode stays the same all the time, which it doesn't since it gets occasionally updated). At least, not techniques that a programmer can understand and an optimizer can't.. rather the opposite, in average.

Again, I was speaking in layman's terms. You yourself mentioned one of the things I had in mind below - utilising various aspects of the chip platform to eek out more performance from the code. I'm not low level assembler guy, I haven't written assembler for 30 years, but for example it was possible on Intel chips because of it's pipeline to process 4 voices on a synth with the same CPU cost as one voice - this was a common optimisation that developers did, but you couldn't use that optimisation on other chip architectures that didn't offer the same features.

A compiler will optimise the technical stuff pretty well, but it can't problem solve for your unique application in the same way a smart person can. That's why audio plugins developers (particularly things like synths) still often have an "optimisation" phase in developer right at the end, and this is not simply flipping a couple of compiler flags and calling it a day.

CS70 wrote:If it's not been recompiled, it's not so much Alchemy that has the "optimized loops", but that it's using algorithms that - when originally compiled - resulted in an optimization not suitable to the changed underlying hardware.

Yes, Logic 10.6 is fully native for Apple Silicon, and Alchemy isn't showing the same performance improvements that you might expect given what we see elsewhere. As to *why*, this is indeed conjecture on my part, but again just to illustrate a point.

This stuff comes from online discussions over the years with plugin developers, some notable ones which do, in fact, obsess about performance, examine the machine code generated for their audio loops, and use their smarts to hand tune this stuff, either by using the knowledge of what the compiler will do to their code to optimise their code, or to replace it with assembler (which these days, as you say, is less likely due to the complexity of code and the fact that compilers generally do do a phenomenal job at this for the most part.)
User avatar
desmond
Jedi Poster
Posts: 10884
Joined: Tue Jan 10, 2006 1:00 am
mu:zines | music magazine archive | difficultAudio

Re: New Macs

Postby CS70 » Tue Nov 24, 2020 1:13 pm

desmond wrote:This stuff comes from online discussions over the years with plugin developers, some notable ones which do, in fact, obsess about performance, examine the machine code generated for their audio loops, and use their smarts to hand tune this stuff, either by using the knowledge of what the compiler will do to their code to optimise their code, or to replace it with assembler (which these days, as you say, is less likely due to the complexity of code and the fact that compilers generally do do a phenomenal job at this for the most part.)

Er, well, there's supposed "experts" in audio that obsess over the cables they use. :D People do what they do because of lots of reasons, many of which don't have much to do with fact. Plugin development is neither particularly hard not esoteric per se (the implementation, I mean.. the algorithm design can certainly be, even if in reality it doesn't seem to happen very often). Actually the most tedious part is to make the bloody GUI.

This thread (and forum) is not the right place for a lengthy discussion on the subject, but have a look at a look at https://llvm.org/ if you're interested. And experiment if you like. I use clang with Visual Studio, I have been looking at the compiled code for moderately complex algorithms, and I can bet a month's worth of beer that no programmer can do better, obsessed or not :)
User avatar
CS70
Jedi Poster
Posts: 7014
Joined: Mon Nov 26, 2012 1:00 am
Location: Oslo, Norway
Silver Spoon - Check out our latest video and the FB page

Re: New Macs

Postby desmond » Tue Nov 24, 2020 1:21 pm

CS70 wrote:Actually the most tedious part is to make the bloody GUI.

That's my favourite part! :lol:
User avatar
desmond
Jedi Poster
Posts: 10884
Joined: Tue Jan 10, 2006 1:00 am
mu:zines | music magazine archive | difficultAudio

Re: New Macs

Postby jjlonbass » Tue Nov 24, 2020 2:00 pm

Certain Intel processors do have features that ARM (and sometimes AMD) don't - these are AVX, AVX2 and AVX-512 SIMD instructions that effectively perform the same operation on multiple pieces of data in one instruction. ARM has broadly similar, but different enough features where AMD has most but not all of the Intel instructions.
I'd imagine that audio processing software, soft instruments etc. do make use of these features and have optimised loops that use them. I certainly found their fore-runners MMX and SSE very useful when I was involved in designing PC based video processing software a few years back.
Also, very few modern high performance microprocessors make much use of microcode for commonly encountered instructions - they simply wouldn't be fast enough if they did.

John
jjlonbass
Poster
Posts: 15
Joined: Wed Dec 19, 2018 4:52 pm

Re: New Macs

Postby Agharta » Tue Nov 24, 2020 2:30 pm

jjlonbass wrote:Certain Intel processors do have features that ARM (and sometimes AMD) don't - these are AVX, AVX2 and AVX-512 SIMD instructions that effectively perform the same operation on multiple pieces of data in one instruction. ARM has broadly similar, but different enough features where AMD has most but not all of the Intel instructions.
I'd imagine that audio processing software, soft instruments etc. do make use of these features and have optimised loops that use them. I certainly found their fore-runners MMX and SSE very useful when I was involved in designing PC based video processing software a few years back.
Also, very few modern high performance microprocessors make much use of microcode for commonly encountered instructions - they simply wouldn't be fast enough if they did.

John

Not much audio software requires AVX to function as there is usually a fall back to SSE etc.
NI's Massive X requires it which annoyed some people, those with roughly 10+ year old hardware.
Agharta
Jedi Poster
Posts: 4264
Joined: Sat Oct 30, 2004 12:00 am

Re: New Macs

Postby ConcertinaChap » Tue Nov 24, 2020 2:46 pm

BobTheDog wrote:The shadow side as written by someone that works for AMD!

In fairness, not since 2011.

CC
User avatar
ConcertinaChap
Jedi Poster
Posts: 9439
Joined: Wed Jul 20, 2005 12:00 am
Location: Bradford on Avon
Making music: Eagle Alley, recording music: Mr Punch's Studio
International Mercurial Man of Mystery.
 

Re: New Macs

Postby BobTheDog » Tue Nov 24, 2020 3:05 pm

Pretty sure the company he founded still has contracts with AMD though.
User avatar
BobTheDog
Frequent Poster
Posts: 1011
Joined: Fri Nov 19, 2004 1:00 am

Re: New Macs

Postby Agharta » Tue Nov 24, 2020 6:26 pm

BobTheDog wrote:Pretty sure the company he founded still has contracts with AMD though.

That's strong enough evidence for Trump's legal team. :shh:
Agharta
Jedi Poster
Posts: 4264
Joined: Sat Oct 30, 2004 12:00 am

Re: New Macs

Postby BobTheDog » Tue Nov 24, 2020 8:14 pm

He might have a point though, mine arrived and it hasn’t gone well!

I have not managed to run anything under Rosetta, the best I have managed is with the “native” version of Xcode downloaded from the App Store telling me I need to install Rosetta and then hanging.

Anything else I have tried will not run, helpfully the icon has a cross through it telling me I can’t run it!

I have a process called updatebrain that sits there using 100% of a core.

It is totally confused about my monitor thinking it is both a 5k and a 4K. Resolutions offered are either 4K or very low res.

Downloading Logic content was using 60% of total cpu including updatebrain, it does actually start up though so that is good.

First impressions have not been good.
User avatar
BobTheDog
Frequent Poster
Posts: 1011
Joined: Fri Nov 19, 2004 1:00 am

Re: New Macs

Postby desmond » Tue Nov 24, 2020 10:21 pm

I heard from someone else who had a Rosetta experience on the new Macs - when he ran some non-native app, the mac popped up saying "Would you like to install Rosetta to use this app?", and he either answered no, or dismissed the warning, figured he'd do it later, and then for the life of him he couldn't figure out how to access this again - the Mac just wouldn't run Intel apps, and it wouldn't prompt to install Rosetta etc.

He eventually figured it out that he had to reset something to bring the prompt back - the details escape me at the moment, but it's definitely possible but not obvious. I'm sure a google around would answer that one.

Did you update MacOS on first run? they shipped with an earlier version of BigSur for production reasons, so make sure you updated if you haven't already as this can fix some rough edges that didn't get fixed in time for production (I'm sure you probably have).
User avatar
desmond
Jedi Poster
Posts: 10884
Joined: Tue Jan 10, 2006 1:00 am
mu:zines | music magazine archive | difficultAudio

Re: New Macs

Postby BobTheDog » Tue Nov 24, 2020 10:53 pm

Thanks Desmond.

Rosetta is now working, I have no idea what changed. The pesky update brain process has also gone, I wonder if they are connected someway.

I have actually had an hour when things seem to be working much better, so my sulking has become less.

So I took the good old Logic Pro test from GS: https://www.gearslutz.com/board/apple-l ... ktest.html

with 44.1k and 128 buffer it managed 196 tracks, that is pretty impressive:

Image
User avatar
BobTheDog
Frequent Poster
Posts: 1011
Joined: Fri Nov 19, 2004 1:00 am

Re: New Macs

Postby desmond » Tue Nov 24, 2020 10:57 pm

To be honest, I could forgo the performance and *just* take the heat & fan improvements alone..! :clap: :thumbup:

Everything I hear about people's experiences with these things just make me really happy for my next machine...
User avatar
desmond
Jedi Poster
Posts: 10884
Joined: Tue Jan 10, 2006 1:00 am
mu:zines | music magazine archive | difficultAudio

Re: New Macs

Postby BobTheDog » Wed Nov 25, 2020 9:07 pm

Ok, day 2 update.

Basically a day of porting work using XCode and a bit of Ableton Live.

This is in comparison to a 2013 MacPro trash can with 32GB ram.

First the M1 mini just feels faster in general use, the MacPro usually is using a lot of file cache so even though the storage is twice as fast in the M1 I don’t think it is down to that so possibly the single core speed or just that it is newer, maybe if I reinstalled everything on the MacPro it would be similar.

Build speed in XCode seems much slower on the M1, maybe 1/2 or a 1/3 of the speed. This is fully CPU bound and the MacPro has very good hyper threading so pretty good 24 “core” performance, the M1 to me seems to have 4 very fast cores and 4 pretty useless cores but even so has pretty good performance.

Now to the real surprise, Ableton Live under Rosetta on the M1 from a very surface level so far runs like an absolute dream! Loads in 2.5 seconds, opens max patches instantly, very low cpu usage with a 32 buffer. I have never seen live run so well!

Tomorrow I need to connect up some Class Compliant USB audio reference kit so will test Live and Logic with multiple I/O channels enabled to see what effect that has...

p.s. I have not heard the fan come on yet!
User avatar
BobTheDog
Frequent Poster
Posts: 1011
Joined: Fri Nov 19, 2004 1:00 am

PreviousNext