A few months ago, we covered how Mathwork’s Matlab software didn’t run workloads on AMD CPUs at full speed. These products use the Intel Math Kernel Library, which will only run fully optimized code on Intel CPUs. AMD CPUs were shunted into using a different and much slower code path. Despite widespread speculation from the community that MathWorks might either be unable or unwilling to patch the issue, the company has surprised us all and fixed it.

According to NedFlanders1976 (the same individual who made the original Reddit report), MathWorks has incorporated a permanent path fix into Matlab 2020a, the latest version of its application. Essentially, Matlab now always starts in a mode that allows it to run AVX2 code on AMD CPUs. Previously, you could only force this capability by creating a System Environment Variable or a special batch file to launch the program.

Kudos to Matlab

I’d like to acknowledge and thank MathWorks for being willing to resolve this issue and for doing so quickly. I’ve had a number of conversations on this topic with my colleague David Cardinal, who has more experience than I do with the software development side of things. One of the points he made in our discussions is that these sorts of situations play out very differently from the software developer’s perspective.

Individual developers may not be aware that the Intel MKL doesn’t execute AVX2 code on non-Intel CPUs. Even if developers do know, many applications have user bases that are almost entirely Intel-based. If 90-99 percent of your customers own Intel hardware to begin with, the AVX2 codepath issue isn’t going to look very pressing. Working with Intel to maximize performance on an application with a user base that has chosen to buy Intel processors doesn’t necessarily look unfair from the software developer’s perspective. The low performance of AMD’s Bulldozer-derived CPUs made these questions moot until the launch of Ryzen, and just because AMD launched Ryzen in 2017 doesn’t mean everyone running Matlab instantly ran out and bought one.

Given that developers may not be aware of the impact of these issues, I think it’s only fair to judge them by how they address the problem rather than by assuming immediate bad faith just because the issue exists. Evaluated by these criteria, MathWorks’ response is excellent — the company fixed the issue in the next major application update. While NedFlanders1976 notes that “If you use other software including the MKL, e.g. Anaconda, SymPy, etc. along with Matlab, you actually might want to keep that system-wide variable as the new fix only applies to Matlab,” but he states that Matlab itself has been updated appropriately. MathWorks also confirmed the update to ExtremeTech in a separate discussion, even though the fix is not listed in the Matlab 2020a release notes.

There aren’t that many applications that rely on Intel’s compiler or libraries in this manner, but it’s encouraging to see MathWorks react this quickly to guarantee best performance on both Intel and AMD hardware. There’s nothing wrong with using an Intel-optimized library, but if companies are going to do so, they ought to inform their users that they do so, allowing customers to buy the best hardware for the task. Ideally, they would also work with other CPU vendors to offer optimized code paths for their architectures or take action to allow AVX2 code to run unimpeded on CPUs that support it. MathWorks has opted for this last approach and we hope other vendors in similar situations either follow its example or release alternately-optimized code paths that don’t rely on the Intel MKL when running on an AMD CPU if a different library would produce faster results.

Now Read: