x86‑TSO 에뮬레이션이 ARM에서 성능 병목 현상을 일으키는 이유와 FEX의 해결 방법

핵심 문제: 약한 순서의 ARM ISA에서 x86‑TSO 에뮬레이션하기

*ARM의 약한 순서(weak ordering) 모델에서 x86 TSO(Total Store Ordering) 메모리 모델을 에뮬레이션하면 모든 x86 로드를 ARM의 load‑acquire로, 모든 스토어를 store‑release로 변환해야 하므로 큰 성능 저하가 발생합니다.* 이러한 명령어들은 일반적인 로드/스토어보다 훨씬 비용이 많이 들며, 주된 명령어 클래스로 사용되도록 설계되지 않았습니다.

x86‑TSO가 애플리케이션에 중요한 이유

x86‑TSO는 스토어가 모든 코어에 보이기 전에 이후의 로드가 이를 관찰할 수 없음을 보장하여, 프로그래머가 추가적인 펜스(fence) 없이 메모리를 추론할 수 있게 합니다. 이러한 엄격한 일관성은 x86 ISA에 내장되어 있으며, 사실상 모든 PC 게임과 많은 레거시 애플리케이션이 이에 의존하고 있습니다.

ARM의 약한 일관성 모델

ARM의 기본 로드 및 스토어는 즉각적으로 일관되지 않습니다. 스토어는 명시적으로 플러시될 때까지 개인 캐시 라인에 머물 수 있으며, 로드는 오래된 데이터를 볼 수 있습니다. 순서를 보장하기 위해 ARM은 가벼운 장벽 역할을 하는 load‑acquire 및 store‑release 명령어(“RCsc” 모델)를 제공합니다.

초기 에뮬레이션 전략: 모든 곳에 Acquire/Release 적용

FEX는 처음에 모든 x86 로드를 ARM load‑acquire로, 모든 스토어를 store‑release로 매핑했는데, 이는 기능적으로는 정확하지만 비용이 매우 많이 듭니다. 5개의 CPU에서 수행한 마이크로 벤치마크에 따르면 acquire‑load는 최대 50%의 속도 저하를 보였고, 여러 코어(예: AmpereOne)에서 release‑store의 처리량이 급격히 낮아졌습니다.

스플릿‑락(Split‑Lock) 문제

x86 프로그램은 캐시 라인 경계를 넘나드는 정렬되지 않은 액세스(“스플릿‑락”)를 자주 수행하는데, 이는 x86에서는 원자적이지만 ARM에서는 정렬 오류를 일으킵니다. ARM은 acquire/release 명령어에 대해 자연스러운 정렬을 요구합니다. 정렬되지 않은 액세스는 오류를 트리거하며, 이로 인해 FEX는 런타임에 JIT를 패치하고 DMB(data‑memory‑barrier)를 삽입한 후 재시도해야 합니다.

"이러한 패치 지점에서 정렬 오류가 발생하면 FEX는 오류를 포착하고, 코드를 load‑acquire/store‑release 명령어에서 기본 로드‑스토어 명령어로 패치한 다음, 해당 명령어를 데이터 메모리 장벽으로 감쌉니다." – FEX 기사

오류 처리 경로는 모든 스플릿‑락에 대해 커널에서 사용자 공간으로의 왕복을 포함하며, 이는 네이티브 실행보다 수천 배 더 느릴 수 있습니다.

도움이 되는 ARM 확장 기능

LRCPC (FEAT_LRCPC, LRCPC2, LRCPC3)

LRCPC 제품군은 acquire‑load의 무거운 페널티 없이 x86‑TSO 의미론과 일치하는 “Release Consistency processor‑consistent” 로드 명령어를 추가합니다. 벤치마크에 따르면 LRCPC‑로드 방식은 대부분의 CPU에서 기준 처리량에 가까운 성능을 달성합니다.

FEAT_LSE2

FEAT_LSE2는 acquire/LRCPC/Release 명령어에 대한 정렬 요구 사항을 16바이트 단위로 완화하지만, 64바이트(캐시 라인)를 넘나드는 경우에는 여전히 오류가 발생합니다. 대부분의 x86 원자적 연산이 전체 64바이트 캐시 라인에 걸쳐 있기 때문에 스플릿‑락에 대해서는 미미한 이득만 제공합니다.

Apple의 하드웨어 TSO 모드 – 이상적인 해결책

Apple Silicon은 일반 ARM 로드/스토어가 x86‑TSO 의미론을 따르도록 하는 하드웨어 토글을 구현하여, acquire/release나 LRCPC 명령어가 필요 없게 합니다. M1에서 정렬된 액세스와 정렬되지 않은 액세스는 사실상 동일한 성능을 보이며, TSO 모드가 활성화되었을 때 스토어에 대해 약 5%의 완만한 속도 저하만 발생합니다.

"Apple의 하드웨어는 x86‑TSO 메모리 모델에 대한 지원을 직접 추가했습니다. CPU 기능이 토글되면, 그들의 일반 로드/스토어 ARM 명령어는 x86이 요구하는 것과 일치하도록 동작을 변경합니다." – FEX 기사

FEX가 이 기능을 감지하면(예: Asahi Linux를 통해), 하드웨어 TSO 모드를 활성화하여 동일한 "무료" 성능 향상을 얻을 수 있습니다.

원자적 RMW 명령어: x86 LOCK을 ARM으로 매핑

