소프트웨어 프로그래밍에서 CPU 및 GPU로드를 100 %로 유지할 수 있습니까?

이것은 게이머로서 흥미로운 주제 인 CPU / GPU 병목 현상과 프로그래밍에 대한 일반적인 질문입니다. 내가 실수하지 않으면 CPU와 GPU가 계산하는 것을 이해하지만 아키텍처의 차이로 인해 다른 계산보다 나은 계산이 가능하다는 것을 알게되었습니다. 예를 들어, 크래쉬 해시 또는 cryptocurrency 마이닝은 CPU보다 GPU에서 훨씬 더 효율적인 것으로 보입니다.

그래서 궁금합니다 : CPU가 100 % 부하에 있고 CPU는 50 % (예 : 불가피)입니까?

더 정확하게 말하면 , GPU가 일반적으로 수행하는 일부 계산은 첫 번째 계산이 100 %로드 인 경우 CPU가 수행 할 수 있습니까?

주제에 대해 조금 검색했지만 빈손으로 돌아 왔습니다. 나는 이것이이 하위 섹션에 자리 잡고 있으며 당신이 나에게 줄 수있는 모든 문서 나 강의에 열려 있다고 생각하고 희망한다!

이론적으로는 맞지만 실제로는 그만한 가치가 거의 없습니다.

CPU와 GPU 모두 튜링이 완료 되었으므로 하나에 의해 계산 될 수있는 알고리즘도 다른 하나에 의해 계산 될 수 있습니다. 문제는 얼마나 빠르고 편리합니다.

GPU는 큰 데이터 세트의 많은 데이터 포인트에서 동일한 간단한 계산을 수행하는 데 탁월하지만, 분기가 많은 복잡한 알고리즘에서는 CPU가 더 좋습니다. 대부분의 문제에서 CPU와 GPU 구현의 성능 차이는 엄청납니다. 즉, 정지 상태에서 하나를 사용하여 다른 쪽에서 작업을 수행하면 성능이 크게 향상되지는 않습니다.

그러나이 비용을 지불해야하는 비용은 CPU와 GPU에 대해 모든 것을 두 번 프로그래밍해야한다는 것입니다. 스위칭 및 동기화 로직도 구현해야하므로 이는 두 배 이상의 작업입니다. 이 논리는 동작이 전류 부하에 따라 달라지기 때문에 테스트하기가 매우 어렵습니다. 이 스턴트에서 버그를 재현하는 것은 매우 모호하고 불가능합니다.

게임 프로그래밍과 관련이 없습니다. 일부 과학 코드는 GPU와 CPU를 모두 사용할 수도 있습니다.

OpenCL 또는 CUDA 를 사용하는 등 신중하고 고통스러운 프로그래밍을 통해 GPU와 CPU를 거의 100 %로드 할 수 있습니다. GPU ( "커널"코드라고 함)와 CPU 및 지루한 접착제 코드 (특히 GPU에 컴파일 된 커널 코드를 보내려면)에 대해 서로 다른 코드 조각을 작성해야합니다.

그러나 코드는 복잡 할 수 있으며 특히 GPU와 CPU 간의 데이터 전송에 비용이 많이 들기 때문에 실행중인 특정 하드웨어에 맞게 조정해야합니다.

이기종 컴퓨팅 에 대해 자세히 알아보십시오 .

최신 버전의 GCC에서 지원하는 OpenACC 도 참조하십시오 (예 : 2016 년 6 월의 GCC 6 )

수퍼 컴퓨팅 관점에서 CPU / GPU로드를 백분율로 생각하지 말고 문제가 필요한 작업 수를 결정한 다음 시스템의 최고 성능과 비교하는 것이 좋습니다.

100 % CPU 사용률을 얻는다고해서 반드시 시스템에서 모든 성능을 얻는 것은 아닙니다. CPU는 종종 부서와 추가와 같이 여러 가지 다른 작업을 동시에 수행 할 수 있습니다. 디비전을 일찍 시작할 수 있으면 추가와 겹칠 수 있습니다. 데스크탑 CPU에는 이러한 오버랩의 이점을 위해 명령문을 재정렬하는 순서 가 잘못된 장치 가있을 가능성이 높습니다 . 또는 다음 프로그램이있는 경우 :

