Mac Pro 12Core vs Mac Mini 4Core.. Mac Mini wins

[Venshield]

I came up on a 12Core 3.46GHz Mac Pro(5,1) and I compared Pro Tools 12 rendering speeds to my Mac Mini quad core i7(2012) and I noticed the Mac Mini was bouncing the same sessions 10 to 15 percent faster than the 12 core Mac Pro.. Wow.

I believe this happened either because either Pro tools 12 doesn't use multiple cores properly, or multiple cores are overrated once you get to more than 4 cores. Any thoughts?

[musicman691]

Originally Posted by Venshield

I came up on a 12Core 3.46GHz Mac Pro(5,1) and I compared Pro Tools 12 rendering speeds to my Mac Mini quad core i7(2012) and I noticed the Mac Mini was bouncing the same sessions 10 to 15 percent faster than the 12 core Mac Pro.. Wow.

I believe this happened either because either Pro tools 12 doesn't use multiple cores properly, or multiple cores are overrated once you get to more than 4 cores. Any thoughts?

The thing to getting all cores in use is to spread the load out. Don't load up one vi (say Kontakt) with multiple instruments but spread them out amongst multiple instances of Kontakt. There's nothing to your thought about more than 4 cores is overated.

10%-15% faster isn't much difference. Are the drive setups in your Mini and cheesegrater the same? Pop ssd's in that and it'll fly - I know mine speeded up (I have a single 3.46GHz hex core in my 5,1). As regards the number of cores - you're talking actual cores and not the number of hyper-threaded cores? Same amount of ram in each? Unless those specs are the same the comparison isn't really valid.

[25ghosts]

Originally Posted by Venshield

I came up on a 12Core 3.46GHz Mac Pro(5,1) and I compared Pro Tools 12 rendering speeds to my Mac Mini quad core i7(2012) and I noticed the Mac Mini was bouncing the same sessions 10 to 15 percent faster than the 12 core Mac Pro.. Wow.

I believe this happened either because either Pro tools 12 doesn't use multiple cores properly, or multiple cores are overrated once you get to more than 4 cores. Any thoughts?

It takes time to fire up a Thread of execution. Each thread needs it own resources or employ thread-locks if it hasnt to prevent data corruption. Either way, both take time. The faster the speed to your heap of memory the faster those Threads running separate cores can get the data resources they need and in many cases pass back that data to the main thread of the application (Pro Tools). Again, the faster (larger) the bandwidth of the processor the faster this can occur.

The speed bump you are seeing could be due to the mac mini being newer and thus have greater band width and faster memory access.

5 years ago - i ditched my 8 Core Nehalem with PTHD3 for a retina MacBook pro with SSD. Maximizing the Nehalem with TDM and RTAS (100% CPU on both) at that time barely made the retina go to work. It swallowed the same session (Converted the TDM to RTAS and ran the native RTAS) and bare scratched 20% CPU.

Many ol' timers need a big tower to feel that their computer is fast. This is delusional at best and does not reflect reality. Audio is very easy to process in comparison to video. A 2016 MacBook Pro can easily even with its small GPU render 16k x 16x images in realtime. They can run 200+ Reverbs in Logic or PT while playing back 100 audio tracks without breaking much of a sweat. And with the connectivity of Thunderbolt - there isnt much you can't attach. I recommend to everyone I talk to, to ditch their clunky tower and move on to a laptop. Personally, I have two 5k LG FinePix displays hooked up to the thunderbolt ports of the 2016 retina MBP which hangs below my desk and is invisible. Got my SSDs hooked up to a thunderbolt dock - its a dream setup. And when I leave, I unplug 3 cables and have my work with me.

While there may be scenarios where that is not enough I would say that if one can't get it done on a retina MacBook pro 2016 - (even 2013) - chances are that one has other issues than the horse powers of the CPU and should perhaps study before turning on the computer.

In regards to multi processing. In many scenarios it is a total win situation. But it takes great and contemplate design strategies on the programmer side to really get it flying. But its worth it.
However, in many cases where you'd think it is employable it is not. Real Time would be one. If i.e. the effect has to be absolute synchronous with the visual movement of the slider the user is moving - it could pose a problem given the fact that ALL user interface updates must (mandatory must) happen on the main thread. So if you go ahead and tell the effect to render(process) in the back ground it might be finished way before your slider is even redrawn to reflect where you wanted to move its head to in pixel space. Or after.

One example where MP is a Godsend is when you load your Protools session which might have 200 tracks. If the load process would not happen on the BG thread you would have to sit and wait for the app to become responsive which could take minutes. Today, if done right, the app will become responsive immediately while the files (data) are read in from disk and loaded in to RAM or partially loaded in to stream if streaming is happening.