ARMv8.1‑a는 18개의 모든 x86 LOCK‑프리픽스 RMW 연산에 대한 일대일 대응을 제공합니다(예: LOCK ADD → ldaddal). 그러나 동일한 정렬 오류 문제가 적용됩니다. 캐시 라인을 넘나드는 정렬되지 않은 원자적 RMW는 여전히 비용이 많이 드는 오류 처리 경로를 필요로 합니다.

캐시되지 않은(Write‑Combine) 메모리 – 치명적인 문제

게임이 Vulkan의 VK_MEMORY_HOST_CACHED_BIT를 해제하여 사용할 때(write‑combine 버퍼), ARM의 LRCPC 로드는 훨씬 느려지며 스토어는 x86보다 최대 816배까지 느려질 수 있습니다. 이는 캐시되지 않은 메모리가 모든 로드를 시스템 메모리로 강제하고, LRCPC가 추가적인 장벽을 추가하기 때문입니다.

"이 모든 것 중 최악의 경우는 Zen이 스토어에서 얻는 성능과 비교했을 때 스토어 성능이 얼마나 나쁜지이며, 이는 사실상 치명적인 문제입니다. 대역폭이 최대 816배 더 나쁩니다!" – FEX 기사

FEX는 UMA 시스템에서 드라이버가 캐시된 버퍼를 사용하도록 강제하여 이 문제를 완화하지만, PCIe‑GPU 시스템에서는 문제가 해결되지 않은 상태로 남아 있습니다.

공급업체별 결과

CPU	정렬된 로드/스토어	정렬되지 않은 페널티 (로드)	정렬되지 않은 페널티 (스토어)
AmpereOne	기준 ≈ 28 GB/s 스토어	≈ 0% (로드)	~8.5% 속도 저하 (스토어)
Cortex‑X4	11.5 GB/s 로드, 6.7 GB/s 스토어	~50% 속도 저하 (둘 다)
Cortex‑X925	X4와 유사, 더 높은 절대 대역폭
Oryon‑3	정렬된 LRCPC‑로드는 기준과 일치; 스토어 ≈ 기준의 68%; 정렬되지 않은 스토어 ≈ 43%
Apple M1	스토어에 대해 < 5% 속도 저하; 로드는 변경 없음 – 하드웨어 TSO가 정렬 오버헤드를 제거

스플릿‑락을 위한 향후 하드웨어 지원 제안

실현 가능한 하드웨어 수정은 정렬 오류를 발생시키지 않고 64바이트 경계를 넘어 원자적으로 작동할 수 있는 128비트 CASP입니다. 연산은 실패하고 재시도될 수 있으며, ARM의 LL/SC 모델을 활용하여 전진 진행을 보장할 수 있습니다.

개발자 및 아키텍트를 위한 요약

하드웨어 지원 없이 ARM에서 x86‑TSO를 에뮬레이션하는 것은 비용이 많이 듭니다. – acquire/release 명령어와 스플릿‑락에 대한 오류 처리가 오버헤드의 대부분을 차지합니다.
LRCPC 확장 기능은 기본 로드/스토어 성능을 크게 향상시키지만, 정렬되지 않은 원자적 연산이나 write‑combine 사례는 해결하지 못합니다.
Apple의 하드웨어 TSO 모드는 최적의 경로를 보여줍니다. – 일반 로드/스토어가 x86‑TSO를 따르게 하여 네이티브에 가까운 성능을 내는 단일 토글입니다.
캐시되지 않은(write‑combine) 메모리는 PCIe‑GPU 시스템에서 여전히 중요한 병목 현상입니다. – 드라이버 수준의 우회 방법만이 현재 유일한 실질적인 완화책입니다.
향후 ARM 확장 기능(예: 스플릿‑락 인식 CASP)은 캐시 라인을 넘나드는 원자적 연산에 대한 남은 성능 격차를 줄일 수 있습니다.

커뮤니티 반응

"Apple은 x86 에뮬레이션이 중요해졌을 때 칩에 x86 호환 메모리 순서 모드를 단순히 추가함으로써 6년 전에 이 문제를 해결했습니다. Apple의 칩이 업계를 선도하는 또 다른 방식입니다." – @modeless

"FEX는 놀랍습니다. 제가 겪는 대부분의 문제는 안티 치트와 관련이 있지만, 에뮬레이터 자체는 아키텍처상의 장애물을 고려할 때 인상적으로 빠릅니다." – @sureglymop

"이 기사는 ARM이 가장 느슨하고 x86이 가장 엄격하다는 일반적인 주장을 반복합니다. 느슨한 모델이 반드시 큰 이점이 있는 것은 아닙니다." – @pdw (외부 토론 링크)

결론

ARM에서 x86‑TSO를 에뮬레이션하는 것은 두 ISA가 정반대의 메모리 순서 보장을 강제하기 때문에 근본적으로 어렵습니다. 현재 최고의 소프트웨어 접근 방식(acquire/release → LRCPC → 하드웨어 TSO)은 대부분의 워크로드에서 허용 가능한 성능을 제공하지만, 스플릿‑락과 캐시되지 않은 메모리는 여전히 심각한 속도 저하를 유발합니다. 지속적인 ARM ISA 확장과 Apple의 방식과 같은 하드웨어 TSO 모드의 광범위한 채택이 향후 ARM 플랫폼에서 원활하고 고성능인 x86 에뮬레이션을 위한 가장 유망한 경로입니다.