파이프라인과 위험

세탁·건조·접기를 하는 동안 첫 옷의 작업을 모두 끝낸 뒤 다음 옷을 시작하면 장비가 많이 쉽니다. 단계가 다른 옷들을 겹쳐 처리하면 완료 간격을 줄일 수 있습니다. CPU의 파이프라인도 여러 명령의 다른 단계를 겹칩니다. 한 명령의 실행 시간이 더 짧아진다는 뜻은 아닙니다.

다섯 단계의 이상적 모델

IF(인출), ID(해독·레지스터 읽기), EX(계산), MEM(데이터 접근), WB(결과 기록)를 각 1사이클로 두고 단계 사이 레지스터에 중간 상태를 저장합니다. 명령 3개가 독립적이면 다음처럼 배치됩니다.

처음 I1은 5사이클 후 끝납니다. 이후 완료 간격은 이상적으로 1사이클입니다. k단계·n명령의 이상적 총 사이클은 k+n-1입니다. 파이프라인을 채우고 비우는 시간과 단계 레지스터 지연도 실제 계산에 필요합니다.

독립적이지 않으면 기다립니다

구조 위험은 두 작업이 같은 자원을 동시에 원할 때입니다. 단일 메모리 포트에 명령 인출과 데이터 읽기를 동시에 요구하는 사례가 있습니다. 자원 복제나 시간 배치 변경이 필요합니다.

데이터 위험은 다음 명령이 아직 기록되지 않은 결과를 필요로 할 때입니다. ADD R1,R2,R3 다음 SUB R4,R1,R5는 R1에 의존합니다. 전달(forwarding)은 결과를 기록 완료 전 필요한 계산 입력으로 보내는 방법입니다. 그러나 LOAD 값이 MEM 단계 끝에야 준비되는 모델에서 바로 다음 EX가 그 값을 원하면 전달만으로 부족해 정지가 필요할 수 있습니다. 구체적 시점에 따라 계산해야 합니다.

제어 위험은 분기 결과가 아직 결정되지 않았는데 다음 명령을 가져왔을 때입니다. 기다리거나 예측할 수 있습니다. 틀린 예측이면 잘못 가져온 경로의 결과가 외부에 확정되지 않게 처리하고 다시 시작해야 합니다. 뒤 명령을 제거하는 flush와 한 단계를 기다리는 stall은 다른 동작입니다.

시간과 사이클을 함께 계산하기

비파이프라인 한 명령 10 ns, 5단계 파이프라인의 클록 2.5 ns라고 합시다. 독립 명령 20개의 시간은 전자가 200 ns, 후자가 (5+20-1)×2.5=60 ns입니다. 속도 향상은 약 3.33배입니다. 단계 수 5와 같지 않습니다. 정지가 합계 4사이클이면 70 ns입니다.

def pipeline_cycles(instructions, stages, stalls=0):
    if instructions < 0 or stages <= 0 or stalls < 0:
        raise ValueError("모델 입력 범위를 확인하세요")
    return 0 if instructions == 0 else instructions + stages - 1 + stalls

assert pipeline_cycles(3, 5) == 7
assert pipeline_cycles(20, 5, 4) * 2.5 == 70
assert pipeline_cycles(0, 5) == 0

독립 문제: 이상적 처리량의 한계

4단계 파이프라인에 8명령을 넣고 클록 주기는 3 ns입니다. 총 정지가 2사이클이면 시간은 얼마인가요? 한 명령의 이상적 지연과 명령 완료 간격도 구하세요. LOAD R1 뒤에 ADD R2,R1,R3이 있으면 무조건 정지가 0이라고 해도 될까요?

힌트

채우기 비용과 정지를 모두 넣으세요. LOAD 결과 준비 시점을 문제에서 아직 주지 않았습니다.

풀이

총 사이클은 4+8-1+2=13, 시간은 39 ns입니다. 이상적 한 명령 지연은 12 ns, 충분히 채운 뒤 완료 간격은 3 ns입니다. LOAD→ADD의 정지 수는 값 준비·전달 경로와 필요한 시점이 없어서 확정할 수 없습니다. “전달이 있으니 모든 위험이 사라진다”는 오개념을 피하세요.

중간 상태가 낯설면 레지스터와 데이터 경로를 다시 연결하세요. 다음 load-use 시간표는 준비·소비 시점을 고정하고 PC·IF/ID 유지와 bubble을 끝까지 추적합니다.