That depends on how one defines "powerful" - core-for-core they tend to be less powerful than Intel/AMD CPUs, but they're less complex, cheaper to manufacture, and use less energy. You may be able to get more horsepower through higher core count while consuming the same amount of energy for less money. There may be efficiencies gained through closer integration with video and other system hardware features right on the die.

As fascinating as all of this is to me (computer scientist by day!) - the success ro failure of any move for those of us who use the tech for music is going to come down to software support from our vendors. People love to trash Apple for their changing security restrictions on 3rd party software. They love to trash Apple for no longer supporting 32-bit applications. There's a long list of people trashing Apple for being bold enough to discontinue support for X, Y and Z.. The reality is that the software vendors are as much to blame for not keeping their products up to date with the machines people actually run as Apple is for doing what they said they told those vendors was coming years before.

Apple is NOT replacing Intel. They are looking to ARM chips for supplementary processing tasks.....

"Apple is developing a new ARM-based chip for its Mac lineup that would "take on more of the functionality" handled by Intel processors, reports Bloomberg. In development since last year, the chip, codenamed T310, is said to be similar to the chip used to power the Touch Bar in the Macbook Pro."

Considering plugins are self-contained audio processing engines, horizontal scaling (more cores) all makes perfect sense until you realise the end-product of a mixdown in a DAW is a single stream of zeroes and ones, ie it’s got to end up on one core at some point in the right order against the clock before you run out of buffer – the same applies upstream to group busses and the like, so if you’re in real time any single track plus plugins has to fit inside a single core to have a reasonable chance of keeping up with the output stream – this is why fewer numbers of very powerful cores for DAWs works well; Task switching to merge data streams on the same core (or physical CPU) induces much less latency then having to cross invalidate caches and write through to L3 cache, or worse, memory to enable another core to fetch the data you’ve just crunched (If the core is on a different physical CPU). Just adding more L2 cache seems like the right answer – until you realise how many cycles you’re spending on maintaining cache coherency for related processes. Huge L1 caches sound like a great idea until you spend more time flushing them than reading them because a process on another physical core wants the data you’ve just processed – that’s a snippet of the issues you face at a CPU architecture level dealing with real-time processing.

With offline processing, yes, ever increasing numbers of cores will crunch chunks of work in parallel and theoretically get more workload done per second. Massive multithreading is not an easy undertaking with real-time audio processing – there are always huge compromises and lots of cores spinning waiting for other cores to finish with data before stitching everything together. In other words processing efficiency drops off enormously the more you scale horizontally. Obviously these issues have been ground-out over years on the AMD64 platforms – how many dead ends will Apple’s ARM architecture take before it’s as capable? That’s assuming Apple are interested enough in this very niche area to optimize it accordingly. As I’ve said elsewhere, most high-end PC/workstation workloads are not real-time so extra cores over pure horsepower will often prove beneficial - that isn't necessarily the case for music production.

For now - how long will Apple want to maintain two CPU architectures in one hardware product and OS?

I'm not totally disagreeing with you because your technical analysis isn't wrong - but think of querying or analyzing a large database. It's a similar task, where a huge set of data is split up, processed, and recombined at the output. At some point in the size of that set, it's more efficient to split it up over multiple networked machines running multiple cores and combine the results at the end. There are also differences in how caches are designed and accessed - AMD Epyc CPUs outperform AMD Threadrippers in large part because of how the cache is organized. And, lots of people DO run those kinds of workloads on ARM processors today.

