코드를 가장 빠르게 병렬 처리하는 방법은 무엇입니까?

3

나는 매우 빠르게 병렬 처리 될 수 있다고 믿는 이미지 처리 루틴을 가지고있다. 각 픽셀은 이웃에서 수행되는 작업에 의존하지 않는 방식으로 약 2k 작업을 수행해야하므로 작업을 여러 단위로 분할하는 것은 매우 간단합니다.

제 질문은이 변화에 접근하는 가장 좋은 방법은 무엇입니까? 그러니 내가 가장 빠른 스피드 업을 얻을 수 있습니다.

이상적으로 내가 찾고있는 라이브러리 / 접근 방식은 다음 기준을 충족해야합니다.

  1. 5 년 후에도 계속있을 것입니다. CUDA 또는 ATI의 변형과 같은 것이 너무 멀지 않은 미래에 더 적은 하드웨어 별 솔루션으로 대체 될 수 있으므로 시간을 좀 더 강하게하고 싶습니다. CUDA에 대한 나의 인상이 잘못 되었다면, 나는 그 교정을 환영한다.
  2. 구현이 빠르다. 나는 이미이 코드를 작성했으며 직렬 모드로 작동하지만 아주 천천히 작동합니다. 이상적으로는, 필자는 코드를 가져 와서 병렬 처리하도록 재 컴파일하지만, 그것은 환상 일 수 있다고 생각합니다. 만약 다른 패러다임 (즉, 쉐이더 또는 무언가)을 사용하여 다시 작성한다면, 그렇게 될 것입니다.
  3. 하드웨어에 대한 지식이 너무 많이 필요하지 않습니다. 스레드 수나 운영 단위 수를 지정하지 않아도되지만 사용중인 컴퓨터를 기반으로 자동으로 모든 것을 자동으로 파악하도록하고 싶습니다.
  4. 값싼 하드웨어에서 실행 가능합니다. 이는 150 달러짜리 그래픽 카드를 의미 할 수도 있습니다.
  5. Windows에서 실행 가능합니다. GCD와 같은 것이 올바른 선택 일지 모르지만, 내가 타겟팅하는 고객 기반은 언제든지 Mac이나 Linux로 전환 할 수 없습니다. 이렇게하면 질문에 대한 응답이 다음과 약간 다릅니다.이 다른 질문.

어떤 라이브러리 / 접근 방식 / 언어를보고해야합니까? OpenMP, CUDA, GCD 등과 같은 것들을 살펴 봤지만, 제가 놓친 다른 것들이 있는지 궁금합니다.

저는 셰이더와 OpenGL 2.0과 같은 것에 지금 기대고 있습니다. 그러나 그것은 적절한 호출이 아닐 수도 있습니다. 내가 얼마나 많은 메모리 액세스를 할 수 있는지 잘 모르겠습니다. 2k 작업은 이웃 픽셀을 모두 액세스해야합니다. 많은 방법.

mmr

출처 image-processing parallel-processing

5 답변

1

가장 쉬운 방법은 그림을 병렬로 처리 할 수있는 부품 수 (코어에 따라 4, 8, 16)로 나누는 것입니다. 그런 다음 각 파트마다 다른 프로세스를 실행하십시오.

이 작업을 구체적으로 수행하는 측면에서 OpenCL을 살펴보십시오. 그것은 특정 업체가 아니기 때문에 희망적으로 오래있을 것입니다. 그리고 NVidia와 ATI는 그것을 지원하기를 원합니다.

일반적으로 너무 많은 데이터를 공유 할 필요가 없으므로 프로세스가 매우 간단합니다.

  • 살펴 보겠습니다. OpenCL에서 코어 수를 지정해야합니까? 저는 모든 것을 일과 단위로 나누기를 바래요. ' 그걸 맡겨. - mmr
  • 자, 알고리즘을 개발하여 임의의 수의 코어로 작동 가능하도록하십시오. - CookieOfFortune
1

또한 스레딩 구성 요소를 권장합니다. 우리는 이것을인텔 ® 통합 성능 프리미티브내가 일하는 회사에서 이미지 분석을 위해.

TBB (Threading Building Blocks)는 OpenMP와 Cilk와 비슷합니다. 그리고 OpenMP를 사용하여 멀티 스레딩을 수행합니다. 더 단순한 인터페이스로 래핑됩니다. 이 도구를 사용하면 몇 개의 스레드를 만들지 걱정할 필요가 없으며 작업을 정의 할 수 있습니다. 가능한 경우 모든 작업을 유지하기 위해 작업을 분할하여 부하 분산을 수행합니다.

