왜 x86‑TSO 에뮬레이션은 ARM에서 성능 저하의 원인이 되는가 그리고 제조사들은 어떻게 이를 해결하고 있는가

TL;DR

x86‑TSO를 ARM의 약한 메모리 모델에서 에뮬레이션하는 것은 비용이 크다. 모든 로드/스토어가 acquire/release 명령어로 변환되어야 하며, 비정렬 접근은 비용이 큰 정렬 오류 처리를 유발하고, 분할 잠금 원자성은 무거운 커널 중재가 필요하기 때문이다. 최근 ARM 확장 기능(LRCPC, FEAT_LSE2)과 애플의 하드웨어 TSO 모드는 이러한 부담의 대부분을 완화하여 현대 ARM CPU에서 거의 네이티브 성능을 달성할 수 있게 해준다.

x86‑TSO란 무엇이며 왜 중요한가?

  • x86‑TSO (전체 스토어 순서) 는 스토어가 모든 코어에 보이기 전에 이후의 로드가 이를 관찰할 수 없도록 보장한다. 이는 프로그래머에게 간단하고 직관적인 모델을 제공한다: 쓰기는 즉시 일관성 있게 된다.
  • ARM의 약한(완화된) 모델 은 스토어가 개인 캐시 라인에 머무를 수 있고, 로드는 명시적인 acquire/release 명령어를 사용하지 않으면 오래된 데이터를 볼 수 있다.
  • x86 에뮬레이터(예: FEX)가 ARM에서 실행될 때, 모든 x86 로드를 ARM의 load‑acquire로, 모든 x86 스토어를 ARM의 store‑release로 변환하여 TSO 의미를 유지해야 한다.
  • 이 변환은 ARM의 네이티브 모델보다 훨씬 제약이 크며, 런타임 성능을 지배할 수 있다.

acquire/release 의미 체계의 기준 성능

  • FEX의 초기 구현은 ARMv8.0‑a의 acquire/load 및 release/store를 모든 메모리 작업에 사용했다.
  • 마이크로 벤치마크 결과 대부분의 CPU에서 2~5배의 속도 저하 가 발생했다. acquire/release 명령어는 자유롭게 재정렬될 수 없으며, 핫 패스가 되기 때문이다.
  • AmpereOne 서버 CPU는 가장 큰 속도 저하를 보였다. 그의 release‑store 유닛이 특히 약했으며, acquire‑loads의 엄청난 양이 파이프라인을 억제했다.
  • 고성능 모바일 코어(Cortex‑X4, X925)도 비정렬 접근에서 약 50 %의 손실을 겪었는데, 이는 정렬 오류 발생 시 필요한 추가 DMB(데이터 메모리 장벽) 때문이었다.

비정렬 접근과 분할 잠금

ARM에서의 정렬 오류

  • ARMv8.0은 자연 정렬(주소 ≡ 크기)을 요구한다. 이를 위반하면 정렬 오류가 발생하고 일반적으로 프로그램이 중단된다.
  • FEX는 각 로드/스토어 전에 패치포인트(NOP)를 삽입한다. 오류가 발생하면 명령어를 DMB로 감싸는 일반 로드/스토어로 패치하고 실행을 재개한다.
  • 이 대체 경로는 작동하지만, 매번 비정렬 접근마다 커널에서 사용자 공간으로의 라운드트립이 발생하므로 비용이 크다.

x86에서의 분할 잠금

  • x86은 분할 잠금(split-lock) 작업을 허용한다: 캐시 라인 경계를 넘는 원자적 읽기/쓰기. 이들은 여전히 원자적이고 일관성 있게 유지되며, 절단되지 않는다.
  • ARM의 원자 명령어는 자연 정렬 접근에 대해서만 단일 복사 원자성을 제공한다. FEAT_LSE2 확장 기능은 이 범위를 16바이트 그레인으로 완화하지만, 여전히 전체 64바이트 캐시 라인 경계를 넘는 경우 실패한다.
  • 따라서 FEX는 두 개의 64비트 비교-교환(CAS) 연산 시퀀스와 커널 기반의 오류 핸들러를 사용하여 분할 잠금을 에뮬레이션해야 한다. 이는 수백 나노초의 오버헤드를 발생시키며, 네이티브 x86(~1.4 ns)보다 훨씬 느리다.

