Qwen3.5-0.8B를 순수 어셈블리어로 구동해 봄

이력서에 쓰기엔 확실히 좋아 보이겠네! 요즘 같은 시대에 좋은 컴파일러가 코드를 최적화하게 두는 것보다 어셈블리로 코딩하는 게 무슨 장점이 있어?

아니, 사실 그렇지 않아.

아주 특수한 경우에만 그렇지.

매우 특수한 코드 요구 사항이 필요하겠지. "좋은" 소식은 대규모 시스템의 대부분의 최적화는 아키텍처 수준에서 이루어지는데, 컴파일러는 그 부분에 능숙하지 않다는 거야. 코드가 자기 자신과 어떻게 상호작용하는지, 그리고 실행 중에 무엇을 하는지에 대한 높은 수준의 통찰이 필요하거든. 전역 최적화도 한계가 있고.

"컴파일러가 내뱉는 결과물보다 더 빠르게 어셈블리를 짤 수 있는가"라는 질문에 대해, 아키텍처 부분을 무시하고 말하자면: 거의 절대 아니야. 오늘날에도 훌륭한 컴파일러조차 제대로 해내지 못하는 고도로 수작업 최적화된 코드베이스들이 존재하긴 해. 당장 빠른 압축 유틸리티나 비디오/오디오 인코더 같은 것들을 봐. 내가 아는 한, 그런 것들은 꽤 공통적인 패턴을 가지고 있어. 거대한 데이터 스트림으로 변환하는 작업이 엄청나게 많다는 거지. 그런 경우의 수작업 최적화는 데이터를 존재하는 SIMD/NEON 스타일 레지스터에 아주 잘 맞도록 미리 처리하고 루프 사이클을 최대한 타이트하게 만드는 걸 포함해.

표면적으로는 가중치 파싱도 그런 예시 중 하나처럼 들릴 수 있지만, 본질적으로 너무나 많은 무작위성이 있어서 그렇게 적합하다고는 생각 안 해. 본질적으로 거대한 데이터 바다로 분기되는 구조라 L2 캐시에 그 데이터들을 다 집어넣을 수도 없을 거고, 결국 명령어 효율이 어떻든 간에 메모리 읽기 지연(cold memory reads)이 발목을 잡을 거야.