Hacker News 의견들

• 테스트 재현에 필요한 설정, 추측, 코드까지는 다 공개했는데 체감 결과값 자체가 빠져 있어서 조금 의심스러웠음. ARM이 실제로 얼마나 빠른지 수치가 궁금했음
  • 출력 스크린샷을 일부러 뺐던 이유가 있었음. 벤치마크 글로 흐리는 걸 피하고 싶었고, ARM 하드웨어나 Snapdragon X Elite 세부 모델에 따라 결과가 달라져 오해를 부를 수 있다고 봤음. 대신 누구나 재현할 수 있게 PowerShell 스니펫을 넣었음. 대략적인 결과는 Snapdragon VM이 Intel VM보다 테스트별로 약 20~80% 빨랐고, DNS는 약 20%, IIS는 약 50%, 나머지는 대체로 80%에 가까웠음
• Windows 개발자 관점에서 보면 이건 segment heap 영향일 가능성이 커 보였음. Windows 힙 구현에는 오래된 NT heap과 2010년대의 segment heap이라는 서로 독립적인 두 계열이 있고, segment heap이 메모리 단편화와 작은 할당 재사용 면에서 더 효율적이었음. 다만 Windows는 레거시 호환성을 극도로 중시해서, 오래된 앱들이 use-after-free 같은 위험한 동작이나 내부 NT heap 구조체에 의존할 수 있었기 때문에 기본값을 일괄 전환하지 않았음. 그래서 packaged 실행 파일에는 segment heap을 기본 적용하고, unpackaged 쪽은 그대로 두는 절충을 택했음. 그런데 UWP 전환이 실패하면서 Windows 생태계는 더 쪼개졌고, 중요한 소프트웨어 대부분은 여전히 unpackaged x64로 남았음. 반면 arm64 바이너리는 오래된 레거시 코드일 가능성이 낮아서 arm에서는 segment heap이 기본 활성화됨. 사용자가 arm Windows가 더 반응성 좋다고 느끼는 이유 중 적지 않은 부분이 여기에 있다고 봄. x64에서 segment heap을 강제로 켜고 이 테스트를 다시 해보면 흥미로울 것 같았음. 실행 파일별로는 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe 아래 FrontEndHeapDebugOptions DWORD를 8로 주면 되고, 전역으로는 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap 아래 Enabled DWORD를 3으로 주면 됨. 내 개발 머신에서는 전역 활성화 후 문제를 못 봤고, 메모리 사용량은 테스트 기준 약 15% 절감됐음
  • 내 RAM/CPU 집약 워크로드에서는 NT Heap 대비 Segment Heap으로 전체 성능이 안정적으로 약 7% 좋아졌음. 합쳐진 작업이 7% 더 빨리 끝났음. 예전의 "Compatible with Windows XXX" 같은 인증이 Windows 10/11에도 있었다면, 여기에 segment heap 체크 항목을 넣어 더 많은 앱과 사용자에게 성능, 전력 효율, 친환경성 이점을 줄 수 있었을 것 같음. 그리고 UWP의 문제는 기술 자체보다 패키징과 Store 결합을 고집한 점이었고, 그건 Windows라는 OS의 존재 방식과 충돌했다고 봤음
  • 관심 있는 사람이라면 자기 실행 파일의 application manifest에서 heapType을 SegmentHeap으로 설정해 이 동작을 opt-in할 수 있음. 문서에 설명이 있음
  • 이런 식의 실전 팁이야말로 HN의 가치라고 느낌. 전역 레지스트리 키는 재부팅이 필요한지, 아니면 실행 파일 시작 시점부터 바로 적용되는지가 궁금했음
  • 이 내용은 포럼 댓글보다 블로그 글로 남아야 할 수준으로 흥미로웠음
  • 예전에 이 전역 설정은 0 대 non-zero로 설명된 걸 봤는데, 값이 왜 하필 3인지 궁금했음. 2는 어떤 의미인지, 이런 값들의 뜻을 스스로 어디서 확인할 수 있는지도 알고 싶었음
• 글의 "ARM은 높은 boost clock을 쫓지 않고 꾸준한 성능을 낸다"는 표현은 조금 과장처럼 느껴졌음. 내가 써본 ARM 시스템도 전부 주파수 스케일링을 했고, 그 점에서는 x86과 비슷하게 동작했음. 결국 차이는 얼마나 높이 올라가느냐 정도로 보였음
  • 워크로드 의존성은 있겠지만, 내가 일한 여러 조직의 클라우드 환경에서는 x86에서 ARM 전환만으로도 비용 절감 효과가 꽤 컸음. 인스턴스 가격이 더 낮은 데다 효율도 더 좋았기 때문임. 특히 한 조직에서는 수백 개의 Kubernetes 노드를 동적 오토스케일링하는 환경에서 추가 변경 없이 x86 -> ARM만으로 보수적으로도 약 15% 절감 효과를 예상했고 실제로 달성했음. CPU 바운드이면서 x86 특화 기능에 덜 묶인 워크로드라면 15%보다 훨씬 더 클 수도 있다고 봤음
