Live Performance Test and Geekbench

[Pasha]

Hi,

I'm very confused about what I can obtain with both old iMac 2008 and MPB 2012 13" with Live 9.
According to Geekbench (data comes from http://www.everymac.com) the MBP @2.5 Ghz has almost as twice the CPU power of my 2008 iMac 2.66 Ghz:

iMac (32/64bit) : 3368/4080
MPB (32/64bit) : 6690/7323

However in real life, the Live Performance Test with Live 9 tells a different story.
30% with MPB and 36% with iMac.

Can somebody help me understand this?
By looking at those figures it seems that a slightly underclocked CPU (2.5) is actually slightly faster
than the faster clock CPU (2.66). Apart from the architecture considerations, Mobile i5 CPUs has hyperthreading
so I can 'see' 4 virtual CPU from system monitor on my MBP, while the iMac is only dual core and no HT.
What I think is that those so called benchmarks are 'faked' by programs that exploit fully the CPU potential while usually Consumer software (Like Live) does not use 100% of the CPU capabilities. For this reason I would not trust benchmarks over a CPU choice. This is where Live Performance Test comes handy in my opinion.
What's your take?

Best
Pasha

[haven]

Are you basing you performance on the Live CPU meter and the same session? If so the i5 and i7 CPUs can be misleading since they can do variable clock speed or speed stepping. This is called Turbo Boost in Apple speak. Basically to save energy they have a variable clock rate that goes up and down based on load. The Live CPU meter seems to display what percentage of the current CPU speed is being used. http://gizmodo.com/5917500/what-is-intel-turbo-boost

You could install some extra tools on you make to read the CPU clock speed to get a better idea of whats going on. I have a overclocked PC with a i7 and before I tweaked it to not speed step I would see clock speeds from 1.5ghz to 4.5ghz depending on load in Live. The Live CPU meter was all over the place as the CPU speed changed. Since the Live CPU meter does not list the individual cores it can be misleading even without Speed Step enabled as some cores can be at 10% while others are at 90%.

[Pasha]

Are you basing you performance on the Live CPU meter and the same session? If so the i5 and i7 CPUs can be misleading since they can do variable clock speed or speed stepping. This is called Turbo Boost in Apple speak. Basically to save energy they have a variable clock rate that goes up and down based on load. The Live CPU meter seems to display what percentage of the current CPU speed is being used. http://gizmodo.com/5917500/what-is-intel-turbo-boost

You could install some extra tools on you make to read the CPU clock speed to get a better idea of whats going on. I have a overclocked PC with a i7 and before I tweaked it to not speed step I would see clock speeds from 1.5ghz to 4.5ghz depending on load in Live. The Live CPU meter was all over the place as the CPU speed changed. Since the Live CPU meter does not list the individual cores it can be misleading even without Speed Step enabled as some cores can be at 10% while others are at 90%.

Mmmm thank you. Very interesting. So basically the readings on Live CPU Meter (which makes the Live Performance Test)are not real readings? Turbo Boost and Speed step is working and Live CPU meter goes unnoticed.. So it's impossible to compare real load. That's why I was testing an i7 @ 2.3 Ghz today and the result was 25%. Completely misleading as I had expected half the results of my 2.66 Ghz (dual core) against an i7 quad core (albeit Mobile).
Better use Activity monitor instead, right?

[steko]

A few things:

1. Friedemann (Ableton) on Live's CPU meter (in a thread in a now closed subforum):

Hi,

the CPU meter in Live works differently than the usual CPU meters in the operating system.

In Live you see the ratio of the time that was actually needed to compute the audio signal and the time that
is available to compute it. The latter is just determined by the sample rate of the audio interface, i.e. at 48kHz
sample rate you need to compute 48000 samples in one second, if it takes longer, there will be drop-outs.

Therefore, values below 100% mean that the samples were faster calculated
than needed by the audio interface while values above 100% mean that calculating the samples took too long
for being delivered to the audio interface on time. In the multi-processor-case the slowest path, i.e. the processor that has to calculate most, determines that number.

On the OS level you usually see how much time a certain processor (or all together) devotes to a certain process.

Although both meters show '%' values, they are not really comparable.

Best, Friedemann

2. https://www.ableton.com/answers/which-p ... leton-live:

- Live does not support hyper-threading but multiple Cores.

3. In Live processing is distributed on a per-track basis. One track = one core.

Friedemann (Ableton) in Multicore-Thread from the now closed Beta 8.1 forum:

- since processing is distributed on a per-track basis it is better to use individual tracks for intense computations than to have them in a single track (i.e. inside a rack)
- if there is heavy computation inside a return track, sends to this return track that are not used should be disabled (via the context menu command)

Best, Friedemann

1. Whole bunch of tracks with no reverb on the tracks, but all being sent to a return with reverb = all of the tracks must be processed on the same core. Yes?

2. Whole bunch of tracks with their own reverbs and with their returns disabled = the tracks can be spread out over a number of cores as necessary. Yes?

3. Whole bunch of tracks with their own reverbs and with their returns disabled, but all being sent through the Master which has EQ, compression, etc. = all of the tracks must be processed on the same core. Yes? No?

1. The bunch of tracks will be distributed over all cores. When they all have been calculated, the single return track is calculated on a single core.

2. The bunch of tracks will be distributed over all cores.

3. The bunch of tracks will be distributed over all cores. When they all have been calculated, the master track with its processing (EQ etc.) is calculated.

[Pasha]

A few things:

1. Friedemann (Ableton) on Live's CPU meter (in a thread in a now closed subforum):

Hi,

the CPU meter in Live works differently than the usual CPU meters in the operating system.

In Live you see the ratio of the time that was actually needed to compute the audio signal and the time that
is available to compute it. The latter is just determined by the sample rate of the audio interface, i.e. at 48kHz
sample rate you need to compute 48000 samples in one second, if it takes longer, there will be drop-outs.

Therefore, values below 100% mean that the samples were faster calculated
than needed by the audio interface while values above 100% mean that calculating the samples took too long
for being delivered to the audio interface on time. In the multi-processor-case the slowest path, i.e. the processor that has to calculate most, determines that number.

On the OS level you usually see how much time a certain processor (or all together) devotes to a certain process.

Although both meters show '%' values, they are not really comparable.

Best, Friedemann

2. https://www.ableton.com/answers/which-p ... leton-live:

- Live does not support hyper-threading but multiple Cores.

3. In Live processing is distributed on a per-track basis. One track = one core.

Friedemann (Ableton) in Multicore-Thread from the now closed Beta 8.1 forum:

- since processing is distributed on a per-track basis it is better to use individual tracks for intense computations than to have them in a single track (i.e. inside a rack)
- if there is heavy computation inside a return track, sends to this return track that are not used should be disabled (via the context menu command)

Best, Friedemann

1. Whole bunch of tracks with no reverb on the tracks, but all being sent to a return with reverb = all of the tracks must be processed on the same core. Yes?

2. Whole bunch of tracks with their own reverbs and with their returns disabled = the tracks can be spread out over a number of cores as necessary. Yes?

3. Whole bunch of tracks with their own reverbs and with their returns disabled, but all being sent through the Master which has EQ, compression, etc. = all of the tracks must be processed on the same core. Yes? No?

1. The bunch of tracks will be distributed over all cores. When they all have been calculated, the single return track is calculated on a single core.

2. The bunch of tracks will be distributed over all cores.

3. The bunch of tracks will be distributed over all cores. When they all have been calculated, the master track with its processing (EQ etc.) is calculated.

Very informational answer, thank you. Getting into the guts of Live...
Now I begin to understand certain results, looking at the whole thing in a different way.
There are several things that should be considered when spending money on technology and the more you know, the better. Hyperthreading is over evaluated but when it is never used by software... Sits like a duck.
Maybe one can get 10% more but not that much. A quad core is where I will land. Of course an i7 has other capabilities but if Live does not take advantage from Hyperthreading why bother?

Thank you so much.
Pasha

[steko]

You're welcome!

Some more info on Live & hyperthreading: viewtopic.php?p=1508719#p1508719

[Pasha]

You're welcome!

Some more info on Live & hyperthreading: viewtopic.php?p=1508719#p1508719

Thanks! Today I tested the hard drive speed of my machines.
With my surprise I found out that Blackmagic HDD Benchmark reports less than 50MB/sec
Read / Write for my 7200 RPM HDD in my 2008 iMac... slower than an external 5400 RPM FW800 Lacie Rugged drive! The relatively recent Mid 2012 MBP 13" 5400 RPM drive is about 65 to 70 MB/sec..
Just incredible!.. for me at least.. ... Internal HDD are both SATA II drives, capable of 300 MB/Sec but used up for less than 30%!

Best
Pasha

[piZMo]

3. In Live processing is distributed on a per-track basis. One track = one core.

Friedemann (Ableton) in Multicore-Thread from the now closed Beta 8.1 forum:

- since processing is distributed on a per-track basis it is better to use individual tracks for intense computations than to have them in a single track (i.e. inside a rack)
- if there is heavy computation inside a return track, sends to this return track that are not used should be disabled (via the context menu command)

Best, Friedemann

1. Whole bunch of tracks with no reverb on the tracks, but all being sent to a return with reverb = all of the tracks must be processed on the same core. Yes?

2. Whole bunch of tracks with their own reverbs and with their returns disabled = the tracks can be spread out over a number of cores as necessary. Yes?

3. Whole bunch of tracks with their own reverbs and with their returns disabled, but all being sent through the Master which has EQ, compression, etc. = all of the tracks must be processed on the same core. Yes? No?

1. The bunch of tracks will be distributed over all cores. When they all have been calculated, the single return track is calculated on a single core.

2. The bunch of tracks will be distributed over all cores.

3. The bunch of tracks will be distributed over all cores. When they all have been calculated, the master track with its processing (EQ etc.) is calculated.

Does this apply to grouped tracks/a group track as well?

i.e. all grouped tracks will be spread evenly over all the cores. when they have been calculated the group track is calculated on a single core?

[Machinesworking]

I'm running out the door, but without trying to hurt anybodies feelings, the Live performance test is completely useless.
No two computers and OS report the same CPU to Live in terms of real percentages, the CPU meter in Live has always been bunk.

A real test of any DAW is a test to failure. Basically load plugs ins until there's noticeable audio degradation.
In the performance test on these forums my 8 core Mac pro scores badly, until you start doubling the tracks and realize it's still reading 65% at 5+ times the load!

Geekbench is a far more accurate indicator of your computers performance in Live than the test. It's one of those things where inadvertently bad science is a forum standard.

[Pasha]

I'm running out the door, but without trying to hurt anybodies feelings, the Live performance test is completely useless.
No two computers and OS report the same CPU to Live in terms of real percentages, the CPU meter in Live has always been bunk.

A real test of any DAW is a test to failure. Basically load plugs ins until there's noticeable audio degradation.
In the performance test on these forums my 8 core Mac pro scores badly, until you start doubling the tracks and realize it's still reading 65% at 5+ times the load!

Geekbench is a far more accurate indicator of your computers performance in Live than the test. It's one of those things where inadvertently bad science is a forum standard.

Thanks. I was smelling that the day I tested an i7 Quad 2.3 Ghz against my i5 2.5 dual and 5 years old core duo 2.66 GHz Penryn iMac. I think the trick is within Intel realm of throttling. The i7 Quad at 25% then i5 Dual at 30% and then the old 2.66 C2D at 36% does not reflect real performance . CPU are on demand these days in order to lower power consumption, even in desktops and workstations. On the other side Geekbench tests are written to exploit all the CPU exotic capabilities that might not be used in your software, giving unreal results. Sure at least Geekbench or Passmark for CPU only, gives you a better idea of relative power in CPU comparison.

[Machinesworking]

Thanks. I was smelling that the day I tested an i7 Quad 2.3 Ghz against my i5 2.5 dual and 5 years old core duo 2.66 GHz Penryn iMac. I think the trick is within Intel realm of throttling. The i7 Quad at 25% then i5 Dual at 30% and then the old 2.66 C2D at 36% does not reflect real performance . CPU are on demand these days in order to lower power consumption, even in desktops and workstations. On the other side Geekbench tests are written to exploit all the CPU exotic capabilities that might not be used in your software, giving unreal results. Sure at least Geekbench or Passmark for CPU only, gives you a better idea of relative power in CPU comparison.

To be completely fair, the Live performance test on this forum if performed to failure, (copy the tracks until right before your audio crackles and note the amounts of tracks you can run), that actually measures up quite well against Geekbench. DAW's tax the system pretty well so it's no surprise that the performance ratings in Geekbench match up to "to failure" tests for DAWs. Me and a guy with a new Mac Mini 4 core i7 Server tested to failure with that test and the performances were what you would expect given the ratings on Geekbench. Doing the test the 'normal' way results in the 8 core 2.66 Xeon Mac Pro looking the same as the Mini, whilst to failure results in the almost twice as powerful ratings Geekbench gives the Mac Pro.

[SuburbanThug]

Nice thread guys. Thanks steko and machinesworking!

[Pasha]

Thanks. I was smelling that the day I tested an i7 Quad 2.3 Ghz against my i5 2.5 dual and 5 years old core duo 2.66 GHz Penryn iMac. I think the trick is within Intel realm of throttling. The i7 Quad at 25% then i5 Dual at 30% and then the old 2.66 C2D at 36% does not reflect real performance . CPU are on demand these days in order to lower power consumption, even in desktops and workstations. On the other side Geekbench tests are written to exploit all the CPU exotic capabilities that might not be used in your software, giving unreal results. Sure at least Geekbench or Passmark for CPU only, gives you a better idea of relative power in CPU comparison.

To be completely fair, the Live performance test on this forum if performed to failure, (copy the tracks until right before your audio crackles and note the amounts of tracks you can run), that actually measures up quite well against Geekbench. DAW's tax the system pretty well so it's no surprise that the performance ratings in Geekbench match up to "to failure" tests for DAWs. Me and a guy with a new Mac Mini 4 core i7 Server tested to failure with that test and the performances were what you would expect given the ratings on Geekbench. Doing the test the 'normal' way results in the 8 core 2.66 Xeon Mac Pro looking the same as the Mini, whilst to failure results in the almost twice as powerful ratings Geekbench gives the Mac Pro.

Good point. It confirms my theory... so you made me happy!
We are making good science here!