New "Mac Studio" from Apple

[mattrixx]

Originally Posted by kings79

Exactly.

The Mac Pro 5,1's with the X5690's in them; are slightly more powerful than the trashcan and the computer in question is more powerful than the million dollar 28 core Mac Pro 7,1's (single core for the Max and both single and multi for the ultra). SO we are universes above power if coming from a Trashcan or Cheesegrater.

Currently PT isn't running native so at this point any 'noticable' difference is a huge bonus.

Have to say, going from Trashcan to Ultra is mind boggling.. . Absolutely incredible to be honest.
Definitely been the biggest leap I've experienced in my 30+ years of Macintosh

[Michael Carnes]

I've got a little more data for those inclined to be nerds (that's probably close to universal). You might need some basic knowledge of computer architecture for it to mean much.

I wrote a program to help me do some musical research. It's a command-line utility, written as a multi-threaded app (it uses 25 threads). It uses all of the cores on a machine (verified using Activity Monitor). Without taking you too far into the weeds, it uses a small data set, but performs several billion evaluations of that dataset. I built it native for both Intel and M1.

Because the program is small and the dataset is too, this means that just about everything will live in the cache memory of an x86. What this means is that the x86 program can run in an environment that isn't much different than the unified memory of an M1 processor. So comparisons between this running on either computer gives you a pretty direct comparison of core performance between the two.

From the 10,000' view, my Intel Mac outperforms the M1. That's because my Intel has 16 cores and my M1 Max has 10 (I treated the efficiency cores and the performance cores the same way). If I dig just a little deeper, I can work out that the per-core performance of the M1 is a little better. I don't have the numbers in front of me, but I remember the M1 cores were about 10 percent faster.
.............

What this underscores is how important the unified memory architecture is. Cache memory on an x86 is small, compared to main memory (which is much slower). There's extensive logic on the x86 dedicated to managing the cache. Depending on how a program/plugin is coded, parts may briefly live in the cache and parts may not. Audio/video flowing into a program are often touched only once. All of these programs/data in main memory are quite a bit slower because they get very little benefit from the cache. The system memory on an M1 is basically ALL cache memory, so it simply takes much less time to get data from where it is to where it needs to be. As people are discovering, this makes an M1 much faster in real-world operations.
...........

There's been some discussion about performance of RISC vs CISC operation (RISC is the simpler instruction set). At least in my little test, focused only on the core, RISC compares very well to CISC.

[685]

Originally Posted by Eric Lambert

Notice a difference how? It shouldn't take double the CPU just to "notice" a difference. And you might take a look at Geekbench results for the machines in question. Double doesn't even come close to describing the trashcan vs. the Studio in comprehensive comparisons.

Not sure what you're getting at but personally, I wanted to get to a point where I could set the buffer to 32 and never have to change it. Overall, I noticed a big difference in what I can do with Protools and Logic especially opening previous mix sessions with the buffer set to 32. I could not do the same things on my 12core cheesegrater. I tested them(back and forth) for a few days and it was not even close. The Geekbench scores were 6000 vs 12200. I even created new test sessions at both 48k and 96k to try out. I was able to load way more plugins and and still record on new tracks without any errors. In fact, I loaded a friend's session that was recorded/mixed on his trashcan and he was surprised that I could run it with the buffer at 32. On that same mix session I dubbed the 60 or so tracks, hit record, and Protools recorded on those tracks until I hit stop. I ran similar tests when I was looking at buying a trashcan years ago and I did notice a little more power in the trashcan but it wasn't huge so I passed on it. I would have also needed to buy an expansion chassis to go with the trashcan. So I didn't want to spend a lot of money for a small amount of improvement. I did looked at upgrading the cheesegrater from the 2.93ghz CPUs to the 3.46ghz CPUs but never did.

Originally Posted by thebeatless

I wouldn’t say issues, like I’ve said repeatedly, it’s just not as good as I had hoped, and hopefully it will improve with updates. That hasn’t changed now that it is supported.

Is pro tools working better for you using a different playback engine/a third party interface? Previously I had much fewer cpu spikes using hd native instead of a thunderbolt lynx aurora n, but maybe that changed? I sold the aurora a few months ago because of this. I’ll test with built in audio today to see if I notice a difference. I actually just replied to someone asking about using aurora via thunderbolt mentioning that I’d get garbled audio frequently after CPU spikes. That never happens with hd native. But…. I do get that on my B rig (now my “old” iMac) using a UAD arrow. Changing the buffer and changing it back normally fixes it.

Got you! lol

Mannnnn if I open Protools 10 times from a fresh boot it will open without CPU spikes about 3 of those times running HD Native/HD Omni. Things run well until I close Protools or restart the computer. Weird deal
I do agree with you on Protools running better with the HD Native card. This is going back but I remember having less stop errors when I switched over years ago. I guess its still the same now but time will tell.

[Marsdy]

Originally Posted by Michael Carnes

I've got a little more data for those inclined to be nerds (that's probably close to universal). You might need some basic knowledge of computer architecture for it to mean much.

I wrote a program to help me do some musical research. It's a command-line utility, written as a multi-threaded app (it uses 25 threads). It uses all of the cores on a machine (verified using Activity Monitor). Without taking you too far into the weeds, it uses a small data set, but performs several billion evaluations of that dataset. I built it native for both Intel and M1.