• ARM CPU의 덜 흔들리고 더 예측 가능한 성능이 핵심이었다면, 데스크톱 CPU 대신 Epyc 같은 서버 CPU를 써도 비슷한 이점을 볼 수 있다고 생각했음. 서버 CPU는 클럭 변동 폭이 더 작고 boost 정책도 덜 공격적이기 때문임. 심지어 지금 있는 데스크톱 하드웨어에서도 BIOS에서 Turbo를 꺼서 Intel CPU를 기본 클럭으로 고정하면, 낮더라도 안정적이고 예측 가능한 성능을 만들어 비교해볼 수 있다고 봤음
  • 전원 관리 계획에서도 turbo 동작을 끌 수 있었음. 다만 그 설정이 GUI에 기본으로 보이지 않을 수도 있었음
• Windows on ARM이 VBS나 Virtualization Based Security를 쓰는지, 그리고 VM 안에서도 nested virtualization으로 그걸 지원하는지가 궁금했음. 또 CPU 취약점 완화가 VM에서 이중으로 걸려 성능에 영향을 주는지 여부도 중요해 보였음. 요즘 Windows를 VM에 넣었을 때 흔히 보는 성능 문제 상당수가 여기서 오기 때문임. 그런데 글에서는 이 부분을 언급하지 않아 아쉬웠음
• 두 시스템의 RAM과 스토리지 구성이 궁금했음. Snapdragon 쪽이 패키지드 RAM이라 인터커넥트가 더 빠를 수도 있고, x86 쪽은 DIMM이라 트레이스가 더 길 수도 있다고 봤음. 스토리지나 CPU 모델도 성능 차이를 크게 좌우할 수 있음. 벤치마크는 시스템 한 부분만 과하게 자극하는 경우가 많아서, 진짜 차이가 ARM 아키텍처 자체보다 RAM, syscall, SSD 같은 다른 요소에서 오는 것일 수도 있다고 생각했음
  • 두 시스템 모두 메인보드에 납땜된 DDR5와 NVMe SSD를 사용했음. 오히려 Intel 쪽 SSD가 Snapdragon 쪽 Foresee보다 더 빠른 Samsung 모델이었음
• Linux에서는 전부 더 잘 돌아가고, 감시 오버헤드로 사이클을 낭비하지 않는다고 느꼈음
• 글이 Intel 프로세서가 뭔지 일부러 말을 피하는 것처럼 보여서, 내가 뭘 놓친 건지 궁금했음
  • 사용한 CPU는 14th Gen Intel Core i9였음
• HV 서버에서는 보통 C States 비활성화, 전원 관리 high 설정 같은 방식으로 x86이 다운클럭하지 않게 막는 편임. CPU가 위아래로 흔들리지 않게 하면 성능이 크게 좋아질 수 있음. 다만 이런 건 보통 개인용이나 실험실 장비에서는 잘 하지 않음
  • 아니면 그냥 turbo boost 비활성화만 해도 됨
• 글을 읽고 나니 핵심은 두 가지로 보였음. 첫째, ARM64는 x64보다 덜 "똑똑"해서, Core i9처럼 공격적으로 부스트와 스로틀링을 반복하기보다 일정한 성능을 내고, 그 덕분에 OS 스케줄링이 쉬워진다는 점임. 둘째, Windows가 ARM에서는 x64보다 역사적 짐이 덜해서 ARM 빌드 자체가 더 효율적일 가능성도 있어 보였음. 결국 CPU 스로틀링이 너무 영리해져서 오히려 해가 되는 지점에 온 건지 궁금했음
  • 다만 이건 서버 OS를 데스크톱 x86 CPU에서 테스트한 사례라는 점을 같이 봐야 했음. AMD Epyc나 Intel Xeon 같은 x86 서버 CPU는 클럭 변동 범위가 더 작고 정책도 덜 공격적이라, 데스크톱 CPU보다 더 일정하고 예측 가능한 성능을 냄. 이런 특성은 멀티스레드 워크로드에 유리하고, 데스크톱 CPU는 단일 스레드 최고 성능을 위해 조정되다 보니 멀티스레드에는 오히려 손해가 날 수 있다고 봤음