버그가 왜 생겼는지 아주 제한적으로 추정해 보면, 스카이레이크에서 11년만에 프론트엔드를 늘렸습니다.

11년 전은 인텔이 AMD와의 성능 경쟁에서 겨우 이기기 시작한 시기인데요, Conroe와 함께 프론트엔드를 늘렸습니다.

다만 이 시기에서도 완벽하지는 않았습니다. Conroe의 errata만 봐도 상당히 많았고 (그래도 이번 건 보다는 약해 보입니다.)

Conroe 개발 하던 도중에 AMD64 명령어가 생겨서 호환성을 맞추느라 아키텍처가 누더기가 됐다는 말이 있습니다.

당시만 해도 인텔은 64비트로의 전환을 당장 염두해 두지 않았다고 하고요.

그래서 Conroe는 64비트 모드로 동작하면 분기예측 성능이 엉망이 됩니다.

이건 이후의 울프데일 정도는 돼야 개선이 되구요.

프론트엔드 늘리는게 워낙 힘든 작업에다가 x86은 잘 아시듯 누더기 중에서도 심각한 누더기 아키텍처입니다.

CISC인데 내부적으로는 RISC로 동작하면서도 SIMD는 어마어마하게 많고 8비트부터 64비트까지 호환성을 다 가져가야 합니다.

물론 64비트로 오면서 8비트 호환성을 상당히 포기하긴 했으나, 칩셋 자체는 32비트를 지원하기 때문에 32비트 모드로 동작하는 경우에는 여전히 8비트 호환성을 가져가야 하는 상황이고요.

x86 자체가 레지스터 갯수가 너무 적어 성능이 느릴 수 밖에 없어서 Logical Register 하나를 두고 내부적으로는 Physical Register를 어마어마하게 많이 둔다고 알려져 있습니다. x86 명령어가 느리지만 동작은 빠른 이유가 이 때문이라고 보이고요.

문제는 어떤 Physical Register가 어떤 Logical Register와 매치되는지를 매번 결정해 줘야 하는데, 이걸 생으로 연산하기에는 너무 부담이 커서 캐싱을 해서 동작합니다. 예를 들어, Basic Block 정도의 단위에서는 그냥 생으로 연산해 버리는 식으로요.

이걸 매 경우마다 다 따져가며 연산해 줘야 하는데, 사람이 할 일이 아니지만.. 그래도 인텔은 하더라구요.

그런데 여기에 하이퍼쓰레딩까지 들어가 있으니까..... 이건 진짜 사람이 할 일이 아니게 됩니다.

이 어마어마한 아키텍처를 지금까지 끌고온 것도 대단한데......

AMD가 여기까지 따라온것도 신기합니다.

이야기가 조금 샜는데, errata를 보면 하이퍼쓰레딩이 켜진 상태에서 AH, BH, CH, DH레지스터가 Short Loop에서 사용될 경우, 루프 길이가 64 인스트럭션 이하일 경우에 문제가 생긴다고 합니다.

64인스트럭션이면, 짐작 가는게 있죠. 명령어 레지스터 캐시 크기가 비슷합니다...

64 인스트럭션을 넘어가면 캐시가 비워지니까 제대로 동작하는 것 같아요. 한방에 다 캐싱을 못하니까요.

그런데 64인스트럭션 자체가 일반적인 short loop의 한계를 넘어서기 쉬우니까

아마 이 조건을 만족하려면 아주 단순한 명령어로 구성된 short loop이어야 할 것 같아요.

하이퍼쓰레딩이 켜질 경우에만 문제가 생긴다는건 Logical Register와 Physical Register의 스위칭이 잘 안 일어난 것 같습니다.

프론트엔드는 바꼈는데 캐시 버퍼 비워주는 조건을 다 손보지 못해서 그런 것 같아요.

그래서 잘못된 레지스터가 파이프라인에 들어가면 뭐.. 오염되는거죠.

문제는 그게 AH, BH, CH, DH라는거고, 이게 오염되면 덧셈 뺄셈 곱셈 나눗셈 틀리고 함수 리턴 주소 바뀌고 난리가 나겠네요...

(왜 하필이면 이렇게 중요한 레지스터에서 오류가 생기는건지..)

문제가 왜 잡히지 않았나 생각해 보면

11년만에 프론트엔드를 바꿨고, 거기에 백엔드도 바꿨는데...

링버스 스마트캐시 구조 바꾸느라 그것도 힘들었을텐데

(샌디브릿지, 아이비브릿지는 L2 캐시가 심각하게 느려지는 버그가 있습니다. 캐시 내부의 버스 통신 비용(communication cost)이 캐시 전송 데이터보다 많아지는 경우가 드물지 않게 발생합니다....;;;; 이때 이미 인텔은 망조를 보이기 시작했습니다.. 아무튼 이 문제때문에 스카이레이크는 캐시 동작구조도 다시 설계했습니다. 정말 바뀐게 많은 아키텍처죠.)

과거에 사용했던 테스팅 노하우가 이번에는 안 통하는 시점이었던 것 같습니다.

문제는.. 저는 컴퓨터로 산술연산을 상당히 많이 하는데 (거의 연산만 돌립니다 ㅠㅠ)

스카이레이크 PC가 절대다수입니다.. 연산이 틀렸을 것 같아요.

하스웰에서 스카이레이크로 옮기고 나서 vector initialization이 좀 이상했었습니다.

이 연산이 전형적인 숏룹 쓰는 구문인데

10억개 정도의 데이터를 랜덤값 튀겨서 특정 범주 이내라면 값을 기록하도록 되어 있습니다.

이게.. 하스웰에서 스카이레이크로 옮기고 나서 값에 0이 훨씬 많이 들어와 있었습니다.

아무튼 저는 이게 상당히 심각해 보입니다.

인터넷에서는 실드가 정말 많이 보이고...

errata에 들어있는 흔하디 흔한 버그라는 사람도 있는데..

저는 개인적으로 errata를 종종 찾아보긴 합니다만, 이번과 같이 범용적인 케이스는 제 눈으로는 두 번째로 봅니다..

인텔 플로팅포인트 나눗셈 버그는 전해듣기만 한거라 제외하고,

AMD TLB 캐시 미스.. 이건 뭐..... 역대 최악의 양산 CPU 버그죠. CPU L3 캐시가 오염됩니다.

BIOS 패치로 TLB를 끄는 식으로 패치했고, "최소" 10% 성능이 낮아졌습니다.

이 시기부터 AMD가 맛이 가다가, 10년 넘어서야 다시 고개를 들고 있습니다.

그 다음으로 심각해 보이는게 지금 이 버그입니다.

GPR 중에서도 정말 메이저 레지스터인 AH, BH, CH, DH가 ALU에서 연산될 때의 버그....

x86에서 이 네 개의 레지스터를 빼면 시체인데 ㅠㅠ 여기서 버그라니.....

이런 버그는;;

산술연산 주로 돌리는 입장에서는 차라리 AMD를 쓰고싶어지는 수준입니다..... ㅠㅠ