I have written a very CPU intensive threaded task that works as expected on my 2012 MacBook Pro quad core. I turn it loose with 20 threads and the temperatures get up to about 100 °C as measured with Intel Power Gadget with minimal throttling.

Take the same program and data files home to my 2016 13" MacBook Pro with a dual core machine and start it up, I would expect that it would also keep up the 3.3-3.4 GHz until the temperature gets near the 100 °C mark. Top command shows the task at 350% (2 cores each dual threaded), but the CPU frequency gets cut to 1.6-1-8 GHz with the temperature only at 60 °C or so with the fans dead quiet. If I start 4 separate single threaded CPU tasks, the machine behaves as expected with it keeping up the 3.3-3.4 GHz until it hits the 100 °C and the fans get cranking. The question is why is my CPU being throttled?

Both machines are up to date and running the same versions of gcc. If I even take the binary from the working machine and put it on the 2016 Mac, it has the same problem.

If I run 3 or 4 CPU single threads so the machine is going at full speed, then start the threaded program, it slows the frequency down also.

Both machines have 16 GB of RAM.


After playing around with code, I suspect that it is getting throttled when a task creates too many threads. In this program, I take each record I read and create a thread for it. I only let 20 or so threads go at a time so at no time is there more than 21 threads, but there are 14,400,000 records to be processed so over the 30 minutes or so each of those records will be processed by a separate thread.

I created a trivial pthread program that sucked CPU time and set 10 of them running. The problem laptop ran that and warmed up to 95C without issues.

I guess I will rewrite my code to reuse the same thread instead of destroying them and starting them up again.

Update 5/13/17

After several hours of work, it now only creates n threads and just reuses them, that didn't help. Other than CPU temperature, what will cause this machine to throttle down?

  • 1
    I love this question! How about running a different specific multithreaded task? I'd suggest running something like an ffmpeg task (on a 1080p or 4K video, to make sure it uses all available CPU resources) and see if it throttles down. This might narrow the problem down to either: your program in that machine or all multithreaded programs on that machine
    – NoahL
    Commented May 4, 2017 at 2:08
  • 1
    If I run Cinebench R15 benchmark, it uses the threaded tasks and runs as expected, temperature gets up to about 100C and the fans come up. Intel Power Gadget shows the CPU frequency is still near 3.3Ghz. So it doesn't look like a hardware issue. All the code is just C code with nothing that fancy using p_threads and minimal Mutex locks. The program is mostly DNA sequence processing with one thread pulling in something like 16 gig of data and passing it to n individual threads for the heavy number crunching.
    – markatlnk
    Commented May 4, 2017 at 2:45
  • 1
    That looks like other programs can hit the ceiling you are aiming for? If the problem is from your special code alone we might need more info on that code. Albeit, where is your data to be processed? External? How much work does kernel_task report? Other temp sensors? Commented Sep 12, 2017 at 7:02
  • 1
    Your CPU has 8 logical cores, not 4, so 4 threads would show as 50% total CPU usage. I wonder if that affects your system's load estimate.
    – sudo
    Commented Nov 3, 2017 at 17:44
  • I don't know if you'd want to go through the trouble, but you could try debugging at the kernel level with the debug kernel instead. You can get it if you click more in downloads on the apple dev site. Commented Mar 15, 2018 at 10:16

4 Answers 4


This may be a longshot, but perhaps the difference in single-core performance and/or cache performance between the 2012 and 2016 cpu packages are large enough that the cores are data-starved and throttling down until they are able to work again?

I'm making that guess because you indicate enough single-thread processes can run full speed on all cores, and a simple multi-thread program can run full speed on all cores.

That makes me think there is something in the program design of your real workload vs the test multi-thread workload that isn't letting the CPUs work all the time


The kernel extension /System/Library/Extensions/AppleACPIPlatform.kext controls a lot of temperature and CPU safeguards. It's already compiled, obviously, on your system, but it may be available on https://opensource.apple.com (I can't find it, but I only gave it a quick look). It wouldn't surprise me if Apple had very conservative settings on CPU capability.

  • 3
    AFAIK the Apple kexts aren't open source. (Strangely?) the best resource for info on this is the Hackintoshing community because of the need to inject drivers.
    – JMY1000
    Commented Dec 22, 2017 at 5:32
  • Not strange at all! The tinkerers give the best advice because they know a lot more than they should first hand. As for the conservative CPU settings, do remember that the MBP has a great heatsink for burst performance, but not so great for sustained cycles. It's quite likely this problem is down to Apple wanting to pre-emptively keep your legs from being cooked. I heard about a few lawsuits over that with the 2012MBP. Commented May 19, 2018 at 21:44

Whenever the os recognizes threads as unpredictable and out of control it will throttle down to remain hardware and system stability, the 2012 model behaves different and might lock up in worst case. Happened to me with poorly implemented thread control, my fault. Just dont run that many threads on an dual core.


Happened to me with poorly implemented thread control, my fault. Just dont run too many threads on a dual core CPU.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .