• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

AMD Processors No Longer Crippled with Latest MATLAB MKL Update

btarunr

Editor & Senior Moderator
Staff member
Joined
Oct 9, 2007
Messages
47,670 (7.43/day)
Location
Dublin, Ireland
System Name RBMK-1000
Processor AMD Ryzen 7 5700G
Motherboard Gigabyte B550 AORUS Elite V2
Cooling DeepCool Gammax L240 V2
Memory 2x 16GB DDR4-3200
Video Card(s) Galax RTX 4070 Ti EX
Storage Samsung 990 1TB
Display(s) BenQ 1440p 60 Hz 27-inch
Case Corsair Carbide 100R
Audio Device(s) ASUS SupremeFX S1220A
Power Supply Cooler Master MWE Gold 650W
Mouse ASUS ROG Strix Impact
Keyboard Gamdias Hermes E2
Software Windows 11 Pro
MATLAB received an update that no longer cripples users of AMD processors. Back in November 2019, there was quite some controversy when it emerged that MATLAB, a popular computing platform popular with engineering firms, universities, and research institutes, wasn't working optimally with AMD processors. Specifically, the suite's Intel MKL (math kernel library) component was designed such that if it didn't recognize the "GenuineIntel" CPUID string, it would disable fast AVX2 code-paths and fall back to SSE. This would inflict anywhere between 20-300 percent performance penalties on "AuthenticAMD" processors.

Reddit user Nedflanders1976 developed a tweak back in November, which spoofs MKL into thinking AMD processors are "GenuineIntel," enabling it to leverage modern instruction sets such as SSE4, AVX, and AVX2. AMD processors have been supporting SSE4 and AVX since its 2011 FX-series, and AVX2 since 2017 Ryzen. With the latest R2020a version, MATLAB automatically enables AVX2 execution on AMD processors that support the instruction set. A quick set of tests by ExtremeTech confirms that the update does indeed leverage the faster code-path by default, with Ryzen Threadripper 3960X and 3970X gaining over 200% performance and beating the Core i9-10980XE (something that needed the Nedflanders1976 tweak earlier).



View at TechPowerUp Main Site
 
I remember there have been discussions about this way back and some not long ago on this forum. So it turns out MATLAB was crippling AMD CPUs. Two bad it is a tweak by a guy not genuine software update by the software developer.
 
Soooo it "only" took them 4 months to implement a fix that a random guy from Reddit managed to make in a day or two.
Not to mention Ryzen is here since 2017... talk about lazy.
 
So how much was Intel paying them?
 
Soooo it "only" took them 4 months to implement a fix that a random guy from Reddit managed to make in a day or two.
Not to mention Ryzen is here since 2017... talk about lazy.
They make two releases a year, March and September. Not every company panic blows a truckload of patches every week.
 
They make two releases a year, March and September. Not every company panic blows a truckload of patches every week.
That's not an excuse for a simple change on so expensive software.
 
They make two releases a year, March and September. Not every company panic blows a truckload of patches every week.
Lol a panic patch... It's a simple bug fix that has less than 10 lines of code.
The issue has been present since the launch of Zen 1. So your "every week" has actually been 3 years.
 
So, if someone with an AMD processor, who payed for the program, comes out and say
"Because of what they did, I lost X time that translates to Y money that is way much more than what Matlab costs. So from here on I am going to pitrate this software until I cover up my loses".
How much wrong would he be?
 
So, if someone with an AMD processor, who payed for the program, comes out and say
"Because of what they did, I lost X time that translates to Y money that is way much more than what Matlab costs. So from here on I am going to pitrate this software until I cover up my loses".
How much wrong would he be?
Legally? Very.
 
Legally? Very.
Legally will always be wrong. I was thinking about ethically. A company deliberately(?) chooses(?) to not fix an easy bug that slows performance in very specific hardware. This is probably not legally wrong, but ethically?
 
Legally will always be wrong. I was thinking about ethically. A company deliberately(?) chooses(?) to not fix an easy bug that slows performance in very specific hardware. This is probably not legally wrong, but ethically?

Technically, it's like inserting a rod in a rotating wheel, so that it helps to stop the progress.

This is exactly why Intel is a so dislikable corp. Meh!
 
Lol a panic patch... It's a simple bug fix that has less than 10 lines of code.
The issue has been present since the launch of Zen 1. So your "every week" has actually been 3 years.

Maybe this is them panicking!

