'이 코드 느린데 왜 느린지 모르겠어요'의 정답지
우리가 짠 코드가 느릴 때, 흔히 '알고리즘 복잡도(빅오)'만 따지잖아요. O(n)이냐 O(n²)이냐. 그런데 똑같은 빅오인데도 어떤 코드는 10배 빠르고 어떤 건 느려요. 그 차이를 만드는 게 바로 '한 연산이 실제로 CPU에서 몇 사이클을 잡아먹느냐'예요. 한 C++ 성능 시리즈의 이번 글은, 현대 CPU에서 각종 연산이 대략 몇 클럭 사이클이 드는지를 인포그래픽으로 한눈에 정리했어요. 추상적인 빅오 아래에 깔린 '진짜 물리적 비용'을 보여주는 지도라고 생각하면 돼요.
연산마다 가격표가 이렇게나 다르다
핵심부터 말하면, 산술 연산은 대체로 싸고 메모리 접근은 비싸요. 정수 덧셈·뺄셈, 비트 연산 같은 건 보통 1 사이클 안팎이에요. 곱셈은 그보다 조금 비싸고요. 그런데 정수 나눗셈(division)으로 가면 갑자기 수십 사이클로 확 뛰어요. 그래서 베테랑들이 2로 나누는 걸 비트 시프트(>>)로 바꾸는 거예요. 부동소수점 연산도 더하기·곱하기는 빠른데 나누기와 제곱근은 비싸고요.
진짜 충격적인 건 메모리 계층이에요. CPU 바로 옆에 붙은 L1 캐시는 몇 사이클이면 읽어요. 그런데 한 단계 멀어진 L2는 그 몇 배, L3는 또 몇 배, 그리고 메인 메모리(RAM)까지 가면 수백 사이클이 날아가요. 즉 데이터가 캐시에 있느냐 RAM까지 다녀와야 하느냐에 따라 같은 변수 읽기가 100배 차이 날 수 있다는 뜻이에요. 그래서 "메모리 접근은 새로운 디스크 I/O"라는 말까지 나오는 거죠.
또 하나 비싼 게 분기 예측 실패(branch misprediction)예요. 현대 CPU는 if문 결과를 미리 '찍어서' 다음 명령을 앞당겨 실행하는데(파이프라이닝), 이 예측이 틀리면 했던 작업을 다 버리고 다시 시작해야 해서 십수 사이클을 손해 봐요. 데이터가 들쭉날쭉해서 예측이 자꾸 빗나가는 분기는, 차라리 분기 없이 계산하는 코드로 바꾸는 게 빠를 때도 있고요.
'Latency Numbers Every Programmer Should Know'의 계보
이런 류의 자료는 사실 계보가 있어요. 구글의 제프 딘이 정리한 '모든 프로그래머가 알아야 할 지연 시간 숫자'가 원조 격인데, 이번 글은 그 정신을 C++ 관점에서 'CPU 클럭 사이클' 단위로 더 잘게 쪼개 시각화한 버전이에요. 이게 중요한 이유는, 이 숫자들이 곧 데이터 지향 설계(Data-Oriented Design)의 근거이기 때문이에요. 객체를 여기저기 흩어놓는 대신 한 줄로 빽빽하게 모아두면(배열) 캐시 적중률이 올라가서 수 배 빨라진다는 게임 업계의 노하우가, 전부 이 '캐시는 싸고 RAM은 비싸다'는 숫자에서 나온 거거든요.
한국 개발자에게는?
물론 일반적인 웹 백엔드에서 이 정도 사이클 단위 최적화는 과해요. 거기선 DB 쿼리 한 번이 수백만 사이클이라 곱셈 몇 개는 의미가 없죠. 하지만 게임 엔진, 실시간 영상·오디오 처리, 고빈도 트레이딩, 데이터베이스 엔진, ML 추론 커널을 다룬다면 이건 생존 지식이에요. 똑같은 알고리즘인데 '메모리 접근 패턴'만 바꿔서 성능을 끌어올리는 일이 일상이거든요. 직접 최적화할 일이 없더라도, "왜 캐시 친화적으로 짜라고 하는가"의 근거를 숫자로 이해하면 코드를 보는 눈이 한 단계 깊어져요. 배열을 순서대로 도느냐 건너뛰며 도느냐 같은 사소해 보이는 선택이 왜 중요한지 몸으로 알게 되니까요.
마무리
빅오는 알고리즘의 비용을, 클럭 사이클은 현실의 비용을 알려줘요. 둘 다 봐야 진짜 성능이 보여요. 여러분은 최근에 '복잡도는 그대로인데 캐시 배치만 바꿔서' 코드가 빨라진 경험이 있나요?
🔗 출처: Hacker News