코어 수가 많은 AArch64 시스템을 데스크톱으로 사용할 때 겪게 되는 멀티코어 활용의 장점과 단일 스레드 성능 부족 문제를 다룬 글입니다.
이 글은 "Let me try to use an AArch64 system as a desktop" 시리즈의 6번째 글입니다:
AArch64 코어가 80개인 시스템을 사용하는 것은 즐거울 수도 있습니다. 아니면 고통일 수도 있고요…
코어가 80개나 있다는 건 멋지게 들리지 않나요? 하지만 실제 사용에서는 그다지 그렇지 않습니다…
페도라 패키지를 빌드할 때는 정말 쏜살같이 진행됐습니다. 모든 코어를 사용하고, ccache 버퍼가 채워지고(재빌드의 경우), 128 GB RAM도 계속 사용되는 식이었죠 등등.
하지만 동시에 모든 코어에 100% 부하가 걸리면 Spotify로 음악을 듣거나 온라인 비디오를 보는 등의 일을 할 수 없었습니다. CPU 코어가 빌드 프로세스에 점유되어 있기 때문입니다.
각 fedpkg mockbuild 호출에 대해 cpu.max를 제한하려고 cgroups를 사용해 봤습니다. 큰 도움은 되지 않았습니다. 오디오는 여전히 끊겼습니다.
비교를 위해 말하자면, 저는 이 글을 Ryzen 5 3600 CPU가 장착된 시스템에서, 백그라운드로 패키지 빌드가 돌아가는 동안 작성했습니다. 열두 개의 CPU 스레드가 모두 100% 바쁘게 돌아가고 있었지만, 음악은 끊기지 않았습니다.
이 모든 것은 코어 수가 많은 CPU가 데스크톱 머신에는 그다지 좋은 선택이 아닐 수도 있음을 보여줍니다. 지연 시간, 스케줄러, 문맥 전환 — 이 모든 것이 데스크톱 사용자를 괴롭히기에 충분한 잡음을 만들어 냅니다.
Arm 프로세서는 많은 경우에 훌륭합니다. 순수한 단일 스레드 CPU 성능이 필요하지 않은 한에서는요.
이 점은 웹 브라우저에서 아주 두드러지게 느껴집니다. 예를 들어 Bitwarden은 눈에 띄는 지연 후에 잠금이 해제되지만, Ryzen 5 3600에서는 거의 즉시 됩니다. 그리고 “€100 예산으로 누가 더 빠른 PC를 만들까” 같은 YouTube 영상을 보고 난 뒤 같은 브라우저 벤치마크를 실행해서 더 나쁜 결과를 얻으면 체감은 더 심해집니다…
많은 소프트웨어 빌드도 이 문제를 부각합니다. 제 느낌에는 개발자들이 x86-64 아키텍처에서는 일반적인, 적은 수의 빠른 CPU 코어에 이미 익숙해졌고, 그 점을 당연하게 전제한 채 코드를 작성하는 것 같습니다.
그러고 나서 자신의 머신을 보면, 70개의 코어는 아무 일도 하지 않은 채 어떤 코드가 마침내 컴파일되거나 링크되기를 기다리고 있습니다. 저는 부트스트랩이 소스 파일 두 개로 이루어진 소프트웨어 패키지를 본 적이 있습니다. 둘 다 크기가 2 메가바이트를 넘었고 기계 생성 C 코드로 가득 차 있었습니다. 두 개의 코어는 꽤 오랫동안 바쁘게 유지됐지만, 나머지 78개는 기다려야 했습니다.
8년 전의 제 블로그 글 the “From the diary of AArch64 porter — parallel builds” 이후로 크게 달라진 것은 없습니다.
물론 모든 코어와 전체 메모리, 그리고 가능한 한 많은 스왑까지 가져다 쓰면서 거의 순식간에 마법 같은 일을 해내는 패키지도 있습니다. PrusaSlicer 패키지 빌드를 시작했을 때는 Firefox가 OOM 때문에 종료되어서 스왑을 좀 추가해야 했습니다. CPU 코어당 RAM이 2 GB보다 적다는 건 정말 끔찍합니다 ;D
데스크톱 시스템을 사용하는 데 많은 코어가 필요한 것은 아닙니다. 코어가 빠르기만 하다면요.