Another would be when you load a big NASA image 16000x16000 pixels * 4 (Color Components) into an app hauling the pixels from a spinning drive. That could take several minutes. If loaded on the BG Thread the user would could do other work while it loads and when it is done - it will let you know that it is ready to work with. Rendering such an image on the CPU (if the GPU hasnt got sufficient memory) would take a long time if you dont MP it. In a scenario where you'd want to brighten the image (Multiply each color component by 2) you could spin off ass many cores as you can because each pixel can be calculated regardless of the values of the other pixels. SO if you have 12 cores you could divide the image into i..e 10 tiles and calculate each tile on a separate core increasing the speed to theoretical 10x minus the time it takes to setup the resources, thread locks and fire up the threads.

Man, this post got a little long...

[Venshield]

Originally Posted by musicman691

The thing to getting all cores in use is to spread the load out. Don't load up one vi (say Kontakt) with multiple instruments but spread them out amongst multiple instances of Kontakt. There's nothing to your thought about more than 4 cores is overated.

10%-15% faster isn't much difference. Are the drive setups in your Mini and cheesegrater the same? Pop ssd's in that and it'll fly - I know mine speeded up (I have a single 3.46GHz hex core in my 5,1). As regards the number of cores - you're talking actual cores and not the number of hyper-threaded cores? Same amount of ram in each? Unless those specs are the same the comparison isn't really valid.

The 12Core(2 hex core) machine has 32GB of Ram and the Mac Mini has 16... They both are running on Solid State drives... (and btw.. the 12core machine smoked the Mac Mini when I tested them in Logic Pro X)

[Venshield]

Originally Posted by 25ghosts

It takes time to fire up a Thread of execution. Each thread needs it own resources or employ thread-locks if it hasnt to prevent data corruption. Either way, both take time. The faster the speed to your heap of memory the faster those Threads running separate cores can get the data resources they need and in many cases pass back that data to the main thread of the application (Pro Tools). Again, the faster (larger) the bandwidth of the processor the faster this can occur.

The speed bump you are seeing could be due to the mac mini being newer and thus have greater band width and faster memory access.

5 years ago - i ditched my 8 Core Nehalem with PTHD3 for a retina MacBook pro with SSD. Maximizing the Nehalem with TDM and RTAS (100% CPU on both) at that time barely made the retina go to work. It swallowed the same session (Converted the TDM to RTAS and ran the native RTAS) and bare scratched 20% CPU.

Many ol' timers need a big tower to feel that their computer is fast. This is delusional at best and does not reflect reality. Audio is very easy to process in comparison to video. A 2016 MacBook Pro can easily even with its small GPU render 16k x 16x images in realtime. They can run 200+ Reverbs in Logic or PT while playing back 100 audio tracks without breaking much of a sweat. And with the connectivity of Thunderbolt - there isnt much you can't attach. I recommend to everyone I talk to, to ditch their clunky tower and move on to a laptop. Personally, I have two 5k LG FinePix displays hooked up to the thunderbolt ports of the 2016 retina MBP which hangs below my desk and is invisible. Got my SSDs hooked up to a thunderbolt dock - its a dream setup. And when I leave, I unplug 3 cables and have my work with me.

While there may be scenarios where that is not enough I would say that if one can't get it done on a retina MacBook pro 2016 - (even 2013) - chances are that one has other issues than the horse powers of the CPU and should perhaps study before turning on the computer.

In regards to multi processing. In many scenarios it is a total win situation. But it takes great and contemplate design strategies on the programmer side to really get it flying. But its worth it.
However, in many cases where you'd think it is employable it is not. Real Time would be one. If i.e. the effect has to be absolute synchronous with the visual movement of the slider the user is moving - it could pose a problem given the fact that ALL user interface updates must (mandatory must) happen on the main thread. So if you go ahead and tell the effect to render(process) in the back ground it might be finished way before your slider is even redrawn to reflect where you wanted to move its head to in pixel space. Or after.

One example where MP is a Godsend is when you load your Protools session which might have 200 tracks. If the load process would not happen on the BG thread you would have to sit and wait for the app to become responsive which could take minutes. Today, if done right, the app will become responsive immediately while the files (data) are read in from disk and loaded in to RAM or partially loaded in to stream if streaming is happening.