인텔 통합 성능 프리미티브 (Ipp)는 비전을위한 라이브러리를 최적화했습니다. 대부분은 멀티 스레드입니다. 우리가 필요로하는 함수가 IPP에 없기 때문에 우리는 TBB를 사용하여 스레드합니다.

이를 사용하여 IPP 방법을 사용하여 이미지를 만들 때 최상의 결과를 얻습니다. 그것이하는 일은 주어진 캐시 라인이 전체적으로 하나의 행에 포함되도록 각 행을 채 웁니다. 그런 다음 스레드에서 이미지의 행을 분할하지 않습니다. 그렇게하면 동일한 캐시 라인에 쓰려고하는 두 스레드에서 잘못된 공유가 발생하지 않습니다.

  • IPP에 익숙하지만 멀티 스레딩 / 타일링 코드가 유용하지 않은 것으로 나타났습니다 (이미지는 모두 uint8이 아니라 ushorts입니다). TBB가이 문제를 해결하면 꽤 재미 있습니다 ... - mmr
  • 우리는 ushorts뿐만 아니라 uint8 인 이미지를 사용합니다. TBB는 둘 중 하나와 함께 작동합니다. 실제로, 우리가 직접 작성한 함수의 대부분은 두 유형을 모두 허용하고 TBB를 사용하는 템플릿입니다. - Ed_S
  • 명확히하기 위해, IPP는 다른 유형의 메모리 할당자를 가지고있다. 이러한 할당자는 모든 캐시 라인이 완전히 하나의 행에 포함되도록합니다. 캐시 행이 가득 차도록 각 행의 끝을 패딩하여이 작업을 수행합니다. 그것은 약간의 메모리를 낭비하지만 1025 x 1024 크기의 이미지에서는 단지 3 %입니다. 이것은 더 나쁜 경우입니다. 대부분의 경우 메모리를 적게 낭비합니다. - Ed_S
0

인텔의 (오픈 소스)스레딩 구성 요소?

  • 나는 그렇지 않다. 나는 그것을 조사 할 것이다. - mmr
0

나는 그것을 사용하지 않았지만 한번 보아라.Cilk. 팀의 큰 가발 중 하나는 Charles E. Leiserson입니다. 그는 "L"이다.CLRS, 지구상에서 가장 광범위하게 존경받는 알고리즘 책. 나는 그것이 귀하의 요구 사항을 충족 시켜줄 것이라고 생각합니다.

나의 간단한 독서에서, 당신이 오직해야하는 것은 당신의 "꼬리표"이다기존의코드를 작성한 다음 컴파일러를 통해 자동으로 / 코드를 병렬 처리합니다. 이것은 큰 판매 포인트이기 때문에 다른 옵션 (예 : OpenMP)과 달리 처음부터 병렬 처리를 염두에두고 시작할 필요가 없습니다.

0

C, C ++, Fortran 중 하나에 이미 작동중인 시리얼 코드가 있다면 OpenMP를 심각하게 고려해야합니다. 다른 많은 병렬화 라이브러리 / 언어 / 시스템 / 무엇보다 큰 장점 중 하나는 루프를 한 번에 병렬 처리 할 수 있다는 것입니다. 다시 쓰기를하지 않고도 유용한 속도 향상을 얻을 수 있습니다. - 디자인, 당신의 프로그램.

요구 사항 측면에서 :

  1. OpenMP는 고성능 컴퓨팅에 많이 사용되며, 그 뒤에 많은 '무게'가 있고 적극적인 개발 커뮤니티 인 www.openmp.org가 있습니다.

  2. C, C ++ 또는 Fortran을 선택했을 정도로 충분히 빠르면 구현하기에 충분히 빠릅니다.

  3. OpenMP는 병렬 컴퓨팅에 대한 공유 메모리 접근 방식을 구현하므로 '하드웨어를 이해할 필요가 없습니다.'인수에 큰 도움이됩니다. 런타임에 얼마나 많은 프로세서를 가지고 있는지 파악한 다음, 사용 가능한 모든 프로세서와 또 다른 프로세서에 계산을 배포 할 수 있습니다.

  4. 비싼 또는 값싼 추가 그래픽 카드가 필요없이 이미 가지고있는 하드웨어에서 실행됩니다.

  5. 네, Windows 시스템에 대한 구현이 있습니다.

물론 처음에 C, C ++ 또는 Fortran을 선택하지 않은 경우 현명하지 못한 경우이 조언 중 많은 부분이 해당 언어 중 하나에 다시 작성된 후에 만 적용됩니다!

문안 인사

표

연결된 질문

관련된 질문

최근 질문