스트림 처리

컴퓨터 과학에서 스트림 처리(이벤트 스트림 처리, 데이터 스트림 처리 또는 분산 스트림 처리라고도 함)는 데이터 스트림 또는 시간의 이벤트 시퀀스를 계산의 중앙 입출력 개체로 보는 프로그래밍 패러다임입니다.스트림 처리에는 데이터 흐름 프로그래밍, 사후 대응 프로그래밍 및 분산 데이터 ^[1]처리가 포함됩니다.스트림 처리 시스템은 데이터 스트림에 대한 병렬 처리를 노출하는 것을 목표로 하며 효율적인 구현을 위해 스트리밍 알고리즘에 의존합니다.이러한 시스템의 소프트웨어 스택에는 계산을 표현하기 위한 프로그래밍 모델 및 쿼리 언어, 배포 및 스케줄링하기 위한 스트림 관리 시스템 및 가속화를 위한 부동 소수점 장치, 그래픽 처리 장치 및 필드 프로그래밍 가능한 게이트 ^[2]어레이 등의 하드웨어 구성요소가 포함됩니다.

스트림 처리 패러다임은 실행할 수 있는 병렬 계산을 제한함으로써 병렬 소프트웨어와 하드웨어를 단순화합니다.일련의 데이터(스트림)가 주어지면 일련의 연산(커널 함수)이 스트림의 각 요소에 적용됩니다.커널 함수는 보통 파이프라인 처리되며 대역폭 손실을 최소화하기 위해 외부 메모리 상호작용에 관련된 최적의 로컬 온칩 메모리 재사용이 시도됩니다.스트림의 모든 요소에 하나의 커널 기능이 적용되는 균일한 스트리밍이 대표적입니다.커널 및 스트림 추상화는 데이터 의존성을 노출하기 때문에 컴파일러 도구는 온칩 관리 태스크를 완전히 자동화 및 최적화할 수 있습니다.스트림 처리 하드웨어는 스코어보드를 사용하여 종속성이 알려지면 DMA(Direct Memory Access)를 시작할 수 있습니다.수동 DMA 관리를 통해 소프트웨어의 복잡성을 줄이고 하드웨어 캐시 I/O를 제거함으로써 산술 로직 유닛 등의 특수한 연산 유닛에 의한 서비스에 관여해야 하는 데이터 영역을 줄일 수 있습니다.

1980년대에는 데이터 흐름 프로그래밍 내에서 스트림 프로세싱이 탐구되었습니다.예를 들어 SISAL(Streams and Repeating in a Single Assignment Language)이라는 언어가 있습니다.

적용들

스트림 처리는 기본적으로 데이터 중심 모델에 의한 타협입니다.데이터 중심 모델은 기존의 DSP 또는 GPU 타입의 애플리케이션(이미지, 비디오, 디지털 신호 처리 등)에 매우 적합하지만, 보다 랜덤화된 데이터 액세스(데이터베이스 등)에 의한 범용 처리에는 적합하지 않습니다.모델의 유연성을 일부 희생함으로써 그 영향은 보다 쉽고, 빠르고, 효율적인 실행을 가능하게 합니다.상황에 따라서는, 프로세서 설계를 최대한의 효율로 조정하거나, 유연성을 균형 있게 조정하거나 할 수 있습니다.

스트림 처리는 다음 3가지 애플리케이션 ^{[citation needed]}특성을 나타내는 애플리케이션에 특히 적합합니다.

• Compute Intensity는 I/O 또는 글로벌 메모리 참조당 산술 연산 수입니다.오늘날 많은 신호 처리 애플리케이션에서는 50:1이 훨씬 넘고 알고리즘의 복잡성과 함께 증가합니다.
• 입력 스트림의 모든 레코드에 동일한 기능이 적용되어 이전 레코드의 결과를 기다리지 않고 다수의 레코드를 동시에 처리할 수 있는 경우 커널에 데이터 병렬이 존재합니다.
• Data Locality는 신호 및 미디어 처리 애플리케이션에서 일반적으로 사용되는 특정 유형의 시간적 로컬리티입니다. 여기서 데이터는 한 번 생성되고 나중에 한두 번 읽으면 다시 읽지 않습니다.커널 함수 내의 중간 데이터뿐만 아니라 커널 간에 전달되는 중간 스트림은 스트림 처리 프로그래밍 모델을 사용하여 이 로컬리티를 직접 캡처할 수 있습니다.

스트림 내 레코드의 예는 다음과 같습니다.

• 그래픽스에서 각 레코드는 삼각형의 정점, 법선 및 색상 정보일 수 있습니다.
• 화상 처리에서는, 각 레코드가 화상의 1 픽셀이 되는 경우가 있습니다.
• 비디오 인코더에서는, 각 레코드는 데이터의 매크로 블록을 형성하는 256 픽셀이 될 수 있습니다.또는
• 무선 신호 처리에서는, 각 레코드는 안테나로부터 수신한 샘플의 시퀀스가 될 수 있습니다.