도움이 되는 아키텍처 확장 기능

LRCPC (Release Consistency processor‑consistent) – ARMv8.3+

  • x86‑TSO 요구 사항을 충족하는 메모리 모델을 구현하는 LRCPC‑load 및 LRCPC‑store 명령어를 도입한다.
  • 벤치마크 결과 LRCPC‑loads는 모든 테스트 CPU(AmpereOne, Cortex‑X4/X925, Oryon‑3, Apple M1)에서 기준 로드 성능 을 달성한다.
  • FEX는 FEAT_LRCPC 기능을 감지하고 acquire‑load에서 LRCPC‑load로 전환하여 정렬된 접근에 대한 비용이 큰 DMB 경로를 제거한다.

FEAT_LSE2 (Large System Extensions 2)

  • acquire/LRCPC/Release 명령어 및 읽기-수정-쓰기 원자성에 대한 정렬 요구 사항을 16바이트 그레인 내의 임의의 주소 로 완화한다.
  • x86 에뮬레이션에 대해 매우 제한적인 이득 만 제공한다. 대부분의 x86 코드는 전체 64바이트 캐시 라인을 가로지르는 데이터에 접근하기 때문이다(진정한 분할 잠금).

애플의 하드웨어 TSO 모드

  • 애플 실리콘은 스레드 단위 TSO 토글(FEAT_TSO)을 구현한다. 활성화되면 일반 ARM 로드/스토어가 x86‑TSO처럼 동작한다.
  • M1에서는 LRCPC‑loads가 단순히 일반 로드의 별칭이므로, 정렬 및 비정렬 접근 모두에서 5 % 이하의 오버헤드 가 발생한다.
  • 교환 조건은 약간의 (~24 % 저장 시) 성능 저하가 있지만, FEX의 네이티브 ARM 실행 비율이 매우 작기 때문에 영향은 무시할 수 있다.

제조사별 성능 스냅샷

CPU 정렬된 로드 (GB/s) 비정렬 로드 페널티 정렬된 스토어 (GB/s) 비정렬 스토어 페널티
AmpereOne ~28 (기준) ≈0 % (정렬 처리됨) ~28 ~8.5 % 감소
Cortex‑X4 11.5 ~50 % 감소 (DMB) 6.7 ~50 % 감소
Cortex‑X925 14.2 ~50 % 감소 9.1 ~50 % 감소
Oryon‑3 18.0 (LRCPC‑load ≈ 기준) ~30 % 감소 12.2 (기준의 ≈68 %) ~57 % 감소
Apple M1 (TSO) ≈기준 ≤5 % 기준의 ≈76 % (여전히 빠름) 무시 가능
  • 수치는 기사의 마이크로 벤치마크 그래프에서 유도되었으며, 간결함을 위해 정확한 값은 생략됨.

캐시되지 않은 (쓰기 결합) 메모리 도전 과제

  • 게임은 종종 VK_MEMORY_HOST_CACHED_BIT = 0 (캐시되지 않음, 쓰기 결합) 메모리로 GPU 버퍼에 직접 쓴다.
  • ARM에서는 캐시되지 않은 스토어도 여전히 store‑release를 사용하지만, 이는 쓰기 결합 버퍼링의 이점을 받지 못 하여 캐시된 스토어보다 최대 816배 낮은 대역폭 을 보인다.
  • 로드 대역폭은 더 심각한 영향을 받는다. 모든 로드는 캐시를 우회하고 시스템 메모리에 직접 접근해야 하기 때문이다.
  • 결과적으로 PCIe‑GPU 시스템에서는 에뮬레이션된 x86 게임이 1 FPS 미만 으로 떨어질 수 있다 (예: Hollow Knight: Silksong, Subnautica 2).
  • 대안:
    • UMA 시스템(통합 GPU)에서는 드라이버가 캐시된 버퍼를 사용하도록 강제한다. NVIDIA Tegra, Snapdragon Adreno, 그리고 많은 Mali GPU는 이미 이 작업을 수행한다.
    • 애플의 TSO 모드는 하드웨어가 캐시되지 않은 스토어를 일관성 있게 처리하기 때문에 문제를 자동으로 회피한다.
    • 현재 ARM 확장 기능 중 쓰기 결합 스토어 문제를 해결하는 것은 없으며, 미래의 FEAT_LRCPC4 가 필요할 것이다.

