Last week a video appeared on the Web from David Lee showing how the new MacBook Pro would throttle down speeds when it got hot under processor loads. Apple told me that the issue Lee was experiencing has been identified and is being fixed today.
As you can imagine, when Apple heard about the problem, they contacted Lee and worked with him to isolate what could be causing the thermal throttling. After extensive testing, they did find the issue, and luckily it wasn’t a hardware issue, but rather a software bug in the firmware.
“Following extensive performance testing under numerous workloads, we’ve identified that there is a missing digital key in the firmware that impacts the thermal management system and could drive clock speeds down under heavy thermal loads on the new MacBook Pro,” An Apple representative told me. “A bug fix is included in today’s macOS High Sierra 10.13.6 Supplemental Update and is recommended. We apologize to any customer who has experienced less than optimal performance on their new systems. Customers can expect the new 15-inch MacBook Pro to be up to 70% faster, and the 13-inch MacBook Pro with Touch Bar to be up to 2X faster, as shown in the performance results on our website.”
The bug affects the Core i9, Core i7, and the 13-inch models, so you should install the supplemental update when it comes out this morning.
As Apple said in its statement, all of the performance benchmarks on its website are accurate. The company said that you needed the right combination of workloads for the bug to manifest itself and in all of their testing, they never encountered the problem.
In fact, many people using the MacBook Pro probably wouldn’t have seen the bug manifest itself at all because they didn’t have that perfect storm of extended heavy workloads to make it happen.
As it turns out, the fix for this is straightforward and can be applied to all users very quickly.
By the way, I just wanted to note that if Consumer Reports had found the problem, the comment threads would have been full of vitriol towards them, rather than Apple, if past performance is any indicator.
Interesting. If thermal problems can really be patched away I’d love a fix for my kid’s MacBook Air. 🙂
And yet people in this instance used software not designed for it to benchmark the MacBook Pros and few are batting an eye.
CR intentionally misconfigured Safari
No, they didn’t. They configured it to mimic how everyday users would use safari — just like the users benchmarking the laptops now are doing.
I’m sure ALL of the clickbait headlines resulting from this will be removed and updated now.
Ah, no. You missed what CR actually did to Safari to run their test.
No, I didn’t. I understand what they did and why they did it. That CR mimicked the behavior by using developer switches is irrelevant to the fact that there was a bug causing problems — and note that Apple was very careful not to say that the bug could *only* be caused by using the developer controls.
So since the fix is in the High Sierra update, will it also be in the Mojave beta?
Cue the next set of clickbait headlines that Apple’s quality control is going downhill and whatnot.
Only because CR would have installed a custom firmware or adjusted the thermal settings themselves to make it happen.
Why would we? It’s real world software that was not intentionally misconfigured.
CR intentionally misconfigured Safari and then called a bug resulting from that bad configuration a general problem. And then never backed down from it. That’s just scummy.
No, they got the results and immediately contacted Apple, gave them their testing data, and did everything they could to help figure out what was going on. That’s hardly just accepting them.
No, they got the results and immediately contacted Apple, gave them their testing data, and did everything they could to help figure out what was going on. That’s hardly just accepting them.
And in the face of this, CR doubled down: this was a real world scenario, they insisted
Oh, baloney. If they’d really been trying to conceal things they would have, you know, actually concealed things, rather than laying out exactly what they did when the issue came up.
Ah, no. You missed what CR actually did to Safari to run their test. There’s nothing real world about it.
CR was fiddling with switches not designed to be touched by anyone other than Safari/WebKit programmers (inside and outside Apple) and possibly website developers (though they’re likely to regret it, because it’s not the right shape of tool for them).
Consumer Reports could have done a good test without reaching into internals, though. Clearing the cache between iterations would have been a legitimate approach. Reaching into programmers-only internals and disabling the cache wasn’t, as it’s a configuration never used in the real world.
Software works best on paths most tested. That’s why sacrificing a chicken (and other insane ideas) is a poor approach to take to installing software updates. Everything should work, sure, especially along publicly accessible paths. But paths beyond developer only locks are often not just untested, but designed to break.
I just checked, btw, and the latest Safari removes the switches they were playing with. Instead of disabling the cache entirely, developers now have access to a much easier way of clearing the cache. It’s probably less convenient for Safari/WebKit programmers, but far less likely to hurt web developers.
Setting internal switches behind a developer-only switch is NEVER real world.
Setting internal switches behind a developer-only switch is NEVER real world.
And neither is putting a MBP in a freezer to see if that affects performance.
As to the blocking, I’m entertained that you couldn’t just stop replying but had to loudly announce your exit from the thread.
I’d say there’s quite a bit of difference in setting test configurations that end up producing erroneous results and testing different settings in an attempt to figure out what is causing erroneous results.
The issue with the Consumer Reports test is that they got unexpected results and just accepted them as a general failing of the computer instead of trying to determine if they were an artifact of their testing methodology.
It was even worse from my perspective: Had they admitted later it was not a real world scenario it would have been completely forgivable. Mistakes happen all the time.
They didn’t. It was up to someone else to prove their ridiculous methodology was not just ridiculous but broken. And in the face of this, CR doubled down: this was a real world scenario, they insisted.
That lack of humility is why I can never take them seriously again. The scientific mindset should be able to accept being wrong.