CPU 100%인데 실제 retire는 16%: DRAM 50-100ns 지연이 GROUP BY 쿼리를 3.9초로 만든 이유

우리 회사 다른 팀은 STM32MP1에서 메시지 패싱, 깊게 중첩된 C++ 가상 메서드, 큰 DOM, STL 컨테이너를 쓰고 있음. in-order Cortex-A7에 캐시도 형편없는 칩인데. 우리 팀은 1MB도 안 되는 RAM의 STM32H5에서 인라인 할당하는 커스텀 STL 컨테이너랑 2000년대 게임처럼 index+generation 링크 쓰는 오브젝트 풀을 직접 만들어 씀. 벤치마크 숫자로 내가 저쪽 병목이 아니라는 걸 증명해야 했음.

게임 업계에도 그런 시스템 프로그래머가 있는데 다들 나이가 들었고 젊은 세대는 관심이 없음. 기술이 Unreal Engine 5로 획일화되는 게 아쉽더라.

캐시 친화적으로 데이터 구조를 바꾸자는 코드 리뷰에 'premature optimization'이라는 반대를 들었음. 성능 차이가 크고 실제 병목이라는 걸 벤치마크로 미리 증명했는데도. Clean Code가 유행하던 시기라 2010년대에 어떤 미적 기준이 객관적으로 옳다고 믿게 된 게 문제인 듯.

캐시가 형편없는 시스템에선 mechanical sympathy가 캐시 친화성을 뜻하지 않을 수도 있음. 캐시가 없으면 어느 바이트든 접근 비용이 같으니 linked list가 오히려 합리적인 선택이었음.

3주 동안 소프트웨어를 L1 캐시에 전부 들어가게 줄였는데 성능이 놀라웠음. 1970년대 기술을 현대 CPU에서 돌린 건데 제대로 쓰면 기적을 만든다.

프로그램은 문제가 아니라 해법을 표현해야 한다는 말이 와닿음.

Zig 프로그래머들이 allocator를 인자로 넘기는 걸 왜 즐기는지 이제 알겠음. 할당의 무게를 코드에서 몸으로 느끼게 하는 게 mechanical sympathy고, 그게 코드를 칩이 하는 일에 가깝게 만드는 거임.

Ulrich Drepper의 'What Every Programmer Should Know About Memory'를 2026년판으로 다시 쓴 사람 없나.

기사에서 제시한 해법은 결국 clustered hashmap, locality sensitive 해싱 아닌가. 그래도 orders of magnitude 개선은 아님.

flamegraph를 좋아하는데 perf로 만드는 사람들이 많음. 이제 LLM이 있으니 에이전트한테 어셈블리랑 PMU 카운터를 같이 보게 시키면 좋겠음.

이거 그냥 radix-partitioned aggregation 아님? 2단계 계층 집계는 오래된 기법인데 뭐가 새로운 건지 모르겠음. DuckDB도 ClickHouse도 있는데 이 프로젝트가 왜 존재하는지 이해가 안 됨.

새롭다고 주장한 게 아님. 캐시 친화적 데이터 구조가 얼마나 차이를 만드는지 독자가 감을 잡게 해주는 설명 글임.

기사에도 'radix partitioning'이라고 직접 써 있음. novelty 주장이 아니라 최적화 설명 글임.

현대 CPU 캐시가 수백 MB면 1990년대 윈도우 하드디스크 전체보다 큼. 캐시 안에 윈도우를 통째로 에뮬레이션할 수도 있는데 컴퓨터는 여전히 느림. RAM 기다리는 시간에다 수십 년간 추상화를 효율보다 우선한 결과임.