The myth of single core performance

[bxs]

Subject: The myth of single core performance

There's so much chatter/discussion surrounding the importance or how to test a Mac for single Processor core performance that it bogles my mind.

Much is discussed comparing single core performance of one Mac model vs. another, with the intent of stating one is better than the other for a program that is designed to run on and use only one Processor's core.

With the new iMac Pro (iMP) everybody wants to know how each of the iMP models differ in single core performance. The discussions kind of go like; if your work is 'single core' will it run better on 8-core, 10-core, 14-core or 18-core where each model has a different core min/max frequency (the stated min frequencies 3.2/3.0/2.5/2.3 GHz and stated Turbo Boost frequencies 4.2/4.5/4.3/4.3 GHz).

Many people will jump to the conclusion that the 10-core with its 4.5 GHz Turbo Boost will be the best for a program that is designed to run on and use only one Processor's core even though its base frequency is 3.0 GHz which is lower than the base frequency of the 8-core at 3.2 GHz and max Turbo Boost frequency of 4.2 GHz.

Now, hopefully everybody understands that a program that is designed to run on and use only one Processor's core will not run continuously on any one core in the system all the time. The system (macOS) with its many active processes (system processes and user processes) will cause the 'single-core program' to bounce around from executing on one core to another. This is a natural behavior for a modern OS to share the Processor resources as it will constantly exchange what's running on one core in favor of another process that demands the CPU resource; its called context switching.

Given the above, it's highly unlikely that a program that is designed to run on and use only one Processor's core will ever see the Turbo Boost frequency for the iMP model its running on.

To give you some idea about what can be achieved in obtaining the Turbo Boot frequency I used my iMP 10-core to test a few things.

1) I ran a program that is designed to run on and use only one Processor's core with all 10 cores enabled. The observed average frequency as reported by Intel Power Gadget and iStat was 4.2 GHz.

2) I now disabled 8 of the cores using Xcode's Instruments and ran the program as I did in 1). The observed
average frequency as reported by Intel Power Gadget and iStat was 4.5 GHz.

3) I now disabled 9 of the cores using Xcode's Instruments and ran the program as I did in 1). The observed
average frequency as reported by Intel Power Gadget and iStat was 4.5 GHz.

So for a program that is designed to run on and use only one Processor's core will likely see 4.2 GHz on a 10-core iMP. It will not have access to the max Turbo Boost frequency of 4.5 GHz unless 8 or 9 of the cores are disabled.

So what can be said for the 8-core, 14-core and 18-core iMP models when running a program that is designed to run on and use only one Processor's core ?

My guess is that for the 10-core iMP as mentioned above that averaged 4.2 GHz, it will run a program that is designed to run on and use only one Processor's core faster (less wall clock time) than for the 8-core IMP model as it would not be able to sustain its 4.2 GHz Turbo Boost frequency.

My guess is that the 10-core iMP model will actually be the best iMP model for running a program that is designed to run on and use only one Processor core.

I think the story to be taken away with all the above is that to determine which iMP model is best for a program that is designed to run on and use only one Processor's core is that it must be run on all the iMP models to find out and not think that studying just the base and max frequencies of each iMP model is a means for deciding this.

 

[Darmok N Jalad]

Curious how the results would go under Windows, especially since there are additional programs that can monitor max CPU frequency, even if it’s just for a second (HWmonitor). I wish there were more programs like this for MacOS, especially for those of us on pre-gen-2-Core CPUs that can’t run the Intel tool. The best I can assume is that my Xeon’s behavior in Windows is similar to how it functions in MacOS.

Nice research, btw.

 

[Trebuin]

Subject: The myth of single core performance

There's so much chatter/discussion surrounding the importance or how to test a Mac for single Processor core performance that it bogles my mind.

Much is discussed comparing single core performance of one Mac model vs. another, with the intent of stating one is better than the other for a program that is designed to run on and use only one Processor's core.

With the new iMac Pro (iMP) everybody wants to know how each of the iMP models differ in single core performance. The discussions kind of go like; if your work is 'single core' will it run better on 8-core, 10-core, 14-core or 18-core where each model has a different core min/max frequency (the stated min frequencies 3.2/3.0/2.5/2.3 GHz and stated Turbo Boost frequencies 4.2/4.5/4.3/4.3 GHz).

Many people will jump to the conclusion that the 10-core with its 4.5 GHz Turbo Boost will be the best for a program that is designed to run on and use only one Processor's core even though its base frequency is 3.0 GHz which is lower than the base frequency of the 8-core at 3.2 GHz and max Turbo Boost frequency of 4.2 GHz.

