인텔이 자사의 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 프로세서도 한번 써 보고 싶네요.
좋은 정보 감사드립니다.
제가 본문 쓰면서 설명충이 될거 같아서 일부러 새소게에 안쓰고 모공에 쓴건데...
스퀴니님께서 핵심만 짧게 새소게에 올려주셨네요.
추텔아, 인하다...
Paul's iPhone 11 Pro with Clienkit
인텔이 CPU 패키지안에 MKL을 포함해서 판매한 것도 아니고 경쟁회사가 MKL과 유사한 것을 상업적으로 배포한 것도 아니고, 끼워팔기 금지조항에 걸린다는 것은 억지죠.
오래 전 기억을 되살려 보면 OS에 브라우저,메신저,미디어플레이어를 "무료로 선탑재"해서 해당 조항에 걸린 MS에 조치된 판결이, "구분된 버전 판매(K,KN)", "별도 다운로드 하도록 제공" 이었음을 상기해보면, 인텔은 애초에 그렇게 하고 있는 상황인데요...
그런식이면 자사 기기에만 동작하는 무료SW를 제공하는 수많은 모바일 기기와 게임 콘솔 등의 기기는 대체 어떻게 하란 말입니까. 타사 HW까지 완벽한 동작을 보증해야 하면요...
그런다고 엔비디아가 욕먹은 적은 없죠. 지원 및 최적화가 부족한 ati/amd가 질타를 받으면 받았죠.
amd도 자사 최적화 라이브러리 개발하고 소프트 제작사가 채택하도록 협력 및 지원 관계 열심히 구축하는게 우선이지 않나 싶습니다
게임에선 대놓고 엔비디아가 지원해줌! 하면서 게임킬때부터 제작사 로고, NVIDIA로고 띄워주고 시작하는 경우도 있지요.
인텔은 그 짖거리를 사용자가 모르게 몰래 했다는 것이고요..
인텔호환 명령어셋에 대한 지원은 인텔에 무임승차하고 있는 것 아닌가요?
인텔 입장에선 자신들의 라이브러리를 아예 인텔씨퓨에서만 돌게 할 수도 있을텐데.. 돌려는 주잖아요.
AMD CPU에서는 64비트로 돌고 인텔CPU에서는 검증이 안되었다는 이유로 32비트로 작동하게 하는 어플리케이션을 AMD에서 만들었다고 하면 이해가 되시나요?
X86-64는 양사 간에 크로스라이선스로 되어있대요.
이게 사실 제일 문제 같아요.
안돌아 가는게 아니고. 느리게 돌아간다.
아이폰도 그러지 않았었나요?
오래쓰면 느리게 돌아간다.
인텔은 오래안써도. Amd 꺼쓰면 느리게 돈다 니까요 .
다른가요?
인텔칩에서 성능이 좋은 최신 코드가 과연 AMD칩에서 문제 없이 돌아갈 거냐라는 문제인데..
이 부분을 책임지기 어려우니 성능이 낮은 대신 호환성이 높은 코드를 썻다는 것 이잖아요?
인텔칩이야 자사의 칩이니 최신코드가 잘 돌아가도록 책임지고 개발하겠지만 다른 칩은 그러지 못하지 않앗을까 라는 생각이 드네요
라이브러리에서 어떤 인스트럭션 셋을 쓸지는 그 라이브러리를 이용해서 소프트웨어를 개발하는 개발자가 정해도 됩니다.
그런데 그걸 인텔이 의도적으로 자사 프로세서에서만 최신 인스트럭션을 쓰게 막아버린거죠.
인텔 MKL 이 시장에서 지배적인 소프트웨어들에 거의 독점적으로 사용되다보니,
저는 일정부분 그 독점적 지위를 이용한 횡포라고 보고 있습니다.
> 문제는 저게 라이브러리라는 겁니다.
라이브러리라 문제가 없어보입니다.
>라이브러리에서 어떤 인스트럭션 셋을 쓸지는 그 라이브러리를 이용해서 소프트웨어를 개발하는 개발자가 정해도 됩니다.
라이브러리(or SDK)로 제공되는데, 사용자(개발자)에게 어떤 instruction set을 선택하게 해주는 library는 (만들수는 있지만) 잘 없지요. 그냥 어떤 function이 최적화 루틴과 비효율적인 루틴이 두개 있다고 생각하면, 이런 모든 라이브러리가 비슷하다고 생각하시면 됩니다. 어떻게 두개를 선택하는 로직을 독과점에 안걸릴 정도로 자사에 유리하게 적용하는 practice 는 비판받아 마땅합니다만.
애초에 라이선스를 intel전용으로 제한하든지 하면 됐을텐데.. 이런식이라면 고객들에게 인텔 제품이 우월하다는 잘못된 인식을 주기위한 사기에 가까운 행위 같은데요
기능이나 성능이란 건 당장 얼마나 퍼포먼스가 나오느냐가 아니라
다른 탈 없이 고르게 안정적으로 쓸 수 있는 지 확인되느냐가 문제이니까요.
인텔에서 개발한다면 AMD에서까지 이러저러하게 잘 되는지 모두 확인 검토하고 보완하느니,
그냥 적당한 수준에서 마무리했었겠죠.
개발사들에게 제공되는 라이브러리인데, 라이브러리단에서 막아버리니 문제가 된다고 봅니다.
이거 하는 물리학자, 화학자, 재료공학자들이 리눅스 프로그래머도 아니고, 컴파일 익숙하지 않은 AOCC를 쓰기도 힘들고 제대로 쓴다 해도 ICC보다 성능도 안나오고, GCC나 GFC는... PGI 컴파일러는 안써봐서 모르겠네요. 예전 KISTI에서 옵테론 시스템 사용할 때 썼다는데요.
edu 이메일 사용 시 1년간 무료 사용 가능한 점, 컴파일 쉬운 점은 너무 좋고 인텔이 만든 컴파일러니 당연히 AMD CPU에 대한 최적화를 해 줄 이유는 없지만 그래도 고의적으로 속도 제한을 하는건 좀 치사해 보이긴 하네요.
윈도우에서 돌리는 ABAQUS나 COMSOL 같은 FEM 계산이면 몰라도, 리눅스에서 ICC/IFC/MKL 이용한 계산과학들, 대표적으로 대부분의 슈퍼컴퓨터 리소스 사용량에서 큰 비중을 가지는 제일원리 계산에서는 인텔을 쓸 수 밖에 없습니다.
cpu 본연에 대한 연구개발보다 이런
앝은수를 쓰면서 경쟁사와의 격차를 유지하려했으니
하스웰은 현재 6년차로 비슷한 겝입니다. 넘어오시죠 ㅎㅎ
AMD도 SW에 투자를 많이했으면 좋겠어요.
그리고 AMD BLIS에서 인텔의 MKL만큼 잘 돌아간다면, 소비자는 소프트웨어 개발자에게 AMD에서 작동하게끔 해달라고 요구했을 겁니다.
그걸 알고서 인텔은 일부러 돌아는 가되, 느리게 돌아가게끔 만들어둔거겠죠. 소프트웨어 개발자는 돌아가기만 하면 더 이상 손을 안댈거라는 걸 예상하고서요.
그렇게 보면 작동 안하게 막아놓은 것보다 더 악질 아닌가요.
이미 FTC 에서 판결을 내린 부분도 그렇게 하지마라가 아니라 그렇게 했으면 무슨 짓을 했는지 공개해라 정도이니
법적으로도 인텔이 자사 프로세서에서만 유리하게 작동하도록 만들 권리가 있는 것이죠.
---
본문에 적으셨듯 저게 공개소프트웨어거나 계약하고 제공하는게 아니면 맞는 말이라고 생각합니다. 자기들이 몇년에 걸쳐 개발한 것을 다른 회사에 쓰라고 넘겨줄 회사가 얼마나 있는지도 궁금하네요. 너네가 만들어써야지 왜 우리껄 쓰냐가 정상아닌가요. 인텔입장에선 거의 10년전부터 성능차이를 느꼈으면 자체 커널을 개발해라라고 해도 암드는 할말없는 입장입니다
물론 제3자입장에선 주고도 욕먹을 케이스니 좋게 안보이긴하지만 한편으론 1:1 맞다이판인데 편의봐줄이유도 없는것도 사실이죠
x86 호환 프로세서가 AMD만 있는 것도 아니고
그 AMD도 하드웨어 별로 명령어 셋이 다른데 일일이 최적화할 수 없습니다. 이건 AMD 몫이죠.
타 프로세서도 인텔 코드 돌리게 하면 하드웨어 익셉션 뜰 확률이 매우 높아지는데 저렇게 리거시 코드라도 넣어주는게 다행인거죠.
왜냐면, 인텔 CPU의 역사가 길고 시간이 지나면서 명령어 셋이 계속 추가되어 왔습니다. 즉, MKL도 내부적으로 각 세대별 cpu마다 지원되는 명령어셋들을 구분하면서도 동작하고 있을 거라는 거죠. 안그러면 지금과 달리 ,MKL버전별로 사용가능한 intel cpu세대가 정확하게 지정되어야 할 겁니다.
그말은 뒤집어 보자면, AMD - Intel간에 크로스라이센싱된 마이크로익스트럭션 셋에 대해서는 MKL에서 돌아가도록 할 수 있었을 거라는 거죠. 그리고 공정함과 선의라는 관점에서 보자면 소비자/사용자들입장에서는 그런 페어함을 기대하는게 당연한 거죠. AMD의 전용 명령어셋까지 지원해주는 초-대인배적인 것 까진안바랍니다만, intel이 cpu를 만들면서 AMD와 경쟁한다면, 우리는 CPU설계과 성능으로 차별화를 통해 인텔이 경쟁하기를 바라는 거죠. 이런 수법이 아니라요.
물론 법적의무는 없겠습니다만, 도의적으로, 그리고 저 MKL이 공익적인 과학기술계산에 많이 쓰이는 용도 아무래도 그런 공익적인 의도를 바랍니다. 물론 선택은 인텔의 몫이고 비난or칭찬도 인텔의 몫이겠지만요.
우리나라는 지적재산권에 대한 소유 개념, 특히 소프트웨어 알고리즘에 대한 소유 개념이 없긴 합니다. 인텔 개발물을 AMD에도 동작하도록 개발하라는 것은 사비로 강남에 호텔 지어 공공으로 무료 개방하자는 말과 같은 말입니다.
AMD가 돈 써서 개발하면 됩니다.
물론 AMD는 태생부터가 인텔에 빌붙는 존재라 그간 전혀 투자한 적이 없습니다.
저런 식으로 동작시키는 것도 인텔이 개발한 결과물을 AMD가 훔쳐다 쓰는 행위죠.
욕 먹어야 할 대상은 AMD입니다.
아래쪽에 별도 댓글 남겼습니다만, 인텔은 공공기관이 아닙니다.
저는 계약되지 않은 내용을 intel이 AMD에 제공하라고 한 것이 아닙니다. AMD CPU를 사용하는 소비자/사용자를 고려해서 intel이 자사의 instruction set중 AMD에도 제공된 것 정도는 MKL에서 사용할 수 있게 해서 성능을 제대로 내줄 수 있도록 하는 것이 도의적으로 좋다고 한 것이지요. 그리고 도의적인 그런 기대에 intel이 하는 선택에 따라칭송을 받을 수도 비난을 받을 수도 있겠다고 했습니다.
하지만 님께서는, 사람마다 가진 사상이 다르고, 생각이 다르고, 이데올로기가 다르니 이견이 있을 수는 있고, 토론이나 논쟁이 벌어질 수도 있습니다만, 다소 과하게 오버하시는 것 같습니다.
일단 AMD가 intel에 무슨 무임승차를 했다는 말씀입니까? AMD가 인텔에 줘야되는 돈 안준 게 있습니까? 한 95년부터 IT분야쪽 잡지나 기사를 띄엄띄엄 읽어오긴 해서 다 기억은 못하겠습니다만, 법적분쟁이 있었을 수는 있겠으나 그래서 판결난 돈 AMD가 intel에 줘야되는 데 안준게 있는 지는 기억이 안나는 군요. 있다면 기사를 찾아주시면 좋겠습니다. 근거 없는 비방은 적절하지 않겠지요.
그리고 훔쳤다니요? 훔쳤다는 것은 정당한 권리가 없는 것을 임의로 가져와서 사용할 때 할 소리입니다. AMD가 intel MKL 훔치기라도 했습니까? 무슨 근거와 어떤 판단로직으로 훔쳤다고 하시는 건가요? AMD가 MKL소스 훔치는 시도라도 했다는 기사나 증거자료 보신적 있으신겁니까?
p.s
그리고 우리나라에 지적재산권 개념이 없다는 근거는 무엇입니까? 이견이 있기는 할 지언정, 한국에도 지적재산권 개념있습니다. 게다가 더욱 불합리하게 보이는 말씀은, Intel, AMD는 한국회사들이 아니고 북미쪽이 다들 본사일텐데, 미국에서 지적재산권개념이 없어서 사람들이나 법원들이 intel편 안들고 AMD손들어주고 있는 것 같습니까? 언급되지 않았고, 끌어올 필요도 없는 이야기를 구태여 가져와서 논점 흐트리는 일은 줄이는 게 좋겠습니다.
그리고 저는 논쟁거리가 된다고 생각합니다.
AMD 에도 BLIS 라이브러리가 엄연히 존재합니다
그런데 인텔이 cpu 시장에서 특히 HPC 시장에서 100% 에 가까운 독점적 지위에 있다보니
소프트웨어 만드는 다른 회사들이 다 인텔것만 갖다가 사용하고
그게 그 인텔의 독점을 더 공고하게 만드는게 문제입니다
그래서 제가 독점적 지위의 남용이라 보고 있는 이유입니다
타사 프로세서도 같은 인스트럭션 셋을 가지고 있는데
자사 프로세서에서만 그걸 활용하겠다는게 법적으로 문제가 있는 행동은 아니지만
필요없는 제한을 함으로써 그 독점을 더 강화하는거니까요
글쎄요.
CUDA가 라데온에서 안돌아가면 그게 엔비디아 책임입니까? (실제로 안돌아가죠?)
돌아가는게 감지덕지한거죠.
AMD는 무임승차 할 생각하지 말고 소프트웨어 역량을 강화해야 됩니다.
인텔도 스펙격차가 더 심화되면 자신만의 심화 명령어셋만 가능하도록 수정해버릴 수도 있겠죠.
지원안되는 명령어 cpu에서는 아얘 구동도 안되버리게요.
그걸 못하게 막을 수 있겠습니까?
어느정도는 이해할 수도 있습니다만
저렇게 까지 하는건 좀 치사한 느낌이 들긴 하네요
하드웨어단 지원이나 최적화와는 아무런 상관이 없나보네요. 그냥 인텔이 졸렬하다는 생각밖에..
애초에 내 독점 라이브러리니까 사용하지마! 면 아무 문제가 없는건데, 마치 amd cpu가 성능상 매우 딸려보이게 만듬으로써 amd 쪽 브랜드에 상처를 냈으니까요.
만약 그것이 불만이면 직접 만들어 쓰면 됩니다.
파라미터를 수정해서 성능 향상을 이뤘다는 것을 보면 소스는 공개 되어 있으니, 필요한 부분만 알아서 수정해서 쓰면 될 일이지 공개한 intel을 비난 할 것은 아니라고 보여지네요.
반대 급부로 AMD는 왜 저런 라이브러리를 공급하지 못 했는지도 이야기 한다면 오히려 쓸 수 있게 만들어 준 intel을 비난하면 안된다고 생각합니다.
그런데 MKL소스는 공개되어 있지 않습니다. 소스없이 이걸 찾은 사람은 대단하고요.
AMD에서 느리게 돌아가긱 위한 꼼수는 이전에 부렸고, 명령어 셋을 변경 했다는 말은 본문에도 있습니다. 최신 명령어 셋을 AMD가 지원하지 않는다고 하여 intel이 그 부분 까지 지원해야 할 의무가 있는지 여쭤 보고 싶네요.
시장 논리에서 기능성 차이점을 두는 건 꼼수가 아니라 경쟁력이라고도 표현 됩니다. 만약 그런 경쟁력이 필요로 한다면 AMD도 라이브러리를 배포 하거나, 라이센스 공유라면 수정을 요청 했어야지요. AMD 사용자는 intel에게 항의 할 게 아니라 AMD에게 하는게 옳은 방향 아닐까요?
충분히 지원하는 명령어임에도 불구하고 의도적으로 해당 명령어를 쓰지 않도록 배제한겁니다
당연히 intel CPU에서 잘 처리 되도록 프로그램을 짜 놓았다면, 그걸 AMD용 까지 맞춰 프로그래밍 해줘야 할 의무가 있을까요?
intel 프로그래머가 AMD에 돈 받고 일 한 건 아닌 듯 한데요...
저거는 의도적으로 AMD인 경우 해당 명령어를 쓰지 않도록 예외처리 시킨겁니다. 오히려 비용이 더 발생하는 방법이죠
추가적인 비용 발생은 무임승차한 AMD가 부담해야죠
의도적이든 아니든 intel은 intel 입장이지 경쟁자를 위해 혜자처럼 굴 필요가 없어 보입니다
사용자에게 불편함을 안긴건 태업인 AMD에 있다고 봅니다
그 비용이 intel에서 발생하나요?
cpu 사용자와 제조사를 분리해서 봐야 하지 않을까요?
그건 intel 주주가 아니면 고민 할 필요가 없어 보입니다
그리고 최적화 명령어 셋으로 개발 하는건지 아닌지는 intell만 아는거죠
AMD 유저라면 태업인 AMD를 욕해야 하지 않을까요?
그래픽카드 벤치 보시면 AMD 협업 들어간거 몇 가지는 nVidia 바르는데, 나머지는 숨도 못 쉬죠.
게임 뿐입니까. 램도 넉넉하고 GPGPU에 유용한 하드웨어 두고 개발자 커뮤니티 전혀 신경 안 쓴 결과 nVidia CUDA가 시장의 대세가 되었죠. 이제와서 RadeonOpenCompute라고 비슷한거 지원하면서 HIP라고 CUDA 트랜스파일러 만들어놨는데 현상태로는 쓰레기입니다.
CPU도 인텔 컴파일러로 컴파일된 코드가 인텔이 아닌 CPU에서 성능을 떨군다는 얘기 나온지가 10년은 된거 같은데 관련 투자는 없었죠.
윈도우 스케줄러 문제로 라이젠이 성능문제를 1년 넘게 갖고 있었는데, 그걸 개발단계에서 모른건지 출시하고 나면 마소가 고칠거라고 생각하고 손 놓고 있었던건지 이해가 안됩니다.
그래도 스펙터대는 자기는 상관 없다고 커널코드 바로 수정하긴 하더군요 ㅋ
자사 하드웨어는 본인들이 제일 잘 압니다. 지자식 지가 키워야지 AMD는 SW 면에서는 인텔에 무임승차 하고 있는 수준이라 할 말이 없죠.
AMD에 따져서 AMD가 자사 CPU의 성능 뽕을 뽑을 수 있고 intel CPU는 시궁창 성능이 나오는 같은 기능의 라이브르리를 만들면.
양사가 소프트웨어 업체에 지사 라이브러리만 써 주세요 식의 로비를 하기 시작할테고 결과물로 나오는 소프트웨어도 CPU 골라가면서 사야하는 시궁창 스러운 상황이 될것 같은데요..
본문 논조가 애매한데 타사를 느리게 하는게 아니라 자사를 빠르게 하는거라 소비자는 어쨌든 좋은겁니다.
본문은 논조가 애매한게 아니라 본문의 내용은 아무리 봐도
타사를 느리게 하는건데요..
AMD64를 위한 라이브러리라고 공계하지만 amd64중 AVX를 지원한다고 보고하는 CPU 가 있을때 AVX를 사용하는 루틴을 돌리는 대신
일부러 CPU이름을 확인해서 AMD의 AMD64프로세서는 AVX를 쓰지 않는 루틴을 돌리고 인텔의 AMD64 프로세서는 avx를 쓰는 루틴을 돌린다는건 아무리 봐도 남의것을 느리게 만들려는 의지가 있다고 밖에는 볼 수 없는거 아닌가요?
애초에 AVX 자체가 인텔이 추가한건데..
음 글쌔요...
내가 안풀면 아예 존재할 수 없는 내가 인스트럭션 셋을 공개하지 않은 하드웨어를 위한 독점 소프트웨어 같은거라면...
"일부러 상대방 기기의 기능을 재한하는 코드를 넣은 소프트웨어 = 내것만 빠르게 만든 것"
이 말씀이 맞는 말이겠지만..
AMD64는 하드웨어 최적화를 위한 자세한 사양이 공개되어 있으니..
KML이 없으면 소프트웨어 재조사에서 해당 기능을 자체 개발 했을태고..
그 경우 양자 모두 빠를 수도 있으므로..
"일부러 상대방 기기의 기능을 재한하는 코드를 넣은 소프트웨어 = 내것만 빠르게 만든 것"
라고 하기 힘들것 같은데요...
AVX가 에초에 인텔이 주창한 인스트럭션 셋이라는건 이건에서는 별 의미가 없는것 같고요..
만약에 AMD가 그래픽카드 주도권을 잡아서 그 점유율을 이용하려고
AMD 그리픽 카드 드라이버를 인텔 CPU에서는 32bit로만 작동하도록 만들었다면
욕먹을 일일까요 아닐까요?
x86 CPU들에 들어 있는 64bit 인스트럭션 셋은 에초에 AMD가 넣은거니까 괜찮은걸까요?
잘 모르셔서 그러나본데 이게 말이 안되는겁니다. 그게 되면 애초에 비싼 MKL 사서 안쓰죠.
어떤 관점에서 말이 않된다고 생각하시는지 의문인데요?
본문에도 언급하다 시피 비슷한 기능의 오픈소스 프로젝트도 존재하는데..
불가능하다고 단언할 수 있는 이유가 궁금합니다.
라이브러리를 사서 쓰는건 대부분의 경우 불가능해서가 아니라...
그 편이 비용이 훨씬 절약 되기 떄문입니다.
라이브러리 화 해서 판매하는쪽은 여러손님을 상대하므로 개발단가를 효율적으로 녹여넬수 있고.
인텔처럼 시장 주도권을 위해서 저런 조잡한 짓을 할 마음을 품고 있다면 적자를 보는 가격으로 뿌릴 수도 있죠.
그리고 intel KML은 현시점에는 상업이용도 무료 라이선스로 가능한것 같던데요?
그리고 라이브러리가 훨씬 절약된다는거 알고 계시는데 그런말을 하시나요? 결국 사실상 직접 만드는게 불가능한거고 그게 시장경제입니다. 빠르고 완성도 높은 라이브러리를 만들었는데, 대신에 자사에 최신 기능을 적극 활용하는 최적화를 했다. 문제될게 뭐 있나요?
적자를 보는 가격으로 뿌린다. 그게 결국 자사 하드웨어를 위한 소프트웨어 기반을 무료 제공하는겁니다. 판촉의 일환이에요. 삼성이 갤럭시 버즈를 만들고 애플이 이어팟을 만들었는데 자사 제품이랑 썼을때 성능이 더 좋다? 단순한 제품 장사가 아닌 생태계 장사가 된 요즘에 이게 아닌게 더 이상한거죠.
이것도 못하면 공산주의나 다를바 없습니다만
그걸 인텔이 대신 해준겁니다. 결국 없던 라이브러리가 그것도 고퀄리티로 생긴거고 어쨌든 AMD도 그 덕을 본거죠.
AMD는 x86 시장을 위해서 노력한게 거의 없습니다. 2등이었으니 굳이 그럴 필요가 없기도 했고요. 그런데 인텔은 무지 고생했어요. 테슬라 수퍼차저 같은 사업 모델이라고 생각하시는게 좋습니다
첫째로
대부분의 자본주의 국가에서도 그런 행위를 완전히 용인하지는 않는데 사회주의가 나오는건 좀 부적절합니다.
손해를 보면서 시장을 점유하고 그 점유율로 끼워팔기 같은걸 하는건 위법인 경우가 많습니다.
둘째로
라이브러리를 쓰면 돈을 절약할 수 있다.. 라는건 라이브러리를 쓰지 않으면 접근할 수 없는 기능이다 와는 전적으로 다른 이야기 입니다.
해당 라이브러리가 아니면 접근할 수 없는 기능이 아니라면 해당 기능을 삼자가 만들수 있습니다.
그것을 막고 있는것이 이미 적자를 보면서 팔아제끼고 있는 저렴한 퍼스트 파티 라이브러리 자체고요.
그렇다면 이것이 설령 옳은 일이라고 해도 마땅한 권리라고 해도
"일부러 상대방 기기의 기능을 재한하는 코드를 넣은 소프트웨어 = 내것만 빠르게 만든 것" 라는 말은 성립이 안된다는거죠...
시장 독점적인 지위를 확보하지 않았으면 시장성 있는 서드파티 라이브러리가 존재할 가능성이 높고..
그렇지 않더라도 소프트웨어 업체 인하우스에서 구현 했을수 있으니까요.
그리고 비난을 받는것은
자사의 최신기능을 적극 활용하는 최적화를 한것이 포인트가 아닙니다.
상대방 CPU를 추가적인 노력 없이 그냥 내버려 둔것과 비교했을때
1/4 성능이 나올정도로 의도적으로 저성능이 나오도록 오히려 추가적인 설정을 해서 빈축을 사고 있는거죠..
이것만으로도 비난 받을만 하지만..
이것이 AMD와 INTEL 당사자들만 만들수 있어서 외의 사람들이 아예 재작할 수 없는 기능이라면..
말씀하신 "일부러 상대방 기기의 기능을 재한하는 코드를 넣은 소프트웨어 = 내것만 빠르게 만든 것" 가 말은 된다는거죠. 자기 프로세서를 위한 라이브러리를 멀쩡하게 만들지 않은 AMD 탓이니까요..
그런데 그게 아니니까 말이 안된다는 겁니다.
x86 시장을 위해서 노력한게 거의 없다고 하기엔..
현제의 64bit x86 프로세서는... AMD가 밀어서 시장에 안착한 건데요.
인텔은 32bit를 끝으로 x86은 정리하고 아이테니엄으로 전환하려고 했었죠..
AMD는 우리 이런거 만들었다~! 쓸거면 써! 이 이상 나간적이 거의 없습니다. 전형적인 구식 하드웨어 회사에 머물러있어요. 요새 차차 나아지는 모습은 보입니다만..
그리고 아시겠지만 저런 최적화는 명령어 이외의 상세한 아키텍처까지 고려하기 때문에 제일 기본적인 코드를 두고 특정 프로세서 그룹에 대해선 이렇게 하고 다른 그룹은 다르게 하고 이런식으로 세세하게 이루어지지, 기본 AVX2 코드 바탕으로 미지원일 경우 무조건 Fall back 코드를 실행하는식으로 단순하지 않을겁니다. 즉, 화이트리스트에 있을 경우에만 최적화를 사용하죠.
프로세서 스펙 보고 비슷한 그룹에 AMD거를 넣어줄 수도 있지만, 굳이 그럴리가요
아키텍쳐만 구성했다 쓸테면 써가 아니라..
자기들이 그거 잘 팔아먹음으로서 x86의 64bit 버전이 존속가치가 있다는걸 시장에서 증명했죠.
그러지 않았으면 인텔은 예정대로 답도 없는 x86 버리고 새 아키텍쳐로 떠나서 그걸 PC에 밀어 붙였을태고
PC용 아이테니엄도 독보적인 지위를 향유했을겁니다.
즉 버려질 생태계를 억지로 살렸는데 한것이 없다고 하기는 무리가 있다는 거죠...
최적화에 대해서는
저 빈축을 사는게 AMD CPU에 대해서 자사에 준하는 수준으로 캐시용량 링버스인지 아닌지 l4가 있는지 없는지 캐시간의 속도차이가 어떤지 뭐 이런 잡다한 요소들 다다 고려해서 칼같은 최적화를 재공하지 않아서 욕을 먹는게 아니죠...
'debug cpu type = 5' 같은 분류는 아무리 봐도 품을 들여서 최적화 하거나 한 범주라고 생각할 수는 도저히 없는데.
그정도만 했다.... 한들 누가 욕을 했겠습니까?
일부러 ID 골라서 몽땅 옛날 옛적 인스트럭션 셋만 쓰는 수준으로 누가 봐도 악의적으로 분류 했으니까.. 빈축을 사는 거죠...
일단 오히려 인텔 내부에서 적어도 개발진들은 아이태니엄이 답도 없다고 보고 있었을 가능성이 큽니다. 아이태니엄은 출시하고 나서도 개발은 영 지지부진했고 아이러니하게도 AMD64 출시하고 바로 다음해 프레스캇인가에서 EMT64 추가해서 출시했었죠. 새로운 아키텍처가 1년만에 뚝딱 나오는건 아니니 결국 내부적으로 이미 개발을 하고 있었다는 뜻..
GCC 등의 개발에 적극저긍로 지원한 내역이 있는지 궁금한데 워낙 옛날이기도 하고 해서 잘 안나오는군요.
그리고 환경변수 설정으로 가능한건 AMD CPU를 인텔의 화이트리스트 CPU 그룹의 일부로 강제로 설정하기 때문인거죠. 블랙리스트로 AMD를 뺀게 아니라 화이트리스트로 인텔만 추가한거라고요.
최신 라이브러리를 거의 다 폼함한 범주에 5번이 붙었다면...
이게 아주 최적화를 위한 칼같은 기준으로 박박 나눠놓은 페러메터가 아닐것이라는 의미입니다.
디버그용으로 몇가지 뚫어 놓은 거겠죠.
딱 고정도 수준의 분류도 가하지 않고 싹다 몰아서 레거시 무리들이랑 같은 곳에 처 넣은건 다분히 의도적이라는 겁니다. VIA역시 장사를 안하는 상황인데 블렉리스트나 다를바가 없죠..
그리고 intel이 내부적으로 64bit 확장을 개발하고 있었다는게 AMD가 x86의 존속에 큰 기여를 했다는 사실에 배치되는 사항은 아닌것 같은데요..
출시 시기까지 1년간 AMD CPU에 대한 시장의 반응이 압박하지 않았다면 내부의 진척에도 불구하고 아이테니업에 힘을 실어주기 위해서 출시를 안했을 수 도 있다는점과...
인텔의 개발만 과거에서 부터 시작된게 아니라 AMD의 64비트 확장 역시 발표와 개발과정은 출시 시기보다 훨씬 이전에 진행이 되었을 것이고 그 정보또한 비밀이 아니였으므로 플렌 B를 만들도록 압박한 것일수도 있으니까요..
자꾸 오해하시는게 인텔은 자선단체가 아닙니다. AMD 분류를 안 한게 디폴트고 굳이 타사 제품까지 일일히 분류하는게 일부러 노력해야 가능한 일이죠. 그렇기에 일부러 뺐다가 아니라 굳이 넣지 않았다라고 봐야하는거고요.
AMD64는 20세기말에 나온 아키텍처입니다. 그리고 제가 처음부터 말씀드리는건 소프트웨어적으로 생태계를 유지하기 위해 AMD가 한게 있냐는거죠. AMD가 한 것은 새로운 아키텍처가 굳이 필요 없고 x86-64도 충분하다는걸 '하드웨어' 실체를 만듦으로써 보여준겁니다. 반박을 하고 싶으시면 64비트의 대중화를 위해 AMD 가 소프트웨어적인면에서 투자를 한 게 있는지를 말씀하셔야 대화가 성립하죠.
P4 같은경우 IA-64로 순식간에 완전 대체는 안되니 한동안은 투트랙이 필요했습니다. 그래서 x86도 꾸준히 유지해야 했고 거기에 EMT64도 넣은겁니다. x86만 있는 모델과 둘 다 있는 모델 이런식으로 하기에는 당시 인텔이 잘 나갈때인걸 감안해도 개발역량상 무리이지 싶네요.
자꾸 확대하시는데 자선단체 수준의 수고 하지 않아서 욕먹는게 아니지 않습니까?
라이젠 같은 엄청나게 큰 분류가 한뭉텅이로 들어가는 수준의 분류는 데이터 시트를 찾아서 일일이 어쩌고 운운할 정도라고 볼 수가 없다는게 '악의'를 느끼는 이유 인데요.
누가 그정도 수준의 최적화를 해 달라고 했나요? 아무도 없어요 아무도.
지원하는 명령어셋 몇가지 정보 받아서 서너가지 대분류로 쳐 넣는 수준만 했어도 납득했을겁니다.
일부러 몽땅 몰아서 옛날 레거시 하드웨어랑 같은거 돌리게 만드는건 아무리 봐도 졸렬한 짓이죠..
소프트웨어에 돈 털어넣은것만 인정.. 나머지는 내가 말하는게 아니야 그거 말고는 상관 없어.. 라고 해버리는건 좀 억지 스럽습니다.
지금의 존재 자체에 기여 했는데 그건 다른이야기니까 이야기 하지말고..
딱 소프트웨어 개발사나 독점 컴파일러 같은거 만드는데 돈 털어넣것에 한해서 이야기해 그것이 생태계니까... 해버리면 좀 난감하네요.
사기업이 회삿돈 들여 만든 라이브러리를 타사에 맞게 커스터마이즈할 필요는 없습니다.
오히려 리거시 코드 박아둔 것을 고마워 해야 할 판입니다. 공공기관이 아님에도 준 공공기관급으로 호환성 확보해 줬으니까요.
AMD 팬덤이 강한 건 알겠습니다만..
이제야 조금 좋아진 수준이고,
과거에는 윈도우 전용 x86 프로세서에 제네릭 컴파일러밖에 못 쓰는 형편 없는 하드웨어였습니다.
PCH 칩셋 문제로 AMD가 나쁘다고 팬덤 사이에 잘못 알려졌는데 엄연히 AMD가 방관한 겁니다.
PCI Express 풀 스피드도 못 뽑아내는게 너무 당연한 하드웨어였는데요.
인텔은 1970년대부터 각종 라이브러리, 컴파일러 모두 자체 구성하고 최적화해 왔습니다.
저 고전적인 CISC가 아직도 살아남은 이유가 뭘까요? 인텔이 돈을 미친듯이 퍼부어서 살려놔서 그런겁니다.
인텔은 사기업입니다.
그리고 저런거 다 돈들여서 해서 지금까지 살아남은거고요.
AMD는 태생부터가 인텔의 투자에 빌붙는 존재였습니다.
리사 수 잠깐 반짝한다고 그 격차가 단숨에 좁혀질 리가 없죠. 애초에 얘네들은 프로세서 딱 하나만 하고 PCH부터 다 말아먹고 소프트웨어는 안중에도 없는 기업입니다.
대중은 "2등이 1등을 앞지르는 스토리"를 좋아하니 AMD 응원하고 인텔 욕 하는것도 이해는 됩니다만, 엄연히 저 라이브러리는 인텔이 돈 들여 만든겁니다. AMD 편의를 봐줘야 할 이유가 한 톨 없습니다.
PCH칩 문제는 20년전 VIA칩셋 쓸때나 이슈였지 AMD에서 자체적으로 칩 만들기 시작한 이후로는 이슈된적 없었던것 같습니다
(뭐 지금도 몇몇 칩은 Asmedia에 외주주고 있기는 합니다만 라이젠은 PCH없어도 작동하긴 하죠)
두 회사 프로세서 명령어 셋이 모두 다 같은 것도 아니고, 인텔 내부에서 몇 가지의 그룹으로 나눠서 컴파일러 최적화시켜 바이너리 구성합니다. 이걸 그대로 AMD에 동작하도록 하면 100% 문제가 생기기에 구형 인텔 cpu 정도로 동작하도록 한 것 같습니다 (x86 generic). Intel과 AMD는 물리적으로 100% 동일한 ISA가 아니기 때문에 AMD를 제대로 지원하려면 복잡해집니다. 그리고... 애당초 AMD는 gnu 컴파일러 말고 제대로 된 것도 없구요. 투자 한 톨도 안하니.
pch는 프로세서 내장되며 상황이 개선되긴 했습니다만, 5년 전만 해도 인터넷 서핑 정도나 할만한 수준이었습니다. pci-express 부하 걸리면 속도가 안 나옵니다. 라이젠 나오면서 그나마 쓸만해졌습니다. 20년 전에 해결된 건 결코 아니죠. 그나마 좋다는 SB600만 해도 느려 터져서 사용할만한 물건이 아니었습니다.
뭐 인텔은 투자를 워낙 많이 해서 IA64에서 에뮬레이션하는 IA32속도가 AMD64에서 돌아가는 속도를 못따라가서 결국 AMD64를 라이센스 받아서 구현했으니까요
명령어셋이라는게 결국 양쪽 다 서로가 개발한걸 정식으로 라이센스 받아서 구현한건데
AVX가 AMD에서 제대로 구현이 안된다면 인텔에서 제대로 정보를 제공하지 않아서 발생한거 아닌가요?
만약 AMD가 AMD64명령어로 개발한 제품은 인텔CPU에서 32비트로 구동됩니다라고 하면 똑같이 받아들이실 수 있을껍니까?
그리고 CPU에 내장된건 PCH가 아니라 노스브릿지에 해당하는 물건입니다. PCH는 과거에 사우스브릿지라고 불리던 제품이구요
라이젠3세대에서는 멤컨과 PCI-EXPRESS컨트롤러를 분리해서 IO다이가 별도로 있긴 합니다
말씀하신 SB600이라면 대략 소켓 939~AM2시절정도까지 쓰였던 물건인것 같은데
오래된 이야기라 구시대글이 남아있는 파코즈등을 검색해봐도 해당 이슈는 나오는게 없네요.
PCI-EXPRESS가 글카를 위해 CPU에서 나오는 레인을 말씀하시는건지
혹은 SATA나 랜과같은 장비를 연결하기 위해 PCH에서 나오는걸 말씀하시는건지 모르겠는데
보통 16X슬롯은 CPU에 내장되어있는 컨트롤러에서 나오는 레인이라 여기에 부하 건다고 PCH속도 떨어지는 일은 없습니다
글카 부하는 아니라고 쳐도 당시 기준으로 IO성능이 인텔에 비해서 떨어지던건 맞지만 부하 걸린다고 IO속도가 떨어지는 이슈는 못본것 같습니다.
아마 SB600이 거의 애슬론64 초창기때부터 나온 칩인데 그걸 단가절감을 위해 AM2+까지 끌고와서 발생한 문제가 아닐까 합니다만
인텔로 따지면 당시 소켓 775 초창기에 ICH5를 달고 나온 보드로 코어2쿼드까지 쓰는 경우도 있었으니까요
보통 코어2시리즈와 같이 사용되던 PCH칩은 ICH9인데 저가형보드는 6,7,8 다 넘기고 ICH5를 쓰기도 했죠
그런 보드와 조합하면 최신 CPU를 달아도 IO성능은 처참했습니다
AMD PCI-Express는 CPU Lane 얘기입니다. 제대로 속도 안 나옵니다. 단순 PCH 문제라면 해피할텐데, 라이젠 전엔 AMD 안 쓰는게 돈 아끼는 지름길이었습니다.
그렇게까지 하지 않고 그냥 단순하게 AVX2가 사용 가능한 CPU면 사용한다 라는 정도 까지만 해줬어도 훨 나았겠죠
뭐 인텔이 AMD를 위해서 그렇게 까지 해줘야 하냐 싶겠지만 저정도 처리는 인텔 CPU 내부끼리 구분할때도 충분히 해야하는거니까요
그리고 CPU레인 이야기라면 애초에 PCH와 상관 없는 이슈인데 왜 PCH를 물고 늘어지셨는지 모르겠네요
게다가 CPU레인이면 주로 그래픽카드에서만 사용하는 레인인데 단순하게 CPU성능 외에
PCI-EXPRESS 속도가 떨어져서 사용이 힘들다는 이야기는 더더욱 못들어본것 같습니다
IO에서 발생하는 문제를 CPU레인 문제로 생각하시는거라면 아예 CPU와 메인보드 구조 자체에 대해 모르시는듯 하구요
원문의 링크와 그외 알려진 링크들의 내용을 보면 기존의 MKL을 사용하던 환경에서, 환경변수로 셋팅하나만 해줘도 극적인 성능향상을 보인다는 내용입니다. 즉 이미 컴파일러 설정이고 뭐고를 논할 수준이 아닌 거죠. 이미 기존의 컴파일 된 바이너리에서도 AMD Cpu를 사용해도 웬만큼 성능이 나오게 컴파일되어 있었다는 뜻입니다.
아니면 AMD가 직접 컴퓨트 라이브러리를 만들던지.
인텔이 타사 프로세서를 위해서 굳이 라이브러리를 업데이트해줘야 합니까?
https://software.intel.com/en-us/onemkl-windows-developer-guide
하드웨어가 소프트웨어에 맞춰야된다란 주장이 있어서;;;;;;;;;;
인텔 암드 이런걸 떠나서
소프트웨어가 하드웨어 지원에 최적화하는게 맞지요;;;;
MKL 이야기 인텔쪽 최후의 보루같은거라서...
알겠는데 치사한건 사실이죠..
결론은
현재까지 알려진것과 다르게 Zen2에서 AVX2 성능이
발군이었고 AVX512까정도 상대해볼만한 상태라는겁니다....
심지어 3900X가 AVX2에서 7900X의 AVX512를
일부 이기는 상태....
작업용에서 Zen2 선택이 아주 좋은 제시점이 될겁니다....
인텔 입장에선 AVX512와 함께 최후의 보루였는데
그닥 유쾌한 상황이 아니라는것이죠....
AVX512 미지원이 무색할정도로 Zen2 AVX2 성능이 엄청
발군으로 밝혀졌으니...
이런 모습만 보이니 안타까워요. 사업 분야도 다양하고 기업 규모도 넘사벽인데.
그걸 옹호하는 분들이 계시는게 좀 의아 합니다.
법적으로 맞네 틀리네 를 떠나야 합니다. 사다리 걷어 차서 경쟁사 물먹이는건 대부분 합법적인 틀 안에서 이루워 지잖아요....
우리나라 대기업도. 해외 대기업도 많이 하는 방식이죠.
내 가 오르는 사다리가 아니라고 해서 신경을 안쓰면 언젠가 제가 쓰는 이 사다리도 걷어 차이게 될수 있을거 같네여.
우리나라 대기업들도 합법 적인 틀 내에서 사다리를 걷어 차잖아요.
저는 비슷하게 보이는데요?
저만 그렇게 보이나요?
CUDA는 어떻게 생각하세요?
엔비디아의 치사한 사다리 걷어차기인가요?
국내에서는 정말 너무나도 소프트웨어 개발과 저작에 대한 인식이 낮은것 같아요.
기본적으로 공짜라는 인식 공공재라는 인식이 있지 않고서야 어떻게 이렇게까지 얘기 하는지.
직감적인 인식으로는 수학기호 vs 강사의 강의녹음..같은 기분이랄까요?
특정 강의의 저작권에 대해서는 크게 이견들이 없으실텐데, 수학기호를 사용하는 데 저작권운운하면 설사 그게 법적으로 정당하다고 해도 영 마음에 안든달까요. 물론 MKL이 수학기호보다는 많은 노력이 들어가긴 했습니다만.
제가 MKL을 써본적은없지만, 이야기자체는 오래전부터 들었거든요. 과학계산이나 수치계산 많은 곳에 쓰인다고...게임하는 데 쓰는 지는 잘 모르겠습니다만, 보다 기초과학이나 통계, 데이터처리하는 그런 과학관련분야에서 많이 썼을텐데 그런데에 저렇게 치졸하게 나와서 소비자의 선택을 제한하는 건 아무래도 좀 치사해보이죠.
다른거 같습니다.
인텔에서 그냥 제한을 걸고 우리만 쓰겠다. 가 아니라.
우리가 개발했지만 너희들이 쓸 수 있도록 해줄께.
라고 해놓고 막상 사용하면 성능을 고의적으로 낮춰서 판매량에 영향을 주는 행위로 보이는게 문제로 보입니다.
그냥 우리만 쓰려고 만든거니. 너희들은 직접 만들어서 써 가 아니라.
우리꺼 쓸수 있게 해줄께 라고 해놓고 뒤로는 제한을 걸어 버린거죠.
이건 아무리 봐도 의도 했다고 보이거든요.