각 레코드에 대해 입력에서 읽고, 해당 레코드에서 작업을 수행하고, 출력에 쓸 수만 있습니다.복수의 입력과 복수의 출력을 가지는 것은 허용되지만, 판독 가능한 메모리와 기입 가능한 메모리는 사용할 수 없습니다.

예

예를 들어 다음 코드 fragment는 이벤트스트림 내의 패턴 검출을 나타내고 있습니다.첫 번째 예는 연속 SQL 쿼리(타임스탬프 및 창 기간을 기반으로 도착하는 데이터를 영구적으로 처리하는 쿼리)를 사용하여 데이터 스트림을 처리하는 예입니다.이 코드 조각은 두 데이터 스트림의 JOIN을 나타냅니다. 하나는 주식 주문용이고 다른 하나는 주식 거래용입니다.쿼리는 주문이 발행된 후 1초 이내에 거래와 일치하는 모든 주문 스트림을 출력합니다.출력 스트림은 타임스탬프(이 경우 Orders 스트림의 타임스탬프)별로 정렬됩니다.

선택한다. 데이터 스트림    주문.타임스탬프, 주문.orderId, 주문.티커,    주문.양, 거래.양 부터 주문 합류하다 거래 오버 (범위 간격 '1' 둘째 다음에 나오는) 온 주문.orderId = 거래.orderId; 

또 다른 샘플 코드 조각은 교회 종소리, 턱시도나 모닝슈트를 입은 남자의 등장, 흐르는 하얀 가운을 입은 여자, 공중을 날아다니는 쌀과 같은 외부 "이벤트"의 흐름 속에서 결혼식을 감지한다."복잡한" 또는 "복합적인" 이벤트는 개인의 단순한 이벤트에서 파생되는 것입니다: 결혼식이 일어나고 있습니다.

언제 사람인.성별 동등. '남자' 그리고. 사람인.옷이요. 동등. '도' 따랐다-타고   사람인.옷이요. 동등. "실패" 그리고.   (Church_벨 또는 밥_날다) 이내에 2 몇시간. 액션. 웨딩. 

이전 병렬 패러다임과의 비교

기본 컴퓨터는 순차적 실행 패러다임에서 출발했다.기존 CPU는 SISD 기반입니다.즉, 개념적으로는 한 번에 1개의 동작만 수행합니다.세계의 컴퓨팅 요구가 진화함에 따라 관리해야 할 데이터의 양은 매우 빠르게 증가했습니다.순차적 프로그래밍 모델은 처리 능력에 대한 증가하는 요구에 대처할 수 없는 것이 분명했습니다.많은 양의 계산을 수행할 수 있는 대체 방법을 찾기 위해 다양한 노력을 기울였지만 유일한 해결책은 어느 정도의 병렬 실행을 이용하는 것이었습니다.이러한 노력의 결과는 (다른) 데이터의 여러 인스턴스에 하나의 명령을 적용할 수 있는 프로그래밍 패러다임인 SIMD였습니다.대부분의 경우 SIMD는 SWAR 환경에서 사용되고 있었습니다.보다 복잡한 구조를 사용함으로써 MIMD 병렬화도 가능합니다.

이러한 두 가지 패러다임은 효율적이긴 했지만, 실제 구현에서는 메모리 정렬 문제에서 동기화 문제 및 제한된 병렬 처리 문제까지 제약으로 인해 어려움을 겪었습니다.독립형 컴포넌트로 살아남은 SIMD 프로세서는 거의 없었습니다.대부분이 표준 CPU에 내장되어 있었습니다.

4성분 벡터 100개(총 400개)를 포함하는 어레이 2개를 추가하는 간단한 프로그램을 생각해 보십시오.

종래의 순차적 패러다임

위해서 (인트 i = 0; i < > 400; i++)     결과[i] = 소스 0[i] + 소스1[i]; 

이것이 가장 친숙한 순차적 패러다임이다.변화(예: 내부 루프, 구조 등)는 존재하지만, 결국 그 구조로 귀결됩니다.

병렬 SIMD 패러다임, 패킹 레지스터(SWAR)

위해서 (인트 엘 = 0; 엘 < > 100; 엘++) // 각 벡터에 대해     벡터_섬(결과[엘], 소스 0[엘], 소스1[엘]); 

이것은 사실 지나치게 단순합니다.이 명령어는 다음과 같이 가정한다.vector_sum이것이 명령어 본질에서 일어나는 일이지만 벡터 구성요소의 수나 데이터 형식과 같은 많은 정보는 실제로 고려되지 않습니다.이것은 명확하게 하기 위해서 행해집니다.

