(This is an extension of the original post by Rhys Oxenhams).
Lately, I’ve noticed that my MBP often slows down drastically after it’s on for a while, or if I run some computation-intensive multi-threaded code. Today, I finally decided to explore the problem. (DISCLAIMER: I am a OS X noobie – I do most of my code in linux – so please take what I say with a grain of salt. Nonetheless, if it seems that you have having a similar problem, I encourage you to try out this method. Be sure to let me know if it works!) The way I see it, you have two solutions:
Option 1: Use Windows
People in the tech industry often forget that Windows, apart from its myraid of issues related to security, is actually a well-designed operating system. Yes, OS X maintains a higher level of compatibility with Linux systems, but Windows is still superior on some fronts. I use my Windows partition primarily for running large-scale image processing experiments in MATLAB (it runs horribly slow in OS X), and for performing GPU-intensive tasks (I increase both core and memory clock frequencies for the discrete 750M).
From my experience, booting into Windows removes the the throttling issues. Of course, your computer will still shut down if any of the core components reaches a temperature of Tjunction, which is typically somewhere around 100 degrees Celsius for mobile CPUs and 150 degrees or so for GPUs.
Option 2: Modify kernel drivers
Warning: modify kernel drivers at your own risk.
There is a way, however, to reduce throttling directly in OS X. After replicating this condition, I checked both the activity monitor and ran top (which displays the most CPU-intensive, i.e. top, processes). I quickly noticed that the generic “kernel_task” process was responsible for a huge portion of the CPU usage on my computer. A quick google search led me to the link above, which I promptly tried. It seemed to make sense as well – MBPs are known for throttling both CPUs and GPUs in order to meet power and temperature constraints, and Intel’s SpeedStep technology paves the way for OS X to dynamically adjust the clock periods of the on-board oscillators. One can imagine why this is just by looking at their design, too.
One problem – the numerical portion of the model identifier for all mid-2014 MBPs is 11,3, which, after looking inside the aforementioned kext (kernel driver), the file that we need to identify and remove doesn’t actually exist. If you try removing all plists within the kext, nothing noticeable happens upon reboot – the driver continues to hog resources.
It turns out that you can use the
pmset, which allows you to manage a variety of power-related settings from the command line. Open up a terminal and type:
sudo pmset -a dps 0
It should disable dynamic clock cycle changes and other “power optimizations” which OS X automatically does.