Another would be when you load a big NASA image 16000x16000 pixels * 4 (Color Components) into an app hauling the pixels from a spinning drive. That could take several minutes. If loaded on the BG Thread the user would could do other work while it loads and when it is done - it will let you know that it is ready to work with. Rendering such an image on the CPU (if the GPU hasnt got sufficient memory) would take a long time if you dont MP it. In a scenario where you'd want to brighten the image (Multiply each color component by 2) you could spin off ass many cores as you can because each pixel can be calculated regardless of the values of the other pixels. SO if you have 12 cores you could divide the image into i..e 10 tiles and calculate each tile on a separate core increasing the speed to theoretical 10x minus the time it takes to setup the resources, thread locks and fire up the threads.

Man, this post got a little long...

I appreciate your time and thoughts!

Yes my Mac Mini's memory has better bandwidth (1600MHz) than my 12Core Machine (1333MHz) but the problem is... I tested both machines with Logic Pro X and the 12Core(cheese grater) Machine outperformed the MacMini by a satisfactory margin...

Bouncing times in Logic Pro X

Song #1 Mac Mini - 1 min 37 sec
Song #1 12Core - 59 sec

Song #2 Mac Mini - 1 min 17 sec
Song #2 12Core - 45 sec

------
Bouncing times in Pro Tools 12.5.2

Song #1 Mac Mini - 54.09 sec
Song #1 12Core - 56.59 sec

Song #2 Mac Mini - 28.2 sec
Song #2 12Core - 29.07 sec

------

Here are my Geekbench 4 scores for both machines as well...

12Core Single core Score: 2771
12Core Multi core Score: 23390

Mac Mini Single core Score: 3388
Mac Mini Multi core Score: 10706

------

I'm thinking it's the way Pro Tools 12 uses multi core/threaded machines...

I wasn't expecting a 3 fold increase over the MacMini Machine but I was at least expecting some kind of improvement in Pro Tools lol

I wish I had 1 12Core 2013(trashcan) machine to test! It could be a bandwidth thing but I believe it also has to do with the single core speeds (and the way Pro Tools uses them) as well.

[YYR123]

Originally Posted by Venshield

I came up on a 12Core 3.46GHz Mac Pro(5,1) and I compared Pro Tools 12 rendering speeds to my Mac Mini quad core i7(2012) and I noticed the Mac Mini was bouncing the same sessions 10 to 15 percent faster than the 12 core Mac Pro.. Wow.

Running PT? which version?

I wonder if it matters which version of PT at all, but just curious.

[Venshield]

Originally Posted by YYR123

Running PT? which version?

I wonder if it matters which version of PT at all, but just curious.

I'm running PT 12.5.2 on both machines in Mac OS 10.11.6. I'm curious as well. I'll be repeating the same tests in PT 12.8.2 soon

[guitardom]

Likely has to do with the core speed utilization for bouncing. In outright Pro Tools performance for mixing and plugin power, the 12 core will handily have more power. Now imagine if Mac guys could use a modern 10 core running at 4.5Ghz....

[25ghosts]

Originally Posted by Venshield

I appreciate your time and thoughts!

Yes my Mac Mini's memory has better bandwidth (1600MHz) than my 12Core Machine (1333MHz) but the problem is... I tested both machines with Logic Pro X and the 12Core(cheese grater) Machine outperformed the MacMini by a satisfactory margin...

Bouncing times in Logic Pro X

Song #1 Mac Mini - 1 min 37 sec
Song #1 12Core - 59 sec

Song #2 Mac Mini - 1 min 17 sec
Song #2 12Core - 45 sec

------
Bouncing times in Pro Tools 12.5.2

Song #1 Mac Mini - 54.09 sec
Song #1 12Core - 56.59 sec

Song #2 Mac Mini - 28.2 sec
Song #2 12Core - 29.07 sec

------

Here are my Geekbench 4 scores for both machines as well...

12Core Single core Score: 2771
12Core Multi core Score: 23390

Mac Mini Single core Score: 3388
Mac Mini Multi core Score: 10706

------

I'm thinking it's the way Pro Tools 12 uses multi core/threaded machines...

I wasn't expecting a 3 fold increase over the MacMini Machine but I was at least expecting some kind of improvement in Pro Tools lol

I wish I had 1 12Core 2013(trashcan) machine to test! It could be a bandwidth thing but I believe it also has to do with the single core speeds (and the way Pro Tools uses them) as well.

Did u bounce off or online ?

If offline, the grater should be much faster.
If you launch Activity Monitor from Utilities and from its window menu select CPU Monitor you should see all CPUs spinning up on an offline bounce

[25ghosts]

Originally Posted by guitardom

Likely has to do with the core speed utilization for bouncing. In outright Pro Tools performance for mixing and plugin power, the 12 core will handily have more power. Now imagine if Mac guys could use a modern 10 core running at 4.5Ghz....

They can (soon) iMac pro has 18 of em