단, 이 메서드는 numElements* componentsPerElement에서 numElements로 디코딩된 명령의 수를 줄입니다.루프가 더 적게 실행되므로 점프 명령의 수도 감소한다.이러한 이득은 네 가지 수학적 연산을 병렬로 실행함으로써 발생합니다.

그러나 실제로는 패킹된 SIMD 레지스터에 일정량의 데이터가 저장되어 있기 때문에 더 이상의 병렬 처리를 얻을 수 없습니다.속도 향상은 4개의 병렬 작업을 수행한다는 가정으로 인해 다소 제한적입니다(이는 AltiVec과 SSE 모두에 공통적으로 적용됩니다).

병렬 스트림 패러다임(SIMD/MIMD)

// 데모용 가상 언어입니다. 요소들 = 배열 스트림 요소([번호, 번호])[100] 커널 = 사례 streamKernel("@param0[@iter]") 결과 = 커널.호출하다(요소들) 

이 패러다임에서는 각 구성 요소 블록을 개별적으로 정의하는 것이 아니라 전체 데이터 세트가 정의됩니다.데이터 세트를 설명하는 것은 처음 두 행에 있는 것으로 가정합니다.그 후 소스와 커널에서 결과를 추론합니다.단순화를 위해 입력 데이터와 출력 데이터 간에 1:1 매핑이 있지만 반드시 매핑할 필요는 없습니다.또한 적용된 커널은 훨씬 더 복잡할 수 있습니다.

이 패러다임을 구현하면 내부적으로 루프를 "언롤"할 수 있습니다.따라서 칩의 복잡성에 따라 스루풋을 확장할 수 있으며 수백 개의 ^[3][4]ALU를 쉽게 활용할 수 있습니다.복잡한 데이터 패턴을 배제함으로써 이러한 추가 전력의 대부분을 사용할 수 있게 됩니다.

스트림 처리는 SIMD/MIMD 처리의 일부이지만 혼동해서는 안 됩니다.SIMD 구현은 종종 "스트리밍" 방식으로 동작할 수 있지만, 그 성능은 비교할 수 없습니다. 즉, 모델은 자체에서 훨씬 더 뛰어난 성능을 제공하는 매우 다른 사용 패턴을 구상하고 있습니다.

표준 CPU와 같은 범용 프로세서에 적용하면 1.5배의 속도밖에 얻을 ^[5]수 없다는 점에 유의하고 있습니다.반면 애드혹 스트림 프로세서는 10배 이상의 퍼포먼스를 쉽게 얻을 수 있습니다.이는 주로 메모리 액세스 효율과 병렬 처리 레벨이 ^[6]높기 때문입니다.

모델에 따라 다양한 수준의 유연성이 허용되지만 스트림 프로세서는 보통 커널 또는 스트림 크기에 몇 가지 제한을 가합니다.예를 들어, 소비자용 하드웨어는 고정밀 계산을 수행할 수 있는 능력이 없거나, 복잡한 간접 체인이 없거나, 실행할 수 있는 명령의 수가 더 적은 경우가 많습니다.

조사.

Stanford University 스트림 처리 프로젝트는 1999년에 ^[7]시작된 Stanford Real-Time Programmable Shading Project를 포함합니다.이매진이라고 불리는 시제품이 ^[8]2002년에 개발되었습니다.메리맥이라고 불리는 프로젝트는 ^[9]2004년까지 진행되었습니다.AT&T는 그래픽 처리 장치가 속도와 ^[1]기능 모두에서 빠르게 진화하면서 스트림 강화 프로세서도 연구했다.초기부터 수십 개의 스트림 프로세싱 언어 및 특수 하드웨어가 개발되었습니다.

모델 노트 프로그래밍

병렬 처리 영역에서 가장 시급한 과제는 사용되는 하드웨어 아키텍처의 유형이 아니라 실제 환경에서 허용 가능한 성능을 갖춘 시스템을 얼마나 쉽게 프로그래밍할 수 있느냐에 있습니다.Imagine과 같은 기계는 자동화된 종속성, 메모리 할당 및 DMA 스케줄링을 갖춘 간단한 싱글 스레드 모델을 사용합니다.이는 프로그래머, 도구 및 하드웨어 간의 최적의 작업 계층을 찾기 위해 MIT와 스탠포드가 실시한 연구 결과입니다.프로그래머는 병렬 하드웨어에 대한 매핑 알고리즘에서 도구를, 툴은 프로그래머를 제치고 가장 스마트한 메모리 할당 방식 등을 알아냅니다.특히 관심사는 Cell 등의 MIMD 설계입니다.이 설계에서는 프로그래머가 여러 코어에 걸친 애플리케이션 파티셔닝과 프로세스 동기화 및 로드밸런싱을 처리해야 합니다.효율적인 멀티코어 프로그래밍 툴은 현재 매우 부족합니다.