Now, hopefully everybody understands that a program that is designed to run on and use only one Processor's core will not run continuously on any one core in the system all the time. The system (macOS) with its many active processes (system processes and user processes) will cause the 'single-core program' to bounce around from executing on one core to another. This is a natural behavior for a modern OS to share the Processor resources as it will constantly exchange what's running on one core in favor of another process that demands the CPU resource; its called context switching.

Given the above, it's highly unlikely that a program that is designed to run on and use only one Processor's core will ever see the Turbo Boost frequency for the iMP model its running on.

To give you some idea about what can be achieved in obtaining the Turbo Boot frequency I used my iMP 10-core to test a few things.

1) I ran a program that is designed to run on and use only one Processor's core with all 10 cores enabled. The observed average frequency as reported by Intel Power Gadget and iStat was 4.2 GHz.

2) I now disabled 8 of the cores using Xcode's Instruments and ran the program as I did in 1). The observed
average frequency as reported by Intel Power Gadget and iStat was 4.5 GHz.

3) I now disabled 9 of the cores using Xcode's Instruments and ran the program as I did in 1). The observed
average frequency as reported by Intel Power Gadget and iStat was 4.5 GHz.

So for a program that is designed to run on and use only one Processor's core will likely see 4.2 GHz on a 10-core iMP. It will not have access to the max Turbo Boost frequency of 4.5 GHz unless 8 or 9 of the cores are disabled.

So what can be said for the 8-core, 14-core and 18-core iMP models when running a program that is designed to run on and use only one Processor's core ?

My guess is that for the 10-core iMP as mentioned above that averaged 4.2 GHz, it will run a program that is designed to run on and use only one Processor's core faster (less wall clock time) than for the 8-core IMP model as it would not be able to sustain its 4.2 GHz Turbo Boost frequency.

My guess is that the 10-core iMP model will actually be the best iMP model for running a program that is designed to run on and use only one Processor core.

I think the story to be taken away with all the above is that to determine which iMP model is best for a program that is designed to run on and use only one Processor's core is that it must be run on all the iMP models to find out and not think that studying just the base and max frequencies of each iMP model is a means for deciding this.

Geekbench supports your claim on the 10 core, however, Geekbench does not fully test single thread because it does not establish the correct speed because the test is not as demanding as it should be. For real word performance, running both the 8c & the 10c using something that will utilize the entire processing power during a single thread test will show that the 8c beats the 10c because the 8c is running maxed at 3.9 vs the 10c 3.5. That's provided the single threaded program is demanding enough to utilize up to 100% & for long enough for the thermal down clock to kick in. Those programs that don't, the benchmark won't matter as much.

Now, if you were to turn cores off to run single thread options, this outcome may actually be significantly different, but I haven't seen those benchmarks yet & honestly, I don't know anyone or a program that would benefit as much from adjusting the single thread performance. Most demanding programs now utilize multi-threadings which is beyond the scope of this thread.

 

[bxs]

Geekbench supports your claim on the 10 core, however, Geekbench does not fully test single thread because it does not establish the correct speed because the test is not as demanding as it should be. For real word performance, running both the 8c & the 10c using something that will utilize the entire processing power during a single thread test will show that the 8c beats the 10c because the 8c is running maxed at 3.9 vs the 10c 3.5. That's provided the single threaded program is demanding enough to utilize up to 100% & for long enough for the thermal down clock to kick in. Those programs that don't, the benchmark won't matter as much.

Now, if you were to turn cores off to run single thread options, this outcome may actually be significantly different, but I haven't seen those benchmarks yet & honestly, I don't know anyone or a program that would benefit as much from adjusting the single thread performance. Most demanding programs now utilize multi-threadings which is beyond the scope of this thread.

Thanks.....

Trying to get my iMP to heat up with fans running above there idle RPM of around 1100 is very difficult. I can get them up to no more than 1600 RPM running a full CPU intensive load across the 10 cares and the 10 logical cores. Temps are always maintained at around 93ºC with a slight up and down trend of no more than 2ºF. With this kind of load running for around 1 hour the iMP simply does not overheat nor do fans run at high RPM.

I'm guessing I will need to introduce some heavy workload for the Vega 64 to get some more heat generated.

I attach a screen shot of my load test having run for around 45 mins.

 

[anticipate]

Thanks.....