if (expr1)
    expr2;
else
    expr3;

재정렬 CPU는 세 가지 표현식 을 동시에 계산 한 다음 그 중 하나의 결과를 버립니다. 이것은 전체적으로 더 빠릅니다. 프로그램에 일부 차단기가 있고 순서를 바꿀 수없는 경우 CPU에서 더 적은 레인을 사용하고 있지만 여전히 100 %를 표시합니다.

그런 다음 벡터 작업 인 CPU에 SIMD 기능이 있습니다. GPGPU-light와 비슷합니다. 일반적으로 동시에 4 개 또는 8 개의 작업 만 수행하고 GPU는 32 또는 64를 사용합니다. 그래도 FLOPS를 크랭크하려면이를 사용해야합니다.

허위 공유와 같은 것은 동기화 비용이 많이들 수 있으며 일반적으로 Linux에서 커널로드로 표시됩니다. CPU가 완전히 사용되었지만 유용한 처리량이 많지 않습니다.

IBM Blue Gene / Q 머신에서 일부 프로그래밍을 수행했습니다. 계층 구조 수준이 많기 때문에 ( 구식 Blue Gene / L의 회로도 ) 효율적으로 프로그래밍하기가 어렵습니다. 성능을 얻으려면 전체 계층 구조를 SIMD 및 SMT (Intel은이 하이퍼 스레딩이라고 함)까지 사용해야합니다.

그리고 네트워크는 종종 당신을 제한합니다. 따라서 (벽시계) 시간이 네트워크를 통해 통신하는 대신 여러 CPU에서 동시에 계산하는 것이 더 빠릅니다. 이렇게하면 CPU에 더 많은 부하가 걸리고 프로그램이 더 빨리 실행됩니다. 그러나 실제 프로그램 처리량은 원래 숫자보다 좋지 않습니다.

믹스에 GPU를 추가하면 성능을 높이기 위해이 모든 것을 조정하는 것이 훨씬 어려워집니다. 이것이 몇 달 안에 Lattice QCD Master Thesis에서 시작하게 될 것 중 하나입니다.

당신은 체크 아웃에 관심이있을 수있는 서보 모질라 연구소에서 개발중인 브라우저 엔진을,보다 구체적으로는 웹 (비디오) 렌더링 .