SIMD 프로그래밍의 단점은 Array-of-Structures(AoS)와 Structure-of-Arrays(SoA)의 문제입니다.프로그래머들은 종종 다음과 같은 '실제' 의미를 가진 데이터 구조를 구축하기를 원했습니다.

 // 3차원 공간에 있는 입자. 구조 파티클_t {     흘러가다 x, y, z;          // 배열도 안 돼!     서명되어 있지 않다 바이트 색.[3]; // 채널당 8비트, RGB에만 관심이 있다고 가정합니다.     흘러가다 크기;     // ...및 기타 많은 속성이 뒤따를 수 있습니다. }; 

그 후, 이러한 구조가 어레이로 조립되어 적절히 정리된 상태로 유지되었습니다.이것은 구조 배열(AoS)입니다.구조가 메모리에 배치될 때, 컴파일러는 모든 구조가 연속적이지만 구조 인스턴스의 "크기" 속성과 다음 인스턴스의 동일한 요소 사이에 일정한 오프셋이 있다는 의미에서 인터리브 데이터를 생성합니다.오프셋은 구조 정의(및 컴파일러의 정책 등 여기서 고려하지 않는 다른 사항)에 따라 달라집니다.다른 문제도 있다.예를 들어, 이 세 가지 위치 변수는 연속 메모리 공간에 할당될지 확실하지 않기 때문에 이러한 방식으로 SIMD화할 수 없습니다.SIMD 연산이 동작할 수 있도록 하려면 , 「충전 메모리 장소」 또는 적어도 어레이로 그룹화해 주세요.또 다른 문제는 "color"와 "xyz"가 모두 3성분 벡터 양으로 정의된다는 것입니다.SIMD 프로세서는 보통 4가지 컴포넌트 동작만을 지원합니다(단, 일부 예외).

이러한 문제와 제한으로 인해 표준 CPU의 SIMD 가속은 매우 어려워졌습니다.제안된 솔루션, 어레이 구조(SoA)는 다음과 같습니다.

구조 파티클_t {     흘러가다 *x, *y, *z;     서명되어 있지 않다 바이트 *colorRed(컬러레드), *컬러 블루, *컬러 그린;     흘러가다 *크기; }; 

C에 익숙하지 않은 독자의 경우 각 식별자 앞에 있는 '*'는 포인터를 의미합니다.이 경우 나중에 할당될 배열의 첫 번째 요소를 가리키기 위해 사용됩니다.Java 프로그래머의 경우 이는 "[]"와 거의 동일합니다.단점은 다양한 속성이 메모리에 분산될 수 있다는 것입니다.이로 인해 캐시 누락이 발생하지 않도록 다양한 "빨간색"을 모두 업데이트하고 "녹색"과 "블루"를 모두 업데이트해야 합니다.

스트림 프로세서의 경우 구조를 사용하는 것이 좋습니다.애플리케이션의 관점에서 모든 속성을 어느 정도 유연하게 정의할 수 있습니다.GPU를 참고하여 사용할 수 있는 속성 집합(16개 이상)이 있습니다.응용 프로그램은 각 속성에 대해 구성 요소의 수와 구성 요소의 형식을 나타낼 수 있습니다(단, 현재로서는 기본 데이터 유형만 지원됩니다).그런 다음 다양한 속성이 메모리 블록에 연결되며, 동일한 속성의 '연속' 요소 간의 보폭을 정의하여 효과적으로 인터리브 데이터를 허용합니다.GPU는 스트림 처리를 시작하면 모든 다양한 속성을 단일 파라미터 세트(일반적으로 구조체 또는 "매직 글로벌 변수"처럼 표시)로 수집하여 작업을 수행하고 결과를 나중에 처리(또는 검색)하기 위해 메모리 영역에 분산합니다.

보다 현대적인 스트림 처리 프레임워크는 데이터를 리터럴 스트림으로 구조화하기 위한 FIFO와 같은 인터페이스를 제공합니다.이 추상화를 통해 데이터 의존성을 암묵적으로 지정할 수 있으며 런타임/하드웨어가 효율적인 계산을 위해 해당 지식을 최대한 활용할 수 있습니다.지금까지 C++의 스트림^{[citation needed]} 처리 방식 중 가장 단순하고 효율적인^{[citation needed]} 것은 RaftLib입니다.이것은 C++ 스트림 연산자를 사용하여 독립된 컴퓨팅 커널을 데이터 흐름 그래프로 링크할 수 있습니다.예를 들어 다음과 같습니다.