They can't stay behind now that Ryzen is gaining market share. You can bet that is why they just had to release now :) Yesterday we could read about a certain 4900HS CPU.
 
They make two releases a year, March and September. Not every company panic blows a truckload of patches every week.
Lol a panic patch... It's a simple bug fix that has less than 10 lines of code.
The issue has been present since the launch of Zen 1. So your "every week" has actually been 3 years.

Yeah, hotfixes has been a thing for a really long time.
 
Yeah, hotfixes has been a thing for a really long time.
Hotfixes for regular software like Chrome? Push one update every day no problem. Hotfixes for Nuclear Reactors? Make sure they check every damn interaction before pushing the updates through. This one lies somewhere in between, I think they are likely to err towards the side of caution. Laziness probably played a big part, along with prioritization.
 
Hotfixes for regular software like Chrome? Push one update every day no problem. Hotfixes for Nuclear Reactors? Make sure they check every damn interaction before pushing the updates through. This one lies somewhere in between, I think they are likely to err towards the side of caution. Laziness probably played a big part, along with prioritization.
I agree to all of that except one thing. This updates you mentioned are released by the company which made the application. In case of MATLAB a random guy made a tweak to avoid Genuine Intel CPU recognition or simply fools the software engine to recognize AMD CPU as Intel's.
 
I agree to all of that except one thing. This updates you mentioned are released by the company which made the application. In case of MATLAB a random guy made a tweak to avoid Genuine Intel CPU recognition or simply fools the software engine to recognize AMD CPU as Intel's.

Mr Random guy probably didn't check all interactions before pushing his spoof through.
 
Mr Random guy probably didn't check all interactions before pushing his spoof through.
If you take it as a spoof fine but it actually works.
 
If you take it as a spoof fine but it actually works.
This is not how enterprise production software is made. Matlab is not a game.
They release twice a year. Testing probably takes a month.
 
This is not how enterprise production software is made. Matlab is not a game.
They release twice a year. Testing probably takes a month.
Who said it's a game? That's not the issue here. The update wasn't done by the company. There is no update but instead a random guy made a tweak in the software.
Did you even read OP's post?
 
Who said it's a game? That's not the issue here. The update wasn't done by the company. There is no update but instead a random guy made a tweak in the software.
Did you even read OP's post?
I try not to spend much time reading his posts.
Have you checked the ExtremeTech source he linked (thankfully)?

"A random guy" provided a workaround few months ago.

The reason we're discussing this today is that Matlab 2020a now runs AVX2 on AMD CPUs. So yes, it's an update made by MathWorks.
 
An update which could have easily come a year, heck 2 years back but of course for reasons $$$ :rolleyes:
 
So how much was Intel paying them?
As much as I dislike Intel, it's not their fault. Intel developed the MKL, so they made it fallback on non-Intel CPUs. They didn't have to test it on competitor's CPUs and enable the AVX2 mode.
It's entirely the software company that makes Matlab. "Yeah we know our laziness is bad for you, just wait for next release cycle."
 
I try not to spend much time reading his posts.
Have you checked the ExtremeTech source he linked (thankfully)?

"A random guy" provided a workaround few months ago.

The reason we're discussing this today is that Matlab 2020a now runs AVX2 on AMD CPUs. So yes, it's an update made by MathWorks.
You just joined in the conversation. Now it works and has been proven. I'll focus on that.
You could have shared the source link though.
What extremetech mentions is they have covered the topic that MatLab didn't run the the workloads with fools speed few months ago not that the tweak was found.
Here's the link BTW: https://www.extremetech.com/computi...nger-matlab-2020a-runs-amd-cpus-at-full-speed
The article came out yesterday mentioning "the guy". I didn't find anything that he had done it months ago.
 
An update which could have easily come a year, heck 2 years back but of course for reasons $$$ :rolleyes:
Every fix ever done could have happened earlier. The whole point of fixing issues is that someone has to notice the issue first.
For better part of a decade no one used AMD CPUs for Matlab. Simple as that.

Ad BTW: keep that in mind next time you'll write a post about how great ARM is and how easy it will be to migrate form x86.
 
Weird you're making it sound as if Intel & AMD both don't use the same x86-64 ISA, as for the ARM port you must find where exactly I said it was easy? I simply said for those, like major enterprises or Apple, switching is relatively easy because they mostly have the resources & the knowhow to make it work, not for consumers in the retail space though. So no I've never said porting or switching or migrating is easy, I've always said that ARM (ISA) isn't inherently inferior because forum dwellers say so.
 
Back
Top