아키텍처 두 종류가 아니라 같은 기계의 두 모드
Wrenger·Töllner·Lohmann의 2024년 연구는 Mac Studio M1 Ultra, 128GiB 메모리, Asahi Linux 6.3, GCC 12.1에서 같은 AArch64 바이너리를 약한 순서 모드와 TSO 모드로 실행했습니다. SPECspeed2017의 병렬 부동소수점 실험은 20개 스레드, 세 번 실행의 중앙값과 프로그램 간 기하평균을 사용합니다. x86 대 ARM 비교나 Rosetta의 번역 비용 측정이 아닙니다.
점수가 내려가는 비율과 시간이 늘어나는 비율은 다릅니다
| 항목 | WO | TSO |
|---|---|---|
| 기하평균 점수 | 86.59 | 78.85 |
| fotonik3d | 83.64 | 83.28 |
| nab | 170.85 | 137.43 |
(86.59 - 78.85) / 86.59
≈ 8.94%분모는 WO의 점수입니다. 이 기하평균을 전체 작업의 총 실행 시간으로 바꾸거나, 모든 프로그램에 8.94%를 적용할 수 없습니다. 개별 결과의 차이도 큽니다. 저자들은 공유 데이터의 접근과 false sharing 등을 분석하지만 이것이 M1 내부 store buffer의 회로를 직접 확인했다는 뜻은 아닙니다. 64-byte 단위로 나눈다는 설명만으로 정렬 경계까지 맞아 서로 다른 캐시 라인을 쓴다고 단정해서도 안 됩니다.
더 강한 순서도 모든 동기화를 대신하지 않습니다
TSO는 모든 메모리 연산을 하나의 전역 순서대로 즉시 끝내는 순차 일관성(SC)과 같지 않습니다. 다른 주소에 대한 store 이후 load 같은 경우를 따로 고려해야 하며 프로그램의 원자 연산·fence 요구가 사라지지 않습니다. 소스 언어의 데이터 경쟁 규칙과 CPU의 하드웨어 순서 규칙 또한 별개입니다.
다른 ISA에서도 구분이 필요합니다. RISC-V Ztso 1.0은 RVWMO보다 강한 순서를 정의하면서 새 명령어를 추가하지 않습니다. 그래도 Ztso를 전제로 만든 바이너리가 Ztso 미지원 구현에서 올바르게 동작한다는 보장은 없습니다. 규격은 바이너리가 해당 요구를 표시하도록 설명합니다. 기존 fence를 임의로 지우라는 권고가 아닙니다.
실험 조건과 프로그램을 함께 가져와야 합니다
자신의 소프트웨어에 적용하려면 동일 입력·바이너리·스레드 배치에서 정확성부터 확인하고, 개별 프로그램의 시간 분포와 공유 데이터 접근을 조사해야 합니다. 논문의 컴파일 옵션과 모드 전환을 다른 CPU의 설정으로 그대로 옮겨 실행하지 않습니다. 이 글에서는 논문의 표와 계산을 검토했으며 M1의 모드 변경이나 SPEC 실행을 하지 않았습니다.
출발점은 Taras Tsugrii의 재공유 자료입니다. 게시물의 개념 그림을 M1 구현의 실측 도면으로 사용하지 않습니다.
English summary. This study compares the same AArch64 binary under two memory-order modes. Its 8.94% geometric-mean score decrease is not a universal elapsed-time penalty, an ISA comparison or a license to remove synchronization.