다른 답변 (특히 @ Philip 's)에서 언급했듯이 CPU에서 GPU로 작업을 동적으로 전환하는 것은 실용적이지 않을 수 있지만 일반적인 작업 부하에 대한 CPU / GPU의 부하를 미리 연구하고 일부 작업을 일반적으로 덜로드 된 것으로 전환 하는 것이 실용적입니다 하나.

Web Render의 경우 참신한 점은 전통적으로 브라우저는 대부분의 렌더링 작업을 CPU에서 수행한다는 것입니다. 즉, CPU는 표시 할 객체, 잘라낼 위치 등을 계산하는 데 사용됩니다. GPU는 일반적으로 사용하는 것이 더 좋습니다 ... 모든 사용 사례가 구현하기에 사소한 것은 아닙니다 (부분 컬링, 그림자, ... 및 텍스트).

초기 버전의 Web Render는 성능 향상에 큰 성공을 거두었지만 텍스트 렌더링 문제를 해결하려고 시도하지 않았으며 몇 가지 다른 제한이있었습니다. 모질라 리서치는 현재 제한이 적고 특히 텍스트 렌더링을 지원하기 위해 두 번째 버전을 개발 중입니다.

물론 목표는 렌더링 프로세스의 가능한 많은 부분을 GPU로 오프로드하여 CPU가 Javascript를 실행하고 DOM을 업데이트하며 다른 모든 작업을 자유롭게 수행 할 수 있도록하는 것입니다.

따라서, 귀하의 제안으로하지 극단, 그것은으로 계산 전략 설계의 방향으로 이동 않는 동안 모두 염두에 CPU와 GPU를.

게임에 초점을 맞추면 (포스트에서 구체적으로 언급 한 이후)로드 균형을 조정할 수있는 몇 가지 방법이 있습니다. 한 가지 예는 "스킨", 즉 모델 애니메이션입니다. 렌더링 할 각 프레임마다 애니메이션의 각 프레임에 대해 변환 행렬을 생성하고 모델의 꼭짓점에 적용하여 프레임을 필요한 포즈로 변환해야합니다. 부드러운 움직임을 얻으려면 프레임을 보간해야합니다. 애니메이션이 원래의 Quake (예 : 육포)처럼 보이길 원하지 않는 한.

이 상황에서는 CPU에서 수행하고 렌더링을 위해 결과를 GPU에 업로드하거나 GPU에서 계산 및 렌더링을 수행 할 수 있습니다. 저는 오늘날 GPU에서 수행된다고 생각합니다 ( "하드웨어 스키닝"이라고 함). 수천 번 이상 수행해야하는 비교적 간단한 계산이 있고 결과 이후 각 정점을 동시에 계산할 수 있다면 그렇게하는 것이 합리적입니다. 정점 A의 결과는 정점 B의 결과와 관련이 없습니다.

그러나 이론적으로 GPU와 CPU의 오버로드 정도에 따라 CPU 또는 GPU에서 동적으로 전환 할 수 있습니다.

그러나 모든 계산 에서이 작업을 수행하는 주요 차단제는 CPU와 GPU의 장단점이 다르다는 것입니다. GPU에서 대규모 병렬 작업이 더 잘 수행되고 분기가있는 집중적 인 선형 작업이 CPU에서 더 잘 수행됩니다. 심각한 성능 저하없이 현실적으로 몇 가지 작업 만 수행 할 수있었습니다.

전반적으로 GPU 프로그래밍 (최소한 OpenGL 및 DirectX 11 이하)의 주요 문제는 GPU가 셰이더 코드를 해석하는 방식을 거의 제어 할 수 없다는 것입니다. 계산간에 종속성을 실수로 생성하면 GPU가 픽셀 렌더링을 하나씩 시작하여 실제 데이터가 동일하게 렌더링 되더라도 순간적으로 60fps에서 10fps로 전환 할 수 있기 때문에 셰이더 내에서 분기하는 것은 위험합니다.

실제 사례 중 하나는 오픈 소스 LuxRender 렌더링 엔진으로 CPU와 GPU를 동시에 완전히로드 할 수 있습니다. 또한 동시에 여러 GPU를로드 할 수 있으며 여러 컴퓨터에 분산 할 수도 있습니다.

LuxRender는 OpenCL 을 사용 하여이를 용이하게하지만 OpenCL 이없는 빌드도 존재합니다.

LuxRender가 사용하는 알고리즘은 병렬화가 가능하기 때문에 실용적입니다. LuxRender가 사용하는 가장 일반적인 알고리즘은 경로 추적으로 , 많은 개별 광 경로가 서로 독립적으로 계산 될 수 있습니다. GPU 컴퓨팅에 이상적인 상황이며 컴퓨팅 노드간에 복잡한 동기화가 필요하지 않습니다. 그러나 GPU 제한 (더 적은 메모리 양, 일부 복잡한 렌더링 기능에 대한 지원 부족 및 일부 아티스트에 대한 일반적인 가용성 부족)은 CPU 지원이 여전히 필수임을 보장합니다.

네, 가능합니다.

CPU가 수행 할 수있는 계산, GPU가 수행 할 수있는 계산 및 그 반대의 경우도 마찬가지입니다.

그러나 다음과 같은 이유로 흔하지 않습니다.

• 엔지니어링 복잡성 CPU와 GPU (예 : CUDA)에서 동일한 코드를 실행할 수는 있지만 프로세서의 성능과 성능은 다릅니다. 하나는 MIMD입니다. 다른 하나는 SIMD입니다. 하나에서 빠른 것은 다른 것에서 느리므로 (예 : 분기) 성능을 최대화하려면 별도의 코드를 작성해야합니다.

• 비용 효율성 GPU는 CPU보다 훨씬 강력합니다. GPU의 전체 아이디어는 저렴하고 느리지 만 더 많은 프로세서를 사용하여 동일한 비용으로 CPU보다 훨씬 빠른 계산을 수행하는 것입니다. GPU는 1-2 배 정도 비용면에서 효율적입니다.

알고리즘이 GPU에서 실행되도록한다면이를 최적화하고 필요한만큼 추가하는 것이 더 합리적입니다.