Overclock.net banner
1 - 7 of 7 Posts

paulerxx

· Gamer
Joined
·
3,684 Posts
Discussion starter · #1 ·
https://www.extremetech.com/computi...h.com/computing/302650-how-to-bypass-matlab-cripple-amd-ryzen-threadripper-cpus


"When I published Matlab data in our Threadripper 3970X / Cascade Lake X joint review, it was because Intel had recommended this test and workload as a showcase for Intel’s HEDT desktop line. I specifically asked for recommendations, hoping that Intel would have some applications in mind that would show relatively light scaling at or above the 18-core mark with AVX-512 integration. Even professional apps don’t scale perfectly forever, and I knew going into this review that there was going to be a performance “island” for Intel to stand on at the intersection of higher clocks and lightly threaded applications. “Lightly,” in this context, should be understood to mean “apps that don’t scale all the way to 64 threads” as opposed to “apps that don’t scale past 4-8 threads,” which is usually what we mean when we call an app lightly threaded. It was obvious that Threadripper 3960X and 3970X were going to beat the 10980XE in every app that could scale to match their thread counts, especially in the 3970X’s case. With that as a given, it was worth exploring the areas that had historically been the strongest for Intel to see how performance would compare."

"Matlab runs notoriously slow on AMD CPUs for operations that use the Intel Math Kernel Library (MKL). This is because the Intel MKL uses a discriminative CPU Dispatcher that does not use efficient codepath according to SIMD support by the CPU, but based on the result of a vendor string query. If the CPU is from AMD, the MKL does not use SSE3-SSE4 or AVX1/2 extensions but falls back to SSE1 no matter whether the AMD CPU supports more efficient SIMD extensions like AVX2 or not."
 
Dev being paid to include "accidental" oversight? :D


Also, wrong title.
 
Just more proof in how Intel is using their influence (wallet) to skew results in their favor.


I get it, it's not like someone else (AMD) couldn't do it and probrably has before.
Intel has been accused of this for years and in many cases it's proven as fact such as this example, crippling software compilers in their favor by having software writers/programmers pull such trickery in their stead with nice incentives to do so, straight from their pocketbook.
 
https://www.extremetech.com/computi...h.com/computing/302650-how-to-bypass-matlab-cripple-amd-ryzen-threadripper-cpus


.....This is because the Intel MKL uses a discriminative CPU Dispatcher that does not use efficient codepath according to SIMD support by the CPU, but based on the result of a vendor string query. If the CPU is from AMD, the MKL does not use SSE3-SSE4 or AVX1/2 extensions but falls back to SSE1 no matter whether the AMD CPU supports more efficient SIMD extensions like AVX2 or not."
Wasn't this attempted by Intel previously (way back in the K7/K8 days if i recall) with their compilers? I thought they had agreed as part of a settlement (with SEC???) never to engage in such monopolistic tactics again.
 
Wasn't this attempted by Intel previously (way back in the K7/K8 days if i recall) with their compilers? I thought they had agreed as part of a settlement (with SEC???) never to engage in such monopolistic tactics again.
Its Intel, they always and will always engage in such behaviors when they're on the losing end of the market. It's a story as old as x86 itself :)
 
Yes intel has been doing this forever. Who else remembers the $135 million fines they paid after AMD sued them, and how we had to run the ICC Patch on every program for many years to catch just this trickery. In fact this should be illegal.


Anyone want to try this ICC Patch and see if it catches this?
 

Attachments

1 - 7 of 7 Posts