My point wasn't to try to prove that ARM is be better for audio production. My point was to say that for most people, it will be sufficient, and most likely cheaper. For many of those people, it'll be a step up from the two or three year old machine it replaces. For those of you who fit in the small minority of people where this isn't true, there'll be iMac pros and Mac Pros for you folks (or Windows or Linux if that's your jam).

I find the whole Mac ARM discussion really interesting. The logic for Apple to make this change doesn’t make a lot of sense. The Mac is a platform that is slowing down in terms of sales. It is becoming more and more niche. IPadOS is where we are all heading. A MacBook based around iPadOS will have the software already there and will be more profitable than the MacBook line. No amount of emulation wizardry is going to make up for how slow any existing x86 apps will be on this thing. So we are left waiting for rebuilds of existing software and that will take for ever leaving the whole arm project dead.

I just cant see the point. MS found that out with RT and subsequent windows arm projects. Really only laptops can benefit from the power benefits anyway. Serious users are often plugged into a wall so what is the benefit?Lose out on decades of code and software so you can save a bit of battery? Doesn’t make much sense.

Single core speed is essential for daw work, their are limits as to what can be farmed out in parallel processing. We are not going to have a daw based on a mesh of 100 raspberry pis. I suspect that to create a chip that is as powerful as high end intels requires a multi-billion dollar investment--apple would need to decide if it wants to pony up the bucks to play in that space. There are tons of not powerful cpus in the marketplace, so those are not a big deal to create or use.

But if one is committed to paying apple prices for apple gear, what is under the hood is a matter of curiosity only. I am sure if apple puts something out, it can be trusted to work as it should. Whether there is or isn't a move to arm, I can't see how the consumer need have any concerns.

It’s not the same. A large paralleled SQL query isn’t trying to keep up with real time. Waiting an extra second or so for the parallel processes to complete your result set isn’t going to cause an issue – the requester will wait patiently (within reason) until it’s finished whether that’s 5 tenths or 5 seconds. Large queries tend to be restricted by I/O throughput therefore database queries benefit from as many threads as possible, Database queries can usually be broken up into distinct pieces of standalone work. The more you scale horizontally with DAW workloads the more opportunity you’re introducing for latency, or real-time peaks due to competition for the same resource. DAWs are dependant on pure number crunching – of intertwined and heavily-related streams of processing. The expected outcome is real-time - you expect to write the completed databuffers out at point x – if they are not ready – disaster! Dropped or incomplete buffers will be the result depending on the software – the dreaded pops and clicks. That’s NOT how a parallel database query would be processed. This is why fewer but faster cores still cut the mustard in the DAW world. To trash a well-known phrase:- a DAW output buffer waits for no process!

I'm not going to get into a pissing match over who's got a better handle on CPU architecture. There are plenty of RTP scenarios that utilize highly parallelized architectures. I've already conceded that, in a vacuum, for certain tasks, all other things being equal, a smaller number of higher-powered cores will be better, within certain limits. Take yes for an answer

It's not a pissing match - CPU architecture is why AMD sucked as a real time audio platform for years. The success of RTP applications hinges on how interdependant data streams are. All I'm saying is more cores are not a magic bullet in our specialist real-time applications. I also specialise in CPU hardware and have done so for over 30 years (not PC it must be said) I designed and developed a real-time system (target tracking and merging of RADAR data sources) that had similar real-time latency issues that could only be overcome by redesigning the CPU, bus and cache architecture - which I respecified (successfully.) DAWs are far more extreme examples of interdependancy of data processing streams!

I suspect Apple don't give a stuff about DAW users anyway, they have bigger fish to fry. Which is why I'm concerned about the looming architecture change and its influence on the platform for DAW use - which is indeed a tiny use-case vacuum - but it's our little vacuum that's significant to us. I wouldn't be surprised if developers code their way out of this issue in the long run as more (extreme numbers of) slower cores becomes the norm - perhaps with constant background rendering of tracks as you make changes - so you're never really playing a whole session live. With my analyst/developer hat on - that's how I'd approach it anyway!

If you take a look at the HEDT processor benchmarks lately, the scaling is really fuzzy at the top. I'd love to attempt a 3970x system for audio, but have no idea what the results would be. Some benchmarks show 16 cores sitting there unused..

Consumer cpu's stay at the top of the benchmarks for many applications, obviously because they rule the single-threaded arena, but companies like Adobe are pretty lazy when it comes to splitting render threads.

In a DAW, the splitting up of realtime audio-per-channel strip is pretty well laid out to handle multicore processing. Yet... soon as I hit Export All Tracks or Freeze in Logic, it routes ALL processing to one core, what played back fine in realtime now renders at 1/16 the speed. That's just bad code.

This is oversimplifying, but having a 64-128 core setup, and with threads going to each mixer channel, would allow a really spread out resource setup. Whether ARM architecture can provide that, or Apple will ever lay the infrastructure in their OS for it (Grand Central Station etc..) is to be seen..

Agreed - and more or less you've more eloquently made the point I was trying to all along . A lot of times physical architecture changes are painful because the approach used in existing software no longer matches the reality of the computing hardware.

Why are we having this conversation again?....:

Apple are almost certainly going to develop an ARM Mac. It's inevitable. Intel's continued failure to meaningfully advance their architecture over the last few years combined with Apple's insane performance demonstrated by their ARM chips would make it an obvious choice.

That said, should you continue to use a Mac? In my honest opinion, if you're using Cubase anyway, probably not. I recently switched to PC despite being, quite frankly, a bit scared to do it, but I have to say the performance I'm getting on my new AMD rig with Cubase is insane. My only regret is I didn't consider it before spending a stupid amount of money on various Macs.

Apple are almost certainly going to develop an ARM Mac. It's inevitable. Intel's continued failure to meaningfully advance their architecture over the last few years combined with Apple's insane performance demonstrated by their ARM chips would make it an obvious choice.

That said, should you continue to use a Mac? In my honest opinion, if you're using Cubase anyway, probably not. I recently switched to PC despite being, quite frankly, a bit scared to do it, but I have to say the performance I'm getting on my new AMD rig with Cubase is insane. My only regret is I didn't consider it before spending a stupid amount of money on various Macs.

How about you just leave this thread if you dont like it? That would be totally cool with me...

if someone asks you if you think it will be a big risc. tell them no, it will be a small arm.

What kind of performance are you getting? Do you mind sharing a bit about your build? I'm really curious to hear about an AMD rig for audio...

The problem isn't the code - it's the compilers. You're not writing code you're writing something that gets turned (eventually) into machine code. Trying to keep lots of cores happy with interrelated processes two steps removed from the code that’s actually going to execute is actually very, very difficult indeed. Sony thought they could crack it - look at the PS/3, they thought they’d chuck in 10? FPU engines (bespoke version of IBM's PowerPC based cell CPU) and do all general purpose processing and graphics rendering in parallel, smashing the performance of other platforms for a third or less of the hardware cost. The impressive performance IBM were squeezing out of their cell architecture was because they were executing genuinely parallel processes.

It turned out games are very much like DAW processing – lots of interrelated tasks which cause race and latching issues in typical game software, so it’s easiest to code round a large single thread as it always has been. Sony saved the PS/3 by admitting defeat in time after spending over $100 million trying to write a game-friendly compiler with some of the finest minds in the world and chucked a graphics card in at the last minute to get the machine out the door! What was (on paper) a game-changer, was simply too complicated for “dumb old” (far cleverer than me) humans to get their head round! This stuff always sounds easy. Doing it is another thing. If we ever crack quantum computing it’ll be machine AI that codes it through trial and error – then be scared!

Perhaps as it now stands.. BUT... the bigger fish that Apple wants to fry in the future might have similar real-time demands in processing.

With the noise Apple makes about its plans in Augmented Reality... future DAW performance might just naturally come along for the ride?

That's a great example with the PS3. With ARM being a newer chip design in recent years, would the compiler be more 'up to date' kind of like the newer software languages?

Would be interesting to see how apps are utilizing multiple threads on the iPad Pros.

That's going to be (likely) a different challenge. Not all cores on the iOS devices' processors are the same. There are cores for tasks that demand performance and cores for tasks that "keep the lights on" while other tasks are running of the device is asleep. On iOS it's more of a challenge to optimize battery life, because optimized battery life equals smaller, lighter, hopefully less expensive phones that customers don't complain about having to plug in all the time.

Then we've got this guy:

https://venturebeat.com/2020/03/03/a...ver-processor/

...which is a completely different approach. That prioritizes density and always-working power consumption so that a building full of servers consuming X amount of electricity running Ampere CPUs will in total get more work done than the same building full of Intel servers consuming X amount of electricity.

People hear ARM and immediately think of the chips in their phone, or Windows RT. ARM is just a core design, it's really on the individual vendor to flesh out what that system actually looks like. I don't think it's a foregone conclusion that an ARM CPU will be slower than an Intel CPU.

https://www.theverge.com/2020/6/9/21...wer-efficiency

This is going to be a nightmare software wise.. plugins.. etc.. not working on Arm.. once again we will lose so many gems that won't be ported to Arm

I've been ringing the "ARM is coming and it ain't good for plugins" bell for some time and was told I was crazy.

There's a list as long as our arm where devs took 6+ months for Catalina compatibility. ARM will be more painful.

Imagine a world where all plugins must come through the App Store. Continued narrowing of OS lockdowns, more EFI/T2 witchcraft... what happens to small devs like Chris from Airwindows, Michael Norris?

What happens to the vibrant Ableton Live indie scene for Max/M4L? Open Source?

I hope I'm wrong (and crazy). We need Apple to succeed. I want ARM to succeed. I just don't want the boatload of sh#› that I think will follow in its wake.

Anyone remember Rhapsody and the red box/blue box/yellow box stuff back in the early days of OS X? It's too early freak, we can only make assumptions. We'll know more June 22.

Hopeful yet realistic. Glad I'm writing this from my new 16"MBP.

Not a Cubase user so I don't understand the implications here... are Steinberg always lagging on the macOS-side? Have they made any official statements they wouldn't support ARM?

They already have Cubasis. What would stop them from developing Cubase 11 for macOS ARM?

I was not serious in my post... rather I was poking at what I considered the absurdity of the initial post in this thread:
"What do you guys think about apples move to arm chips? As a Cubase user.... does it even make sense to buy apple at this point?"

Ok, that's what I had hoped.

Thanks god i did not listen to the uninformed smartasses who replied to this....

I replied to you.
How am I an "uninformed smartass"?

But in the sake of this thread: What did you do?

And now that the cat's out of the bag, what will you do?