#실패하다 <초안> #실패하다 <raftio> #실패하다 <cstdlib> #실패하다 <문자열>  학급 안녕 : 일반의 뗏목::커널 { 일반의:     안녕() : 뗏목::커널()     {        산출량.포트 추가< > 표준::스트링 >( "0" );      }      가상 뗏목::상태 달려.()     {         산출량[ "0" ].밀다( 표준::스트링( 헬로 월드\n" ) );         돌아가다( 뗏목::이제 그만 );      } };  인트 주된( 인트 argc, 차 **argv ) {     /** 프린트 커널**/ 인스턴스화     뗏목::인쇄물< > 표준::스트링 > p;     /** hello world kernel **/ 인스턴스화     안녕 안녕;     /** 맵 오브젝트를 만듭니다**/     뗏목::지도 m;     /** 커널을 맵에 추가합니다.hello와 p가 동시에 실행됩니다**/     m += 안녕 >> p;     /** 맵 **/을 실행합니다.     m.실행();     돌아가다( 종료_SUCCESS ); } 

스트림 처리를 위한 계산 모델

스트리밍 애플리케이션을 고급 언어로 지정하는 것 외에도, 계산 모델(MoC)은 데이터 흐름 모델 및 프로세스 기반 모델로 널리 사용되어 왔습니다.

범용 프로세서 아키텍처

지금까지 CPU는 외부 메모리 대역폭이 상대적으로 느리게 증가하는 것에 비해 성능이 지속적으로 향상되었기 때문에 다양한 계층의 메모리 액세스 최적화를 구현하기 시작했습니다.이 간격이 넓어짐에 따라 대량의 다이 영역이 메모리 지연 시간을 숨기는 데 사용되었습니다.이러한 소수의 ALU에 대한 정보 및 연산 코드를 가져오는 것은 비용이 많이 들기 때문에 실제 수학 기계 전용 다이 영역은 거의 없습니다(대략적으로 10% 미만으로 간주).

유사한 아키텍처가 스트림 프로세서에 존재하지만 새로운 프로그래밍 모델 덕분에 관리 전용 트랜지스터의 양은 실제로 매우 적습니다.

시스템 전체의 관점에서 보면 스트림 프로세서는 일반적으로 제어된 환경에 존재합니다.GPU는 애드인 보드에 존재합니다(이는 Imagine에도 적용되는 것 같습니다).CPU는 시스템 리소스 관리, 애플리케이션 실행 등의 더러운 작업을 수행합니다.

스트림 프로세서는 일반적으로 빠르고 효율적인 독자 사양 메모리 버스를 갖추고 있습니다(과거에는 크로스바 스위치가 일반적이며 멀티버스가 사용되었습니다).메모리 레인의 정확한 양은 시장 범위에 따라 달라집니다.여기서 기술된 바와 같이 (엔트리 레벨) 주변에는 아직 64비트 폭의 상호접속이 존재합니다.대부분의 미드레인지 모델은 128비트 고속 크로스바 스위치 매트릭스(4 또는 2세그먼트)를 사용하는 반면 하이엔드 모델은 256비트 폭의 약간 느린 크로스바를 사용하여 대용량의 메모리(실제로는 최대 512MB)를 배치합니다.반면 인텔 Pentium에서 일부 Athlon 64까지의 표준 프로세서에는 64비트 와이드 데이터 버스가 1개만 탑재되어 있습니다.

메모리 액세스 패턴은 훨씬 예측이 용이합니다.어레이는 존재하지만 그 차원은 커널 호출 시 고정됩니다.멀티 포인터 인다이렉션에 가장 가까운 것은 인다이렉션체인입니다.단, 이 체인은 특정 메모리 영역(스트림 내부)에서 최종적으로 읽기 또는 쓰기를 보증합니다.

스트림 프로세서의 실행 유닛(ALU 클러스터)의 SIMD 특성으로 인해 읽기/쓰기 작업이 대량으로 발생할 것으로 예상되므로 메모리는 낮은 레이텐시가 아닌 고대역폭에 최적화됩니다(예를 들어 Rambus 및 DDR SDRAM과의 차이).이것에 의해, 효율적인 메모리 버스 네고시에이션도 가능하게 됩니다.

스트림 프로세서의 작업의 대부분(90%)은 온칩으로 이루어지기 때문에 전 세계 데이터의 1%만 메모리에 저장하면 됩니다.여기서 커널의 일시성과 의존성을 알 수 있습니다.

