CPU 코어를 두 배로 늘렸는데 처리 시간이 절반이 되지 않습니다. Amdahl의 법칙은 무엇을 설명하나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
병렬화할 수 없는 구간과 추가 조정 비용이 전체 속도 향상을 제한합니다. 코어 수 증가가 모든 코드의 실행 시간을 같은 비율로 줄이지는 않습니다.
동작 원리와 전제
작업의 20%가 순차라면 병렬 구간을 무한히 빠르게 해도 이상적 속도 향상은 5배를 넘지 못합니다. 실제로는 락·메모리 대역폭·캐시·작업 분배·동기화 비용까지 있어 더 작을 수 있습니다.
선택과 실패 처리
CPU 프로파일과 대기 프로파일로 순차 병목을 찾고 작업 크기·분할·공유 상태를 조정합니다. 입력 크기가 늘 때 처리량을 확장하는 문제와 고정 작업 하나의 지연을 줄이는 문제도 구분합니다.
구체적인 사례와 검증
작업 분할 뒤 결과를 합치는 한 스레드가 오래 걸리면 worker를 늘릴수록 그 단계가 상대적으로 지배적이 됩니다. 공유 락·단일 DB·메모리 대역폭도 비슷한 제한을 만들 수 있습니다. 더 많은 worker가 캐시를 오염시키거나 NUMA 원격 접근을 늘리면 오히려 느려질 수 있습니다. 고정 입력의 latency를 줄이는 실험과 더 큰 입력을 같은 시간에 처리하는 throughput 실험을 구분합니다. 프로파일로 확인한 병목을 줄인 뒤 다시 측정해야 다음 제한을 알 수 있습니다. 이론적 상한은 선택을 돕는 모델이며 실제 시스템의 모든 비용을 정확히 예측하는 공식은 아닙니다.
코어·worker 수를 단계적으로 늘리며 CPU·실행 시간·락·메모리 대역폭을 측정합니다. 과도한 스레드는 context switch와 false sharing을 늘릴 수 있습니다. 병렬화 자체보다 어떤 구간을 줄일 수 있는지와 그 비용을 설명하겠습니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 핵심 구분: 병렬화할 수 없는 구간과 추가 조정 비용이 전체 속도 향상을 제한합니다.
- 선택 조건: CPU 프로파일과 대기 프로파일로 순차 병목을 찾고 작업 크기·분할·공유 상태를 조정합니다.
- 검증 기준: 코어·worker 수를 단계적으로 늘리며 CPU·실행 시간·락·메모리 대역폭을 측정합니다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- worker 수를 두 배로 늘리면 고정 작업의 실행 시간도 반드시 절반이 된다고 한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- worker 증가가 실제 계산 이득인지 스케줄링·대기 비용 증가인지 어떻게 구분하나요?
- 다른 필드를 갱신해도 cache line을 공유하면 어떤 병목이 생기나요?
- 낮은 CPU에서 긴 지연이 나타날 때 실행 시간과 대기 원인을 어떻게 분리하나요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.