Because the program is small and the dataset is too, this means that just about everything will live in the cache memory of an x86. What this means is that the x86 program can run in an environment that isn't much different than the unified memory of an M1 processor. So comparisons between this running on either computer gives you a pretty direct comparison of core performance between the two.

From the 10,000' view, my Intel Mac outperforms the M1. That's because my Intel has 16 cores and my M1 Max has 10 (I treated the efficiency cores and the performance cores the same way). If I dig just a little deeper, I can work out that the per-core performance of the M1 is a little better. I don't have the numbers in front of me, but I remember the M1 cores were about 10 percent faster.
.............

What this underscores is how important the unified memory architecture is. Cache memory on an x86 is small, compared to main memory (which is much slower). There's extensive logic on the x86 dedicated to managing the cache. Depending on how a program/plugin is coded, parts may briefly live in the cache and parts may not. Audio/video flowing into a program are often touched only once. All of these programs/data in main memory are quite a bit slower because they get very little benefit from the cache. The system memory on an M1 is basically ALL cache memory, so it simply takes much less time to get data from where it is to where it needs to be. As people are discovering, this makes an M1 much faster in real-world operations.
...........

There's been some discussion about performance of RISC vs CISC operation (RISC is the simpler instruction set). At least in my little test, focused only on the core, RISC compares very well to CISC.

Thanks Michael. Interesting stuff.

The big question for me is how much unified memory Apple can realistically fit on Apple Silicon without it being horribly expensive. The current max of 128GB is a bit low for large orchestral VI templates. It sounds like a lot of the performance gains of Apple Silicon would be negated by having RAM external to the processor, if the architecture even allowed it.

[kings79]

Thanks for the info 685 & Michael.

Some really cool positive stuff here. I can only imagine when PT is natively (supported) along with all the plugs. We aren't going to know ourselves.

I've installed everything on my studio so hopefully I can do some tests this weekend.

Funnily enough I'm using a 16 core 7,1 at the moment at the studio I'm contracted at and it's very buggy.

[Michael Carnes]

Originally Posted by Marsdy

Thanks Michael. Interesting stuff.

The big question for me is how much unified memory Apple can realistically fit on Apple Silicon without it being horribly expensive. The current max of 128GB is a bit low for large orchestral VI templates. It sounds like a lot of the performance gains of Apple Silicon would be negated by having RAM external to the processor, if the architecture even allowed it.

It's clear you'll have to stream in a lot more of the instruments. You'll probably have to lower the amount of the samples that you pre-buffer. So a lot really depends on how quickly and efficiently you can get your samples off whatever medium you have to store them. I'm very curious about how well this will work.

[Eric Lambert]

Originally Posted by Marsdy

The current max of 128GB is a bit low for large orchestral VI templates.

I don't think the day of having an entire orchestra loaded into RAM is quite upon us, yet.

I'm just thinking back to my early days (1992-ish) of loading SampleCell kits from CD-Roms onto PCI cards, physically popping discs into the CD-R for drums, then another disc for strings, then yet another for bass, etc. And those only held 32 MB per PCI card. Had you told me then that we'd one day be considering loading 128+ GIGs of samples into **RAM**...

As Michael said, streaming from drives is still part of the equation, but I don't think it's much of a hassle. I don't notice any kind of disadvantage, and I'm still on that trashcan.

[smurfyou]

Originally Posted by Eric Lambert

I don't think the day of having an entire orchestra loaded into RAM is quite upon us, yet.

I'm just thinking back to my early days (1992-ish) of loading SampleCell kits from CD-Roms onto PCI cards, physically popping discs into the CD-R for drums, then another disc for strings, then yet another for bass, etc. And those only held 32 MB per PCI card. Had you told me then that we'd one day be considering loading 128+ GIGs of samples into **RAM**...

As Michael said, streaming from drives is still part of the equation, but I don't think it's much of a hassle. I don't notice any kind of disadvantage, and I'm still on that trashcan.

That should be a Flex perk. Vintage Samplecell instruments.

[Eric Lambert]

Originally Posted by smurfyou

That should be a Flex perk. Vintage Samplecell instruments.

Haha! Coming up on 30 years, those are definitely set to come back in style.

[Marsdy]

Originally Posted by Eric Lambert

I don't think the day of having an entire orchestra loaded into RAM is quite upon us, yet.

I'm just thinking back to my early days (1992-ish) of loading SampleCell kits from CD-Roms onto PCI cards, physically popping discs into the CD-R for drums, then another disc for strings, then yet another for bass, etc. And those only held 32 MB per PCI card. Had you told me then that we'd one day be considering loading 128+ GIGs of samples into **RAM**...

As Michael said, streaming from drives is still part of the equation, but I don't think it's much of a hassle. I don't notice any kind of disadvantage, and I'm still on that trashcan.

Eric
I’m not loading everything into RAM, far from it! Still streaming like a boss here from NVMe on a Sonnet card. My current template is using around 200GB of RAM though just for the preloading and takes 5 minutes to load! Pretty much everything I have loaded has multiple mic positions which obviously at least doubles the RAM usage.

SampleCell? You’re as old as I me! I remember getting three Emu Ultras with 128MB each and thinking I was God! I couldn’t afford to get the libraries on CD-ROM so bought them on audio CD and sampled and looped them myself!