내부적으로 스트림 프로세서는 몇 가지 뛰어난 통신 및 관리 회로를 갖추고 있지만 흥미로운 점은 스트림 레지스터 파일(SRF)입니다.이는 개념적으로 스트림 데이터를 저장하여 벌크 상태의 외부 메모리에 전송하는 대용량 캐시입니다.다양한 ALU에 대한 캐시와 같은 소프트웨어 제어 구조로서 SRF는 모든 다양한 ALU 클러스터 간에 공유됩니다.스탠포드의 Imagine 칩으로 이루어진 주요 개념과 혁신은 컴파일러가 최적의 방법으로 메모리를 자동화하고 프로그래머에게 완전히 투과적으로 할당할 수 있다는 것입니다.커널 함수와 데이터 간의 의존성은 컴파일러가 흐름 분석을 수행하고 SRF를 최적으로 패키징할 수 있는 프로그래밍 모델을 통해 알려져 있습니다.일반적으로 이 캐시 및 DMA 관리는 스트림 프로세서(또는 적어도 Imagine)가 완전히 자동화하는 프로젝트 일정의 대부분을 차지할 수 있습니다.스탠포드에서 실시한 테스트에 따르면 컴파일러는 사용자가 수작업으로 메모리를 튜닝하는 것보다 메모리 스케줄링을 더 잘하거나 더 잘했다고 합니다.

클러스터 간 통신은 드물다고 가정하기 때문에 많은 클러스터가 존재할 수 있다는 증거가 있습니다.그러나 내부적으로는 클러스터 내 통신이 일반적이기 때문에 매우 효율적일 필요가 있기 때문에 각 클러스터는 훨씬 적은 양의 ALU를 효율적으로 이용할 수 있습니다.

이러한 ALU를 데이터와 함께 가져오기 위해 각 ALU에는 기본적으로 사용 가능한 레지스터인 Local Register File(LRF; 로컬 레지스터 파일)이 장착되어 있습니다.

이 3계층 데이터 액세스 패턴은 느린 메모리에서 임시 데이터를 쉽게 보호할 수 있도록 하기 때문에 실리콘 구현이 매우 효율적이고 절전적입니다.

하드웨어 인더루프 문제

이 섹션은 독자들에게 혼란스럽거나 불분명할 수 있습니다. 섹션을 명확하게 하는 데 도움을 주세요. 토크 페이지에 이 건에 대한 논의가 있을 수 있습니다.(2008년 1월) (이 템플릿메시지를 삭제하는 방법과 타이밍에 대해 설명합니다)

(스트리밍 방식으로 컴퓨팅하는 경우 메인스트림 GPU에서도) 상당한 속도 향상을 기대할 수 있지만, 모든 애플리케이션이 이점을 누리는 것은 아닙니다.사실 통신 지연이 가장 큰 문제입니다.PCI Express는 전이중 통신으로 이 기능을 향상시켰지만 GPU(및 범용 스트림 프로세서)를 동작시키려면 시간이 오래 걸릴 수 있습니다.즉, 일반적으로 소규모 데이터셋에 사용하는 것은 역생산적입니다.커널을 변경하는 것은 다소 비용이 많이 드는 작업이기 때문에 스트림 아키텍처는 또한 짧은 스트림 효과라고 불리는 동작인 작은 스트림에 대한 패널티를 유발합니다.

파이프라이닝은 스트림 프로세서에서 매우 널리 사용되고 있으며 GPU는 200단계가 넘는 파이프라인을 특징으로 합니다.설정 전환 비용은 변경되는 설정에 따라 다르지만, 현재는 항상 비싼 것으로 간주됩니다.파이프라인의 다양한 수준에서 이러한 문제를 피하기 위해 "über shaders" 및 "texture atlases"와 같은 많은 기술이 도입되었습니다.GPU의 특성상 게임 지향적인 기술이지만 범용 스트림 처리에도 흥미로운 개념입니다.

예

