x86 에뮬레이터 팀이 너무 나쁜 코드를 발견해 에뮬레이션 중 고쳐버린 일

• x86-32 에뮬레이터는 다른 프로세서에서 x86-32 코드를 실행하기 위해 바이너리 변환으로 네이티브 코드를 생성했으며, 인터프리터 방식보다 큰 성능 개선을 제공함
• 해당 에뮬레이터는 x86-32를 바이트코드처럼 보고, 에뮬레이터를 JIT 컴파일러처럼 동작시키는 구조로 이해할 수 있음
• 한 프로그램은 스택에 약 64KB 메모리를 할당하고 초기화해야 했으며, 일반적인 방식은 스택 프로브 후 스택 포인터를 줄이고 작은 루프로 메모리를 초기화하는 방식이었음
• 해당 코드의 컴파일러는 루프 대신 65,536개의 개별 바이트 쓰기 명령을 생성했으며, 각 명령이 4바이트라 64KB 데이터를 초기화하는 데 256KB 코드가 필요했음
• 에뮬레이터 팀은 이 함수를 감지하는 특수 코드를 번역기에 추가하고, 동등한 짧은 루프로 대체하도록 처리함

---

배경: x86-32 에뮬레이터와 바이너리 변환

• Windows에는 x86-32가 아닌 다른 프로세서에서 실행되는 시스템을 위해 x86-32 프로세서 에뮬레이터가 포함된 적이 있었음
• 이 사례가 어떤 프로세서에 적용됐는지는 원문에서 특정하지 않음
• 해당 에뮬레이터는 바이너리 변환을 사용해 원래 x86-32 코드와 동등한 동작을 수행하는 네이티브 코드를 생성했음
• 이 방식은 인터프리터 기반 에뮬레이션보다 상당한 성능 개선을 제공했음
• x86-32를 바이트코드로 보고, 에뮬레이터를 JIT 컴파일러로 보는 식의 이해가 가능함

문제 코드: 64KB 스택 메모리 초기화

• 한 프로그램은 스택에 약 64KB 메모리를 할당하고 이를 초기화해야 했음
• 표준적인 방식은 먼저 스택 프로브를 수행해 64KB 메모리를 사용할 수 있는지 확인하는 절차였음
• 이후 스택 포인터에서 65,536을 빼고, 작고 타이트한 루프로 메모리를 초기화하는 방식이 일반적이었음

컴파일러의 과도한 루프 언롤링

• 해당 코드를 컴파일한 컴파일러는 각 바이트를 초기화하는 루프를 생성하지 않았음
• 대신 루프를 65,536개의 개별 “메모리에 바이트 쓰기” 명령으로 펼쳐서 생성했음
• 각 명령은 4바이트 길이였음
• 결과적으로 64KB 데이터를 초기화하기 위해 256KB 코드가 필요했음

에뮬레이터 팀의 대응

• 에뮬레이터 팀은 이 함수를 감지하는 특수 코드를 번역기에 추가했음
• 감지된 함수는 동등한 동작을 수행하는 짧은 루프로 대체되었음
• 이 처리는 원래 프로그램 코드를 그대로 번역하는 대신, 에뮬레이션 중 비효율적인 코드 패턴을 더 간결한 형태로 바꾸는 방식이었음

[GN⁺]

Lobste.rs 의견들

• Raymond Chen에게 루프 펼치기(loop unrolling) 를 설명하던 댓글이 꽤 마음에 듦

  • 그 댓글은 블로그 작성자만이 아니라 일반 독자를 위해 쓴 것일 수도 있음
    이런 글을 읽는 사람 중에는 모든 배경지식을 아는 건 아니어서, 더 배울 수 있는 단서를 고마워하는 사람도 많음
  • 그 댓글은 못 봤는데 아마 삭제된 듯함. 그래도 Raymond Chen이라면 그 사람, 전설 그 자체임
    https://joelonsoftware.com/2004/06/…
  • 수십 년 전 Slashdot에서 어떤 사람이 [e-mail]에게 Perl 주제를 설명하려 했던 일이 떠오름

• 이건 Alpha에서였을 것 같음. 그 플랫폼용 x86 에뮬레이터에 워낙 많은 작업이 들어갔기 때문임