인텔이 자사의 Math Kernel Library 라는 라이브러리가 오직 인텔에서만 최적화 되어 돌아가고,

인텔 프로세서가 아닌 프로세서가 감지되면 최적화된 버전이 아닌 느린 루틴으로 작동되도록 한 것이

Puget Systems 에서 비공개 Parameter 를 수정해서 AMD 프로세서에서 MKL 을 가속하는 것을 소개함으로써

어느정도 윤곽이 드러난 것 같습니다.

( https://www.pugetsystems.com/labs/hpc/How-To-Use-MKL-with-AMD-Ryzen-and-Threadripper-CPU-s-Effectively-for-Python-Numpy-And-Other-Applications-1637/ )

Parameter 를 수정해서 AMD 프로세서를 가속시켜도 아직은 코어 수 대비해서는 인텔 프로세서가 더 빠르게 작동하긴 하지만

엄청나게 느렸던 AMD 프로세서들이 Parameter 하나 수정했다고 몇배나 빨라지는 기적을 볼 수 있습니다.

AMD 프로세서 유저들 중에 MATLAB 쓰시는 분들 있으시면 위 링크 타고 들어가셔서 얼마나 빨라지는지 시험해 볼 수 있습니다.

사실 이 문제는 reddit 유저들의 지적에 따르면 이미 9년 전에 FTC 에서 조사를 하고

( https://www.reddit.com/r/Amd/comments/e4klj0/intel_is_still_sneakily_sabotaging_amd/?st=k3oi9wa0&sh=77c60259  )

인텔에게 타사 프로세서에서 의도적으로 느리게 작동하는 코드를 만들었다면 소프트웨어에 어떤 짓(?)을 했는지

공개하도록 명령 ( https://www.ftc.gov/sites/default/files/documents/cases/101102inteldo.pdf  )을 했습니다만,

인텔은 그 명령을 회피하여서 최신의 명령어셋을 쓰는/쓰지않는 두 루틴을 선택적으로 적용하게 하고

자사 프로세서에서만 최신의 명령어셋을 사용하는 방법으로 FTC 의 명령을 우회한 것으로 보입니다.

(아마도 인텔의 의도는, "우리가 의도적으로 느리게 한건 아닌데, 타사 프로세서가

최신 명령어셋을 쓰는지 우리는 알바 없으니 그냥 호환성 높은 레가시 루틴으로 돌아가게 만들었어"

이런 논리인듯 싶네요.)

아무튼 High Performance Computing 쪽에서는 오랜기간 동안 AMD 프로세서가 인텔에 비해 심각하게 느린 문제 때문에

그리고 심지어 HPC 를 제외한 다른 거의모든 상황에서 인텔보다 뛰어난 Threadripper 3 에서조차

HPC 연산에서는 인텔 프로세서보다 심각하게 느린 성능을 보이는 이 비정상적인 상황이

Puget Systems에 의하면 인텔의 권리라 합니다.

이미 FTC 에서 판결을 내린 부분도 그렇게 하지마라가 아니라 그렇게 했으면 무슨 짓을 했는지 공개해라 정도이니

법적으로도 인텔이 자사 프로세서에서만 유리하게 작동하도록 만들 권리가 있는 것이죠.

아무튼 이런 점들 때문에 아마 대다수의 HPC 업계에서는 아직도 인텔 프로세서만 사용을 할텐데,

Open source 대안이 어서빨리 잘 개발되고 대중화되어서 많은 HPC 소프트웨어들이 채용을 해 주면 좋겠습니다.

여전히 OpenBLAS 같은 오픈소스 대안은 상용 라이브러리들에 비해 성능이 많이 부족합니다.

아니면 인텔의 MKL 에 비하면 성능이 떨어지지만 AMD 의 BLIS 를 이용해서 소프트웨어를 컴파일 해 주도록

소프트웨어 제조사들에게 요구하는 것도 하나의 대안이 될 수 있겠죠.

(십수년간의 경험을 토대로 볼 때 상용 소프트웨어 제조사들은 절대로 안해줄겁니다...

아예 우리 소프트웨어는 Intel Xeon 에서 풀 성능을 발휘한다고 대놓고 광고도 할 정도니... 가능성이 거의 없죠...)

저도 어쩔수없이 인텔 프로세서만 사용할 수밖에 없는 1인으로서, 이것만 해결된다면 AMD 프로세서도 한번 써 보고 싶네요.