• Commodore Amiga의 Blitter는 16개의 컴포넌트 비트 벡터의 3개의 소스 스트림을 256개의 방법으로 조합하여 16개의 컴포넌트 비트 벡터로 구성된 출력 스트림을 생성할 수 있는 초기(1985년경) 그래픽 프로세서입니다.총 입력 스트림 대역폭은 최대 4,200만 비트/초입니다.출력 스트림 대역폭은 최대 2800만 비트/초입니다.
• 스탠포드 대학의 William Dally 교수가 이끄는 ^[10]Imagine은 고속으로 에너지 효율이 뛰어난 유연한 아키텍처입니다.1996년에 구상된 이 프로젝트에는 아키텍처, 소프트웨어 도구, VLSI 구현 및 개발 보드가 포함되어 있으며, DARPA, Intel 및 Texas Instruments의 자금 지원을 받았습니다.
• 또 다른 스탠포드 프로젝트인 메리맥은 ^[11]스트림 기반의 슈퍼컴퓨터를 개발하는 것을 목표로 하고 있다.Merimac은 스트림 아키텍처와 고급 상호접속 네트워크를 사용하여 동일한 기술로 구축된 클러스터 기반 과학 컴퓨터보다 단위 비용당 더 높은 성능을 제공할 계획입니다.
• Stream Processors, Inc.의 Storm-1 패밀리는 Stream Processors, Inc.의 Storm-1 패밀리는 ISSCC 2007에서 열린 기능 프레젠테이션에서 발표되었습니다.이 패밀리에는 30GOPS에서 22016비트 GOPS(초당 수십억 번의 작업)에 이르는 4개의 멤버가 포함되어 있으며 모두 TSMC에서 130나노미터 공정으로 제작되었습니다.이 장치는 화상회의, 다기능 프린터, 디지털 비디오 감시 기기 등 DSP 시장의 하이엔드를 타깃으로 하고 있습니다.
• GPU는 AMD와 Nvidia가 주로 설계한 광범위한 소비자용 스트림^[2] 프로세서입니다.스트림 프로세싱의 관점에서는 다음과 같은 다양한 세대에 주목해야 합니다.
  • R2xx/NV2x 이전 버전: 스트림 처리를 명시적으로 지원하지 않습니다.커널 조작은 API에 숨겨져 있어 일반적인 사용에 비해 유연성이 거의 없었습니다.
  • R2xx/NV2x: 커널 스트림 연산은 프로그래머의 제어 하에 분명히 들어갔지만 정점 처리만을 위한 것이었다(프래그먼트들은 여전히 오래된 패러다임을 사용하고 있었다).브랜치 지원은 유연성을 크게 저해하지 않지만 일부 알고리즘(특히 고정밀 유체 시뮬레이션)을 실행할 수 있습니다.
  • R3xx/NV4x: 유연한 분기 지원.다만, 실행하는 조작의 수와 엄격한 재귀 심도, 어레이의 조작에 대해서는 몇개의 제한이 있습니다.
  • R8xx: 추가/소비 버퍼 및 원자성 작업을 지원합니다.이 세대는 최첨단이다.
• AMD FireStream 브랜드명 HPC 대상 제품 라인
• Nvidia Tesla의 HPC 대상 제품 라인 브랜드명
• Sony Computer Entertainment, Toshiba Corporation 및 IBM이 제휴한 STI의 Cell 프로세서는 적절한 소프트웨어 지원을 통해 스트림 프로세서와 같은 기능을 할 수 있는 하드웨어 아키텍처입니다.제어 프로세서인 PPE(Power Processing Element, IBM Power)로 구성됩니다.PC)와 SPE(Synergistic Processing Elements)라고 불리는 일련의 SIMD 코프로세서는 각각 독립된 프로그램카운터와 명령 메모리를 갖추고 있어 사실상 MIMD 머신입니다.네이티브 프로그래밍 모델에서는 모든 DMA 및 프로그램 스케줄링이 프로그래머에게 맡겨집니다.하드웨어는 로컬 통신용 프로세서 간에 고속 링 버스를 제공합니다.명령 및 데이터용 로컬메모리는 한정되어 있기 때문에 이 아키텍처를 효과적으로 이용할 수 있는 유일한 프로그램은 작은 메모리 설치 공간을 필요로 하거나 스트림 프로그래밍 모델을 준수합니다.적절한 알고리즘으로 셀의 성능은 순수 스트림 프로세서의 성능에 필적할 수 있지만, 이는 거의 항상 알고리즘과 소프트웨어의 완전한 재설계를 필요로 한다.

프로그래밍 라이브러리 및 언어 스트리밍

스트림 프로세서의 대부분의 프로그래밍 언어는 Java, C 또는 C++로 시작하여 애플리케이션 개발자가 커널 및/또는 스트림에 태그를 붙일 수 있도록 특정 명령을 제공하는 확장을 추가합니다.이는 대부분의 음영 언어에도 적용되며, 어느 정도까지는 스트림 프로그래밍 언어로 간주될 수 있습니다.

스트림 프로그래밍 언어의 비상업적 예는 다음과 같습니다.

