원문 보기: https://dawoum.duckdns.org/wiki/Pipeline_(computing)
컴퓨팅에서, 파이프라인은, 데이터 파이프라인이라고도 알려져 있으며, 직렬로 연결된 일련의 데이터 처리 요소로, 여기서 한 요소의 출력이 다음 요소의 입력이 됩니다. 파이프라인의 요소는 종종 병렬로 또는 시간-분할 방식으로 실행됩니다. 일부 버퍼 스토리지의 총양은 종종 요소 사이에 삽입됩니다.
Concept and motivation
파이프라인은 일상생활에서 흔히 사용되는 개념입니다. 예를 들어, 자동차 공장의 조립 라인에서 엔진 설치, 후드 설치, 및 휠 설치와 같은 각각의 특정 작업은 종종 별도의 작업 스테이션에서 수행됩니다. 스테이션은 각각 다른 차량에서 병렬로 작업을 수행합니다. 차량이 한 가지 작업을 수행하면 다음 스테이션으로 이동합니다. 작업을 완료하는 데 필요한 시간의 변화는 "버퍼링" (스테이션 사이의 공간에 하나 이상의 차량을 고정) 및/또는 "스톨링" (상류 스테이션을 일시적으로 중단)함으로써 다음 스테이션이 사용 가능해질 때까지 수용될 수 있습니다.
자동차 한 대를 조립하는 데 각각 20분, 10분, 및 15분이 걸리는 세 가지 작업이 필요하다고 가정해 보십시오. 그러면, 세 가지 작업을 모두 하나의 스테이션에서 수행한다면 공장은 45분마다 자동차 한 대를 생산할 것입니다. 세 개의 스테이션으로 구성된 파이프라인을 사용함으로써, 공장은 45분 만에 첫 번째 자동차를 생산하고, 그다음 매 20분마다 새 자동차를 생산할 것입니다.
이 예에서 알 수 있듯이, 파이프라인은 대기 시간, 즉, 한 항목이 전체 시스템을 통과하는 데 걸리는 총 시간을 줄이지 않습니다. 그것은, 어쨌든, 시스템의 처리량, 즉, 첫 번째 항목 이후에 새 항목이 처리되는 율을 증가시킵니다.
In computing
컴퓨팅에서, 파이프라인 또는 데이터 파이프라인은 직렬로 연결된 데이터 처리 요소의 집합으로, 여기서 한 요소의 출력은 다음 요소의 입력입니다. 파이프라인의 요소는 종종 병렬로 또는 시간-분할 방식으로 실행됩니다. 일부 버퍼 스토리지의 총양은 종종 요소 사이에 삽입됩니다.
컴퓨터-관련 파이프라인은 다음과 같습니다:
- 명령 파이프라인(Instruction pipelines)은 중앙 처리 장치 (CPU) 및 기타 마이크로프로세서에서 같은 회로로 여러 명령을 중복하여 실행할 수 있도록 하는 클래식 RISC 파이프라인과 같은 것입니다. 회로는 보통 여러 단계로 나뉘고 각 단계는 한 번에 한 명령의 특정 부분을 처리하여 부분 결과를 다음 단계로 전달합니다. 단계의 예로는 명령 디코드, 산술/논리 및 레지스터 페치가 있습니다. 그것들은 수퍼스칼라 실행, 피연산자 전달, 추측 실행, 및 비순차 실행 기술과 관련이 있습니다.
- 그래픽 파이프라인은, 대부분의 그래픽 처리 장치 (GPU)에서 발견되며, 이는 여러 개의 산술 장치, 또는 완전한 CPU로 구성되어, 공통적인 렌더링 작업의 다양한 단계 (원근 투영, 윈도우 클리핑, 색상 및 조명 계산, 렌더링 등)를 구현합니다.
- 소프트웨어 파이프라인은 일련의 컴퓨팅 프로세스 (명령, 프로그램 실행, 작업, 스레드, 프로시저, 등)로 구성되며, 개념적으로 병렬로 실행되고, 한 프로세스의 출력 스트림이 자동으로 다음 프로세스의 입력 스트림으로 공급됩니다. 유닉스 시스템 호출 파이프는 이 개념의 전형적인 예입니다.
- HTTP 파이프라인은 이전 요청에 대해 새로운 요청을 보내기 전에 완료하는 것을 기다림 없이 같은 TCP 연결을 통해 여러 HTTP 요청을 보내는 기술입니다.
Design considerations
Balancing the stages
파이프라인의 처리량은 가장 느린 요소의 처리량보다 더 좋을 수 없으므로, 설계자는 작업과 자원을 단계 사이에 나누어 모든 단계가 작업을 완료하기 위해 같은 시간이 걸리도록 해야 합니다. 위의 자동차 조립 예에서, 세 가지 작업에 각각 20, 10, 15분이 아니라, 각각 15분이 걸리면, 대기 시간은 여전히 45분이 되지만, 새로운 자동차는 20분이 아니라 15분마다 완성됩니다.
Buffering
이상적인 상황 아래에서, 모든 처리 요소가 동기화되고 처리하기 위해 같은 시간의 총양이 걸면, 각 항목은 단일 클록 주기에서 이전 항목에서 출시되는 것과 마찬가지로 각 요소에 의해 수신될 수 있습니다. 이런 방식으로, 항목은 수로의 파동처럼 일정한 속도로 파이프라인을 통해 흐릅니다. 그러한 "파동 파이프라인"에서, 동기화나 버퍼링은 데이터 항목에 필요한 저장 외에 단계 사이에 필요하지 않습니다.
보다 일반적으로, 파이프라인 단계 사이의 버퍼링은 처리 시간이 불규칙할 때, 또는 파이프라인을 따라 항목이 생성되거나 파괴될 때 필요합니다. 예를 들어, 화면에 렌더링될 삼각형을 처리하는 그래픽 파이프라인에서, 각 삼각형의 가시성을 확인하는 요소는 삼각형이 보이지 않으면 삼각형을 버리거나, 부분적으로 숨겨지면 요소의 두 개 이상의 삼각형 조각을 출력할 수 있습니다. 버퍼링은 역시 응용 프로그램이 첫 번째 단계에 항목을 공급하고 마지막 단계의 출력을 사용하는 속도의 불규칙성을 수용하기 위해 필요합니다.
두 단계 사이의 버퍼는 단순히 두 단계 사이에 적절한 동기화 및 신호 논리를 갖는 하드웨어 레지스터일 수 있습니다. 단계 A가 레지스터에 데이터 항목을 저장할 때, 그것은 다음 단계 B에 "데이터 사용 가능" 신호를 보냅니다. 일단 B가 해당 데이터를 사용해 왔으면, 그것은 A에 "데이터 수신" 신호로 응답합니다. 단계 A는 다음 데이터 항목을 레지스터에 저장하기 전에 이 신호를 기다리며 멈춥니다. 단계 B는 다음 항목을 처리할 준비가 되었지만 단계 A가 아직 제공하지 않으면 "데이터 사용 가능" 신호를 기다리며 멈춥니다.
만약 요소의 처리 시간이 가변적이면, 전체 파이프라인이 종종 중지되어, 해당 요소와 이전의 모든 요소가 입력 버퍼의 항목을 소비할 때까지 기다려야 할 수 있습니다. 그러한 파이프라인 정지 빈도는 해당 단계의 입력 버퍼에 두 개 이상의 항목을 위한 공간을 제공함으로써 줄일 수 있습니다. 그러한 다중-항목 버퍼는 보통 선입 선출 대기열로 구현됩니다. 대기열이 가득찰 때 업스트림 단계는 중지되어야 할 수도 있지만, 더 많은 버퍼 슬롯이 제공됨에 따라 그것들 이벤트의 빈도는 감소합니다. 대기열 이론은 처리 시간의 가변성과 원하는 성능에 따라 필요한 버퍼 슬롯 수를 알려줄 수 있습니다.
Nonlinear pipelines
만약 어떤 단계가 다른 단계보다 훨씬 오래 걸리고 (또는 걸릴 수 있고), 속도를 높일 수 없으면, 설계자는 단일 입력 버퍼와 단일 출력 버퍼를 갖는 두 개 이상의 처리 요소를 제공하여 해당 작업을 병렬로 수행할 수 있습니다. 각 요소가 현재 데이터 항목을 처리하는 것을 마칠 때, 그것은 공통 출력 버퍼에 전달하고, 공통 입력 버퍼에서 다음 데이터 항목을 가져옵니다. 이러한 "비-선형" 또는 "동적" 파이프라인 개념은 두 명 이상의 계산원이 단일 대기 큐에서 고객에게 서비스를 제공하는 상점이나 은행에 의해 예시됩니다.
Dependencies between items
일부 응용 프로그램에서, 단계 A에 의한 항목 Y의 처리가 파이프라인의 이후 단계 B에 의한 이전 항목 X를 처리하는 것의 결과 또는 효과에 따라 달라질 수 있습니다. 해당 경우에서, 단계 A는 항목 X가 단계 B를 통과할 때까지 항목 Y를 올바르게 처리할 수 없습니다.
이러한 상황은 명령어 파이프라인에서 매우 자주 발생합니다. 예를 들어, Y가 이전 명령어 X에 의해 수정된 것으로 가정된 레지스터의 컨텐츠를 읽는 산술 명령어라고 가정합니다. A를 명령어 피연산자를 페치하는 단계로 놓고 B를 지정된 레지스터에 결과를 쓰는 단계로 놓습니다. 만약 명령어 X가 B 단계에 도달하기 전에 A 단계가 명령어 Y를 처리하려고 하면, 레지스터에 여전히 이전 값이 있을 수 있고, Y의 효과는 올바르지 않습니다.
이러한 충돌을 올바르게 처리하기 위해, 파이프라인에 충돌을 감지하고 적절한 조치를 취하는 추가 회로 또는 논리가 제공되어야 합니다. 이것을 하기 위한 전략은 다음과 같습니다:
- Stalling: A와 같이 영향을 받는 모든 각 단계는 종속성이 해결될 때까지 중지됩니다—즉, 필요한 정보를 사용할 수 있고/있거나 필요한 상태가 달성될 때까지 중지됩니다.
- Reordering items: 정지하는 대신, 단계 A는 항목 Y를 제쳐두고 임의의 이전 항목과 보류 중인 종속성이 없는 입력 스트림에서 후속 항목 Z를 찾을 수 있습니다. 명령어 파이프라인에서, 이 기술은 비순차적 실행이라고 불립니다.
- Guess and backtrack: 항목-과-항목 종속성의 한 가지 중요한 예는 명령어 파이프라인에 의한 조건부 분기 명령어 X의 처리입니다. 실행될 다음 명령어 Y를 페치하는 파이프라인의 첫 번째 단계 A는 X가 피연산자를 페치하고 분기가 수행될지 여부를 결정할 때까지 작업을 수행할 수 없습니다. X의 피연산자는 주요 메모리에서 데이터를 페치하는 이전 명령어에 따라 달라질 수 있기 때문에, 여러 클록 사이클이 걸릴 수 있습니다.
X가 완료될 때까지 기다리는 동안 멈추는 대신, 단계 A는 분기가 수행될지 여부를 추측하고, 그 추측에 따라 다음 명령어 Y를 페치할 수 있습니다. 만약 나중에 추측이 틀렸다고 판명되면 (희망적으로는 드물지만), 시스템은 뒤로 돌아가서 올바른 선택으로 재개해야 합니다. 즉, 스테이지 A와 그 추측에 따라 후속 스테이지에서 기계 상태에 대해 변경한 모든 내용을 취소하고, 파이프라인에 이미 있는 X 다음의 명령어를 플러시하고, 스테이지 A는 올바른 명령어 포인터로 다시 시작해야 합니다. 이 분기 예측 전략은 추측 실행의 특별한 경우입니다.
Typical software implementations
효과적으로 구현하기 위해, 데이터 파이프라인에는 작업을 사용 가능한 CPU 코어로 전송하기 위한 CPU 스케줄링 전략과 파이프라인 단계가 작동할 데이터 구조의 사용이 필요합니다. 예를 들어, 유닉스 파생 제품은 운영 시스템에 의해 구현된 파이프를 사용하여 다양한 프로세스의 표준 IO를 연결하는 명령을 파이프라인으로 연결할 수 있습니다. 일부 운영 시스템은 파이프라인에서 여러 프로그램 실행을 문자열로 묶는 유닉스-계열 구문을 제공하지만, 후자를 진정한 파이프라인이 아닌 간단한 직렬 실행으로 구현할 수 있습니다—즉, 다음 프로그램을 시작하기 전에 각 프로그램이 완료될 때까지 기다립니다.
하위 수준 접근 방식은 운영 시스템에 의해 제공되는 스레드에 의존하여 단계별 작업을 예약할 수 있습니다: 스레드 풀-기반 구현이나 단계-별-스레드-하나 둘 다는 실행 가능하고, 존재합니다.
협동적 멀티태스킹에 의존하는 다른 전략이 존재하며, 여기에는 코루틴 기반 프레임워크를 갖는 라운드 로빈 스케줄러를 사용하는 것과 같은 실행의 다중 스레드가 필요하지 않고 따라서 추가적인 CPU 코어가 필요하지 않습니다. 이 맥락에서, 각 단계는 자체 코루틴으로 인스턴스화될 수 있으며, 라운드 작업을 완료한 후 스케줄러에 제어권을 넘깁니다. 이 접근 방식은 프로세스의 단계를 신중하게 제어하여 시간 슬라이스를 남용하지 않도록 해야 할 수 있습니다.
Costs and drawbacks
파이프라인 시스템은 전형적으로 한 번에 하나의 일괄 처리를 실행하는 시스템보다 더 많은 자원 (회로 요소, 처리 장치, 컴퓨터 메모리, 등)가 필요한데, 왜냐하면 그 단계에서 그것들의 자원을 공유할 수 없기 때문이고, 요소 사이에 버퍼링과 추가 동기화 논리가 필요할 수 있기 때문입니다.
게다가, 분리된 처리 요소 사이에 항목의 전송은 지연 시간이 길어질 수 있으며, 특히 파이프라인이 긴 경우 더 그렇습니다.
파이프라인의 추가적인 복잡성 비용은 서로 다른 항목의 처리 사이에 종속성이 있으면 상당할 수 있으며, 특히 추측-과-백트랙 전략이 그것들을 처리에 사용되면 더욱 그렇습니다. 실제로, 복잡한 명령어 집합에 대한 해당 전략을 구현하는 데 드는 비용은 RISC 및 VLIW와 같은 컴퓨터 아키텍처를 단순화하기 위한 일부 급진적인 제안을 촉진했습니다. 컴파일러는 역시 명령어 파이프라인의 성능을 개선하기 위해 기계 명령어를 재배열하는 작업으로 부담을 받았습니다.
New technologies
최근 몇 년 동안 응용 프로그램과 기반 하드웨어에 대한 요구 사항이 상당했던 것은 사실입니다. 예를 들어, 행 단위로 데이터를 트롤링하는 단일 노드 응용 프로그램으로 파이프라인을 구축하는 것은 더 이상 빅데이터의 양과 다양성으로 인해 실행 가능하지 않습니다. 어쨌든, Hadoop 또는 더 최근에는 Apache Spark와 같은 데이터 분석 엔진이 등장하면서, 대용량 데이터 집합을 여러 처리 노드에 분산하여 응용 프로그램이 이전에 가능하다고 생각했던 것보다 수백 배 더 높은 효율성에 도달할 수 있게 되었습니다. 오늘날 이러한 효과로 인해 이러한 방식으로 분산 처리를 사용하는 중급 PC조차도 빅데이터 파이프라인을 구축하고 실행할 수 있습니다.
Bibliography
- Perez Garcia, Pablo (2018). Pipeline DSL a dsl to create a CI/CD pipeline for your projects. Addison-Wesley. ISBN 978-0-134-69147-3.
- For a standard discussion on pipelining in parallel computing see Quinn, Michael J. (2004). Parallel Programming in C with MPI and openMP. Dubuque, Iowa: McGraw-Hill Professional. ISBN 0072822562.
- Pogonyi, Roland (February 2021). "What is a Data Pipeline?". Retrieved March 11, 2021.