Trying to get my iMP to heat up with fans running above there idle RPM of around 1100 is very difficult. I can get them up to no more than 1600 RPM running a full CPU intensive load across the 10 cares and the 10 logical cores. Temps are always maintained at around 93ºC with a slight up and down trend of no more than 2ºF. With this kind of load running for around 1 hour the iMP simply does not overheat nor do fans run at high RPM.

I'm guessing I will need to introduce some heavy workload for the Vega 64 to get some more heat generated.

I attach a screen shot of my load test having run for around 45 mins.

How are you seeing sensor data in istat menus on your iMP? I recently installed everything from scratch on my iMP - OS, software, everything from a blank drive. I get no sensor data in istat menus.

As for fans, I have indeed heard them spin up... at weird times. At full blast they are relatively quiet; they sound like a moderate breeze at best - but it wasn't connected with how hard the processor was working at any given time. It seemed to be more of a function of how much heat had built up in the case... kind of a delayed reaction - to work I had done 30 min prior.

If I could see the sensor data, it would make more sense.

 

[Darmok N Jalad]

How are you seeing sensor data in istat menus on your iMP? I recently installed everything from scratch on my iMP - OS, software, everything from a blank drive. I get no sensor data in istat menus.

As for fans, I have indeed heard them spin up... at weird times. At full blast they are relatively quiet; they sound like a moderate breeze at best - but it wasn't connected with how hard the processor was working at any given time. It seemed to be more of a function of how much heat had built up in the case... kind of a delayed reaction - to work I had done 30 min prior.

If I could see the sensor data, it would make more sense.

Does Macs Fan Control work?

Curious about hitting 93C. That seems really high. I wonder what the back of the PCB reaches, and what might be nearby. Personally, I’d be more comfortable with much lower temps and more fan noise under load.

 

[shaunp]

Nice bit of research there. I moved from Mac to Windows as my main desktop around 18 months ago, the reasons why are not really relevant for this post, were are talking CPU's here. When making the move I looked to balance the number of cores vs. clock speed and cost. While I could get a Xeon with loads of cores it would have been expensive and wouldn't have delivered that much more for my workloads. The key thing people need to take from this is to understand what they are trying to do and then get the right CPU for that.

 

[anticipate]

Does Macs Fan Control work?

Curious about hitting 93C. That seems really high. I wonder what the back of the PCB reaches, and what might be nearby. Personally, I’d be more comfortable with much lower temps and more fan noise under load.

Agreed!

Actually I found a beta of iStat Menus 6.1 (soon to be released) that adds sensor data and fan control. Will keep an eye out...

 

[bxs]

Agreed!

Actually I found a beta of iStat Menus 6.1 (soon to be released) that adds sensor data and fan control. Will keep an eye out...

Yes, the first iStat I used was not reporting I had 10 cores for my iMP with 10 cores. It reported only 8 cores. I contact Bjango about this and they directed me to download and use below...

https://s3.amazonaws.com/bjango/files/istatmenus6/930.zip

This version (is Version 6.00) corrected the # cores being reported as well as displaying the fan RPM. This iStat version does not provide a means for controlling fan RPM even though it has controls for doing so.... I guess that will come a bit later. I would like to have fan control to evaluate ramping the RPM up to lower temps and maybe avoid the core frequency throttling.

BTW.... I had 20 copies of Stockfish running to get all cores (physical and logical ones) ramped up to 100% along with a few traditional "yes >/dev/null 2>&1 &" running just to fill in and use any spare CPU cycles.

 

[Trebuin]

Yes, the first iStat I used was not reporting I had 10 cores for my iMP with 10 cores. It reported only 8 cores. I contact Bjango about this and they directed me to download and use below...

https://s3.amazonaws.com/bjango/files/istatmenus6/930.zip

This version (is Version 6.00) corrected the # cores being reported as well as displaying the fan RPM. This iStat version does not provide a means for controlling fan RPM even though it has controls for doing so.... I guess that will come a bit later. I would like to have fan control to evaluate ramping the RPM up to lower temps and maybe avoid the core frequency throttling.

BTW.... I had 20 copies of Stockfish running to get all cores (physical and logical ones) ramped up to 100% along with a few traditional "yes >/dev/null 2>&1 &" running just to fill in and use any spare CPU cycles.

You're definitely along the right track of getting this done. I have an older thread that includes a lot of other tests that you can try to use to help:
https://forums.macrumors.com/thread...nchmarks-wipe-reinstall-ram-upgrades.2095033/

I'll probably ending up adding your info to that as well when I update it again.