• Ateji PX Free Edition은 JVM에서 스트림 프로그래밍, Actor 모델 및 MapReduce 알고리즘을 단순하게 표현합니다.
• 자동 파이프(Auto-Pipe)는 St. Washington University의 Stream Based Supercomputing Lab에서 제작되었습니다. Louis는 이종 시스템(CPU, GPGPU, FPGA)용 애플리케이션 오서링을 가능하게 하는 스트리밍 애플리케이션용 애플리케이션 개발 환경입니다.애플리케이션은 CPU의 경우 C, C++ 및 Java를 임의로 조합하여 개발할 수 있습니다.FPGA의 경우 Verilog 또는 VHDL입니다.Cuda는 현재 Nvidia GPGPU에 사용되고 있습니다.자동 파이프에서는, 복수의 머신간의 TCP 접속의 조정도 처리합니다.
• ACOTES 프로그래밍 모델: Open 기반 카탈루냐 공과대학 언어MP
• BeepBeep은 Québec chic Chicoutimi 대학의 공식 컴퓨터 과학 연구소에서 제공하는 단순하고 가벼운 Java 기반 이벤트 스트림 처리 라이브러리입니다.
• 스탠퍼드 브룩어
• CAL Actor Language: 데이터 객체(토큰)의 입력 스트림을 출력 스트림으로 변환하는 상태 저장 연산자(데이터 플로우) 액터를 쓰기 위한 고급 프로그래밍 언어입니다.
• Cal2스웨덴 할름스타드 대학의 코드 생성 프레임워크.CAL 코드를 입력으로 사용하여 순차적 C, Chisel, Epiphany 아키텍처를 대상으로 하는 병렬 C, ajava 및 Ambric 아키텍처를 대상으로 하는 아스트랙트 등 다양한 타깃 고유의 언어를 생성합니다.
• 뮌헨 공과대학 및 덴버 대학 DUP 언어
• HSTREAM: 이종 스트림 컴퓨팅을^[12] 위한 Directive-Based Language 확장
• RaftLib - 오픈 소스 C++ 스트림 처리 템플릿 라이브러리 원래 Washington University의 Stream Based Supercomputing Lab에서 제공되었습니다. 루이
• SPAR - 교황청 가톨릭 대학교 리오그란데도술(Rio Grande do Sul)의 애플리케이션 모델링 그룹(GMAP)에서 스트림 병렬성을 표현하기 위한 C++ 도메인 고유 언어
• 워털루 대학의 Sh 도서관
• 오픈 소스 프로젝트인 Shallows
• Hertfordshire 대학의 S-Net 코디네이션 언어(코디네이션과 알고리즘 프로그래밍의 분리를 제공합니다.
• MIT로부터의 Stream It
• WSO2의 Siddhi
• WaveScript 기능 스트림 처리(MIT에서도 사용).
• 기능적 반응형 프로그래밍은 넓은 의미에서 스트림 프로세싱으로 간주될 수 있습니다.

상업용 실장은 범용이거나 벤더가 특정 하드웨어와 연계한 것입니다.범용 언어의 예는 다음과 같습니다.

• MATLAB용 GPU 엔진 상용화 AccelereEyes' Jacket
• 스트림 프로그래밍, Actor 모델, MapReduce 알고리즘의 간단한 표현을 가능하게 하는 Ateji PX Java 확장
• Telchemy의 경량 임베디드 스트리밍 분석 에이전트인 Embiot
• PlayStation 3, Xbox360, Wii, PC용 게임브리오 게임엔진에 제공되는 스트림 프로세서인 Bloodgate
• Open HMPP, 다코어 프로그래밍의 '지향적' 비전
• Peak Stream,^[13] Brook 프로젝트의 스핀아웃(2007년 6월 Google에 인수됨)
• IBM Spade - 스트림 처리 애플리케이션 선언 엔진(B).게딕 등SPADE: 시스템 S 선언 스트림 처리 엔진.ACM SIGMOD 2008).
• Rapid Mind, Sh의 상용화(2009년 8월 인텔 인수)
• TStreams,^[14][15] Hewlett-Packard Cambridge Research Lab

벤더 고유의 언어는 다음과 같습니다.

• AMD/ATI의 Brook+(AMD 하드웨어 최적화 Brook 구현)
• NVIDIA의 CUDA(컴퓨팅 통합 디바이스 아키텍처)
• 스루풋 컴퓨팅용 인텔 Ct - C
• Stream Processors, Inc.의 StreamC는 스탠포드에서 Imagine 작업을 상업화한 것입니다.

이벤트 기반 처리

• Apama - 소프트웨어 AG에 의한 복합 이벤트와 스트림 처리 엔진 결합
• 왈라루과
• WSO2 스트림 프로세서 by WSO2
• 아파치 NiFi

배치 파일 기반 처리(실제 스트림 처리의 일부를 에뮬레이트하지만 일반적으로^{[clarification needed][citation needed]} 성능이 크게 저하됨)

• 아파치 카프카
• 아파치 스톰
• 아파치 에이펙스
• 아파치 스파크

연속 오퍼레이터 스트림^{[clarification needed]} 처리

• 아파치 플링크
• 월마트랩스 MUPD8^[16]
• Eclipse 스트림 시트 - 스트림 처리를 위한 스프레드시트

스트림 처리 서비스:

• 아마존 웹 서비스 - Kinesis
• Google 클라우드 - 데이터 흐름
• Microsoft Azure - 스트림 분석
• 데이터 스트림 - 데이터 스트리밍 분석 플랫폼
• IBM 스트림
  • IBM 스트리밍 분석
• Eventador SQLStreamBuilder

「 」를 참조해 주세요.

레퍼런스