분할 잠금 에뮬레이션의 정확성

  • FEX의 현재 분할 잠금 에뮬레이션은 최선의 노력 으로, 비분할 잠금 원자성이 128비트 영역의 한쪽만 수정할 경우 데이터가 훼손될 수 있다.
  • 단순한 글로벌 뮤텍스 솔루션은 모든 분할 잠금을 시리얼라이즈하지만, 동시에 실행되는 정렬된 원자성에서 여전히 훼손을 허용한다.
  • 게임에서 분할 잠금의 빈도가 높기 때문에 커널 전체의 "세계 멈춤" 접근은 불가능하다.
  • 저자들은 캐시 라인 경계를 넘는 128비트 CASP를 제안한다. 이는 정렬 오류를 유발하지 않으며, 실패할 수 있고 재시도할 수 있어 원자성을 유지할 수 있다.
  • ARM의 트랜잭셔널 메모리 확장 기능(TME)은 이론적으로 도움이 될 수 있지만, 폐기되었고 실제로 출시되지 않았다.

커뮤니티 인사이트

"애플은 x86 에뮬레이션이 중요해지자 6년 전부터 단순히 칩에 x86 호환 메모리 순서 모드를 추가함으로써 이 문제를 해결했다. 애플 칩이 산업을 선도하는 또 다른 방식이다." – modeless

"FEX는 Apple의 Rosetta2와 Microsoft의 Prism과 마찬가지로 x86에서 ARM으로의 번역 프레임워크다. Valve는 새로운 Steam Frame가 x86 게임을 지원하는 방식이기 때문에 개발을 후원한다." – dagmx

"이 기사는 ARM이 가장 완화된 모델이고 x86이 가장 엄격한 모델이라고 일반적으로 주장하지만, 완화된 모델이 반드시 큰 이점이 있는 것은 아니다." – pdw

이러한 의견들은 기사의 핵심 주장, 즉 하드웨어 수준의 지원(애플의 TSO, ARM LRCPC)이 ARM에서 고성능 x86 에뮬레이션을 위한 유일한 실용적인 길임을 강화한다.

전망

  • ARM 제조사들은 점진적으로 LRCPC와 LSE2 확장을 추가하며 x86‑TSO와의 격차를 좁히고 있다.
  • 애플의 하드웨어 TSO 모드는 전용 TSO 토글이 가장 깔끔한 해결책임을 보여준다.
  • 분할 잠금 인식 128비트 CASP 또는 재활성화된 트랜잭셔널 메모리 확장 기능과 같은 미래 제안은 마침내 남은 정확성과 성능 격차를 제거할 수 있을 것이다.
  • 이러한 확장 기능이 일반화되기 전까지는 ARM에서 x86 에뮬레이터는 UMA 플랫폼을 선호하고, 드라이버 패치(예: Valve의 Steam Frame 커널 패치)에 의존하여 캐시되지 않은 메모리 페널티를 완화할 것이다.

결론적으로: x86‑TSO를 ARM에서 에뮬레이션하는 것은 두 메모리 모델이 일관성 스펙트럼의 양극에 있기 때문에 본질적으로 비용이 크다. 그러나 최근 ARM ISA 확장 기능과 애플의 하드웨어 TSO 모드는 오버헤드를 크게 줄여주어 ARM에서 고성능 x86 게임을 실행하는 것이 점점 더 가능해지고 있다.

Sources

관련