GPU가 값어치를 하는 순간: 파라미터 스윕의 루프라인, 헤드라인 167배는 사실 27배 알고리즘 곱하기 6.2배 하드웨어다

"환상 없는 백테스트" 시리즈의 일부입니다.

속도 사다리는 의도적으로 개운치 않은 지점에서 끝났습니다. 우리는 80개 콤보 파라미터 스윕을 노트북 CPU에서 pandas의 69.9초로부터 병렬 numba의 0.23초까지 — 측정된 298배 — 끌어내린 뒤, GPU는 빠진 단이 아니다라고 주장했습니다. 댓글창은 이를 조용히 받아들이지 않았고, 그럴 만했습니다. "빠진 단이 아니다"는 하나의 워크로드, 하나의 크기에 대한 주장입니다. 자연 법칙이 아닙니다. 그래서 이 글은 정직한 일을 합니다 — GPU를 시험대에 올립니다.

결과는 평결이 아니라 곡선입니다. GPU가 CPU에 대해 갖는 우위는 슬라이드에 찍어낼 수 있는 단일 숫자가 아닙니다. 그것은 호출당 얼마만큼의 작업을 넘겨주느냐의 함수입니다. 우리의 멀티 타임프레임 지표 사전 계산에서, CPU 엔진 대비 GPU의 속도 향상은 한 번에 파라미터 조합 하나를 요청할 때 54.5배부터 61개를 한꺼번에 요청할 때 359.6배까지 이릅니다. 같은 커널, 같은 데이터, 같은 하드웨어 — 바뀐 것은 오직 배치뿐입니다. 그 숫자 중 하나만 보고하고 다른 하나를 숨기는 벤치마크는 GPU를 측정하는 것이 아니라 헤드라인을 고르는 것입니다.

그리고 359.6배조차 보이는 그대로가 아닙니다. 뜯어보면 멀티 타임프레임의 커다란 헤드라인 167배는 27배의 알고리즘 — CPU도 27배 빠르게 만드는 재작성 — 곱하기 6.2배의 실제 하드웨어로 분해됩니다. 27배를 해낸 것은 GPU가 아닙니다. 수학이 해냈습니다. 이 글은 그 둘을 구분하는 이야기입니다. 둘을 뒤섞는 것이야말로 git commit 하나면 공짜로 풀렸을 문제를 풀겠다고 2,000달러짜리 그래픽 카드가 팔려나가는 방식이기 때문입니다.

출처: 아래의 모든 숫자는 Apple M2 Max에서 측정되었습니다 — MLX를 통한 Metal GPU 위의 fp32 대 12개 CPU 스레드 위의 fp64 numba이며, 우리의 engine_multitf_gpu.py와 bench_param_sweep.py 벤치마크 스크립트에서 나왔고, 각각은 GPU 경로와 CPU 경로가 동일한 트레이드를 내는지 확인하는 동등성 검사로 게이팅됩니다. 이번 건에는 공개된 동반 논문이 없습니다 — 스크립트가 곧 기록입니다.

질문은 벤치마크가 아니라 루프라인이다

"GPU가 얼마나 더 빠른가"에 단일한 답이 없는 이유는 루프라인 모델(Williams, Waterman & Patterson, 2009) 때문입니다. 프로세서가 달성 가능한 성능은 두 개의 천장에 동시에 제한됩니다: 최대 연산 성능(FLOP/s)이 정하는 평평한 천장과, 메모리 대역폭 곱하기 산술 강도 — 이동한 바이트당 수행하는 유용한 연산의 수 — 가 정하는 비스듬한 천장입니다. 바이트당 저렴한 작업은 비스듬한 천장 아래에 살며 대역폭 바운드이고, 바이트당 풍부한 작업은 평평한 천장에 도달하며 연산 바운드입니다. GPU의 평평한 천장은 CPU의 것 위로 우뚝 솟아 있지만, 그것의 비스듬한 천장과 — 결정적으로 — 그것의 호출당 고정 비용은 그만큼 우아하게 줄어들지 않습니다.

파라미터 스윕에서는 세 번째 항이 차트의 왼쪽을 지배합니다: 실행 및 전송 오버헤드. 모든 GPU 호출은 대략 고정된 값을 치릅니다 — 커널을 디스패치하고, 입력을 (Apple Silicon에서는 통합되어 있지만 공짜는 아닌) 메모리 경계 너머로 옮기고, 결과를 되가져옵니다. $B$개 조합으로 이루어진 배치의 실제 소요 시간을 다음과 같이 모델링합니다

$T_{\text{gpu}}(B) = O + b\,B, \qquad T_{\text{cpu}}(B) = a\,B$

여기서 $O$는 그 고정 오버헤드, $b$는 GPU의 콤보당 한계 비용, $a$는 CPU의 것입니다. 그러면 속도 향상은

$S(B) = \frac{a\,B}{O + b\,B} \;\xrightarrow{B \to \infty}\; \frac{a}{b}.$

이 하나의 분수가 이 글 전체를 설명합니다. 작은 $B$에서는 분모의 $O$가 비율을 짓뭉갭니다 — GPU를 깨우는 값을 치렀는데 거의 쓰지 못한 것입니다. $B$가 커지면 $O$를 더 많은 콤보에 걸쳐 상각하게 되고, 속도 향상은 그 점근선 $a/b$, 즉 진짜 하드웨어 비율을 향해 올라갑니다. 절반 지점은 $B = O/b$에 있습니다: GPU가 낼 수 있는 성능의 절반이라도 내려면 스윕이 얼마나 넓어야 하는지를 알려주는, 배치 공간의 "능선점"입니다. 수십 개 콤보짜리 스윕은 그 능선 한참 왼쪽에 있습니다. 수천 개짜리 스윕은 GPU가 마침내 자신의 천장을 벌어들이는 평평한 부분에 있습니다.

그러니 옳은 질문은 결코 "GPU가 더 빠른가"가 아닙니다. 그것은 "내 스윕이 능선의 오른쪽에 있는가, 그리고 내 콤보당 작업이 거기 도달했을 때 평평한 천장에 닿을 만큼 충분히 연산 바운드인가"입니다. 둘 다 참이어야 합니다. 이 글의 나머지는 그 문턱값들이 실제로 어디에 떨어지는지를 측정합니다.

단일 타임프레임 평결: GPU가 겨우 이긴다

속도 사다리가 쓴 워크로드에서 시작합시다: 단일 타임프레임 HMA/HMA3 스윕, 150,000개 바에 걸친 80개 조합. 우리는 그 사다리에 여섯 번째 단을 추가했습니다 — M5, MLX를 통한 Apple GPU 위의 지표이며, 트레이드는 여전히 CPU에서 추출합니다. 워밍업 완료, 3회 중 최선, 동등성 게이트는 초록불:

순진한 순차 기준선에 대비하면 GPU는 영웅처럼 보입니다 — 2,796배. 하지만 그것은 정직한 사람이라면 누구도 해서는 안 될 비교입니다: 좋은 GPU 구현을 최악의 CPU 구현과 맞붙이는 것이니까요. GPU를 여러분이 실제로 배포할 CPU와 나란히 세우면 — 12개 코어 전부에서 도는 동일한 커널, M4 — 승리는 냉정한 3.2배로 무너집니다(초당 779 대 246 콤보). 그래픽 카드 한 장 전체가 스윕 전부를 돌려서, 12코어 CPU 풀을 세 배 차이로 이깁니다.

3.2배는 아무것도 아닌 게 아닙니다. 그렇다고 누군가가 GPU를 사는 이유도 아닙니다. 그리고 이것은 이만큼 좁은 스윕에 대해 루프라인이 예측하는 바로 그것입니다: 80개 콤보는 능선의 왼쪽입니다. 고정된 실행·전송 오버헤드 $O$는 여전히 0.10초짜리 작업에서 의미 있는 몫을 차지하므로, 우리는 점근선 $a/b$에 결코 도달하지 못합니다. 더 나쁘게는, 콤보당 비용의 일부가 O(n) 트레이드 추출 패스인데, 우리는 이것을 의도적으로 CPU에 남겨두었습니다 — GPU가 전혀 가속할 수 없는 항입니다(그 이유는 다음 섹션에서 더 다룹니다). 이 크기의 단일 타임프레임 리서치 루프에 대해서는, 속도 사다리의 원래 평결이 유효합니다: GPU는 빠진 단이 아니다. 병렬 numba가 이미 여러분을 0.23–0.33초에 데려다 놓았고, 그것을 0.10초로 깎는 것은 리서처를 막고 있던 것을 풀어주지 못합니다. 스윕을 둘러싼 오케스트레이션이 그렇게 합니다.

그 평결에서 흥미로운 단어는 이 크기입니다. 배치 축을 따라 오른쪽으로 움직이면 이야기가 바뀝니다.

비용이 실제로 어디에 있는가

배치를 키우기 전에, 우리가 실제로 무엇에 값을 치르고 있는지 봅시다. 루프라인은 비싼 부분이 연산 바운드일 때만 보상을 주기 때문입니다. 스윕을 프로파일링하면 거의 전부가 한 가지입니다: 가중 이동평균 컨볼루션. HMA는 세 번의 WMA이고, HMA3는 네 번이며, 모든 조합이 그것들을 전체 시리즈에 걸쳐 다시 실행합니다. 트레이드 추출 — 두 지표 배열을 훑고, hma - hma3의 부호 뒤집힘을 찾고, 체결을 기록하는 것 — 은 저렴한 O(n) 패스 한 번입니다. 이 스윕은 트레이딩 전략의 의상을 걸친 컨볼루션 워크로드입니다.

그 분리는 정확히 루프라인의 두 영역입니다:

• 컨볼루션은 연산 바운드입니다. 각 가격은 여러 겹치는 윈도우 합으로 읽혀 들어가므로, 산술 강도 — 이동한 바이트당 연산 — 가 높습니다. 이 작업은 평평한 연산 천장을 향해 손을 뻗으며, GPU의 평평한 천장이야말로 우뚝 솟은 그것입니다. 더 나아가, 윈도우는 조합들 사이에서 겹칩니다: 길이 40짜리 WMA는 수십 개의 콤보에 유용하므로, 배치된 사전 계산은 그것을 콤보마다 다시 계산하는 대신 한 번 공유합니다. 배치는 단지 실행 오버헤드를 상각하는 것만이 아닙니다 — 로드를 재사용함으로써 산술 강도를 끌어올립니다. 이것이 GPU에 속하는 부분입니다.
• 트레이드 추출은 대역폭 바운드이며 분기가 많습니다. 순차 패스 한 번, 크로스마다 데이터에 의존하는 분기, 사실상 재사용 없음. 그것의 산술 강도는 바닥에 가깝고, 그것의 제어 흐름은 SIMD 장치에 적대적입니다. 그것을 GPU로 밀어붙이면 얻는 것은 적고 드는 비용은 큽니다. 그러니 CPU에 남습니다. 이는 곧 그것이 암달의 법칙 분할의 순차적 꼬리라는 뜻입니다 — GPU 속도 향상이 결코 뚫을 수 없는 고정된 바닥이며, 단일 TF 숫자가 3.2배에서 포화한 이유의 일부입니다.

이 커널의 멀티 타임프레임 버전 속에는 두 번째의, 더 날카로운 교훈이 숨어 있으며, 그것이 바로 우리가 설명하겠다고 계속 약속해 온 27배의 원천입니다. 멀티 TF 엔진은 상위 타임프레임 HMA를 미래 참조 없이 기본 1분 인덱스에 정렬합니다. 뻔한 방식으로 작성하면, 그것은 바당 O(length^1.5) 작업입니다 — 모든 기본 바에서 상위 TF 이동평균을 다시 계산하는 것. 하지만 정렬된 HMA는 마지막으로 확정된 몇 개의 상위 TF 캔들의 짧은 버퍼 더하기 진행 중인 종가에 대해 선형이므로, 바당 계산 전체가 하나의 고정 가중치 벡터로 붕괴합니다: 확정된 캔들 시리즈에 대한 conv1d 한 번, 그 뒤를 잇는 O(n) 게더. 수억 번의 중복 연산이 훨씬 짧은 시리즈에 대한 컨볼루션 하나가 됩니다.

그 붕괴는 하드웨어 승리가 아니라 알고리즘 승리입니다. 더 나은 공식입니다. 그것은 GPU에서 돌고, CPU에서도 똑같이 잘 돕니다 — fp64로, np.correlate 더하기 게더. 이것을 단단히 기억해 두십시오: 멀티 TF 헤드라인에서 가장 큰 단일 요인은 GPU가 아예 없는 기계에서도 쓸 수 있는 재작성입니다. 우리가 마침내 167배를 분해할 때, 이것이 그 27배입니다.

우위는 배치 크기와 함께 커진다

이제 루프라인이 우리에게 하라고 한 측정입니다. 비싼 축 — 1분 기본 시리즈 위의 정렬된 상위 타임프레임 HMA 사전 계산, 우리가 가진 가장 긴 캔들 스트림 — 을 잡고, GPU에 호출당 점점 더 많은 길이 조합을 먹입니다, $B = 1, 2, 4, \dots, 61$. 여기서 CPU 기준선은 정직한 프로덕션 엔진입니다: 12개 코어 전부에 걸친 prange numba. 각 배치에 대해 우리는 양쪽을 측정하고 비율을 취합니다.

이것은 실제 측정으로 그린 $S(B) = aB/(O + bB)$입니다. $B = 1$에서 GPU는 이미 54.5배 앞서 있습니다 — 이 비교가 순진한 바당 엔진을 상대로 한 것이라, 알고리즘 붕괴가 콤보 하나에서도 이미 녹아 있기 때문입니다 — 하지만 천장에는 근처에도 못 갑니다: 콤보 하나짜리 호출은 여전히 고정 오버헤드가 지배합니다. 배치를 두 배로 하면 속도 향상은 거의 두 배인 102.5배가 되고, $B = 16$에서는 267.4배, $B = 61$에서는 359.6배이며 눈에 띄게 여전히 오르고 있습니다. 우위는 문제의 크기와 함께 커집니다. 이것이 GPU와 파라미터 스윕에 관한 가장 중요한 단 하나의 문장이며, GPU 속도 향상이 보통 인용되는 방식 — 마치 칩의 상수 속성인 것처럼 — 과 정확히 정반대입니다.

정직함을 위한 두 가지 참고, 이것은 환상 없는 백테스트 시리즈이고 깔끔하게 단조로운 표는 언제나 의심받아 마땅하니까요.

첫째, 하락: $B = 32$는 245.0배로 읽히며, $B = 16$의 267.4배보다 낮습니다. 이것은 양탄자 밑으로 쓸어 넣을 노이즈가 아닙니다 — 청크 경계 아티팩트입니다. 우리의 conv1d는 32개 길이를 하나의 커널 청크에 담으므로, $B = 32$는 여유 없이 정확히 한 청크를 채우는 반면, $B = 61$은 마침 장치를 더 잘 포화시키는 두 번째 청크로 넘칩니다. 루프라인의 요점은 추세이고, 실제 장치에는 양자화 단계가 들어 있습니다. 우리는 그 흔들림을 골라내 피하기보다 그대로 보고합니다.

둘째, 그리고 더 중요한 것: 54.5배와 359.6배는 둘 다 순진한 CPU 엔진을 상대로 한 것이며, 어느 쪽도 하드웨어 승리가 아닙니다. 두 숫자 모두 여전히 27배의 알고리즘 붕괴를 담고 있습니다. CPU 기준선을 CPU에서 도는 붕괴된 알고리즘으로 바꾼다면 — 같은 공식, fp64, 양쪽 다 최적화 — 모든 행이 대략 그 배수만큼 줄어들 것입니다. 그것이 바로 다음 섹션이 정확하게 만드는 분해입니다.

정직한 분해: 27배 알고리즘 곱하기 6.2배 하드웨어

알고리즘을 실리콘에서 분리하려면 동일한 멀티 타임프레임 그리드 위에서 두 개가 아니라 세 개의 경로를 측정해야 합니다. 그래서 벤치마크는 다음을 실행합니다:

1. cpu-engine — 프로덕션 numba 엔진, 모든 코어에 걸친 바당 정렬 HMA. 순진하지만-병렬인 기준선.
2. cpu-collapsed — 붕괴된 가중치 벡터, np.correlate 더하기 게더, fp64, CPU에서. (1)과 같은 하드웨어, 더 나은 알고리즘.
3. gpu-mlx — 붕괴된 가중치를 Metal GPU 위의 배치된 conv1d로, fp32. (2)와 같은 알고리즘, 다른 하드웨어.

이들을 나란히 세우면 전체 멀티 타임프레임 헤드라인이 깔끔하게 인수분해됩니다:

$\underbrace{167\times}_{\text{gpu vs naive CPU}} \;=\; \underbrace{27\times}_{\text{cpu-collapsed vs cpu-engine}} \;\times\; \underbrace{6.2\times}_{\text{gpu vs cpu-collapsed}}$

왼쪽 요인, 27배는 알고리즘입니다 — 이전 섹션의 바당-에서-컨볼루션으로의 붕괴. 그것은 GPU와 아무 상관이 없습니다. 그것을 numpy로 구현하면 여러분의 노트북 CPU는 리팩터링 값만 치르고 이 워크로드에서 27배 빨라집니다. 오른쪽 요인, 6.2배는 하드웨어입니다 — 12개 CPU 코어 위의 동일한 최적화된 알고리즘에 대한 Metal GPU의 정직한, 같은 조건의 승리. 그 6.2배야말로 여러분이 실제로 GPU가 있어야 얻을 수 있었던 유일한 부분입니다.

이것이 산술로 진술된 이 글의 전체 교훈입니다. 벤더 벤치마크, 라이브러리 README, 혹은 흥분한 동료가 여러분에게 "GPU에서 167배"를 보여줄 때, 반사적으로 나와야 할 것은 단 하나의 질문입니다: CPU 기준선이 무엇이었는가? 기준선이 순진한 구현이었다면 — 그리고 거의 항상 그렇습니다, 느린 기준선이 더 나은 슬라이드를 만드니까요 — 헤드라인 대부분은 CPU도 마땅히 누릴 자격이 있었던 알고리즘 승리이고, 오직 나머지만이 하드웨어입니다. 여기서 나머지는 6.2배입니다. 167배라는 인용은 하드웨어의 기여를 대략 27배만큼 과장합니다.

그리고 하드웨어 요인 자체가 문제 크기와 함께 어떻게 움직였는지 주목하십시오. 작은 단일 타임프레임 스윕에서 진짜 GPU 대 최선의 CPU 승리는 3.2배였습니다. 더 큰 멀티 타임프레임 사전 계산에서는 6.2배였습니다 — 같은 두 개의 칩, 거의 두 배의 하드웨어 우위이며, 순전히 더 큰 워크로드가 CPU가 보조를 맞추기 전에 루프라인을 따라 GPU의 평평한 연산 천장을 향해 더 멀리 밀어 올리기 때문입니다. 하드웨어 우위도 상수가 아닙니다. 그것은 동일한 상승 곡선 위의 한 점이며, 그 곡선에서 오른쪽으로 움직이는 방법은 배치를 더 크게, 콤보당 작업을 더 풍부하게 만드는 것입니다.

결정 가이드: 스윕은 얼마나 넓어야 하는가?

루프라인을 돈을 쓰기 전에 내릴 수 있는 결정으로 접어 넣읍시다. GPU는 루프라인의 두 조건이 동시에 성립할 때 값어치를 합니다: 여러분의 스윕이 배치 능선의 오른쪽이고($B \gg O/b$, 그래서 고정된 실행·전송 오버헤드가 상각되고), 여러분의 콤보당 작업이 연산 바운드일 때(얇은 O(n) 패스가 아니라, 평평한 천장에 닿을 만큼 충분히 풍부한 산술 강도). 구체적으로, 우리가 측정한 바로부터:

• 단일 타임프레임 전략의 수십 개 콤보: GPU를 건너뛰십시오. 여러분은 능선의 왼쪽에 있습니다. 병렬 numba에 대한 정직한 승리는 이미 10분의 1초 걸리는 작업에서 ~3.2배입니다. 병목은 커널이 아니라 그것을 둘러싼 모든 것입니다.
• 수천 개의 콤보, 혹은 진정으로 멀티 타임프레임 / 멀티 지표 사전 계산: GPU가 제자리를 벌어들입니다. 오버헤드가 상각되고, 공유된 컨볼루션이 산술 강도를 끌어올리며, 하드웨어 승리는 6.2배로 올라가 배치와 함께 계속 상승합니다. 이것이 GPU가 밤샘 스윕을 커피 한 잔의 휴식으로 바꾸는 영역입니다.
• 먼저 CPU 사다리를 오르십시오 — 더 싸고, 순서상 먼저입니다. CPU에서의 298배와 27배의 알고리즘 붕괴는 공짜이거나 거의 공짜이며, 대안이 아니라 전제 조건입니다: GPU의 6.2배는 어차피 작성해야 했던 붕괴된 알고리즘 위에 얹힙니다. 순진한 파이프라인에 볼트로 조여 붙인 GPU는 대개 그 순진함을 측정합니다.

GPU 갈래에는 속도와는 아무 상관 없는 세금도 있으며, 여러분은 그것을 가격에 반영해야 합니다: Apple의 Metal GPU에는 fp64가 아예 없습니다. 모든 것이 fp32, 상대 정밀도 ~1.2e-7로 돕니다. 이것은 빠른 이동평균을 위한 교과서 트릭 — O(n) 접두합 WMA — 을 죽여버립니다. 150k 바에 걸쳐 30,000 근처의 가격 스케일에서 진행 중인 합이 ~1e14에 이르는데, 이는 fp32의 안전한 정수 범위를 일곱 자릿수나 넘어서기 때문입니다. 우리는 최대 ~2e2의 상대 오차를 측정했습니다(2퍼센트가 아니라 200배). 작동하는 정식화는 직접 윈도우 컨볼루션이며, 여기서는 각 윈도우 합이 비슷한 크기의 항 유한 개로 이루어져 fp32가 ~8e-7까지 정확하게 유지됩니다. 그런데도, hma - hma3의 부호로 결정하는 전략은 두 곡선이 거의 맞닿는 경계선 바에서 이따금 크로스를 뒤집습니다. fp32 반올림이 아슬아슬한 무승부를 한쪽으로 기울이기 때문입니다. 그래서 GPU 경로는 결코 내놓을 수 없는 비트 단위 동일 출력을 단언하는 대신, 트레이드가 얼마나 발산했는지를 측정하는 동등성 게이트 — 베이시스 포인트 단위의 PnL 델타, 트레이드 수의 상대적 이동 — 와 함께 출하됩니다. 우리 실행에서 그 발산은 479,016개 중 90개의 이동된 체결(0.019%)로, 허용 범위에 넉넉히 들어왔지만, 부담은 실재합니다: GPU로 간다는 것은 단지 더 빠른 시계가 아니라 수치 일치성 이야기를 떠안는 것을 의미합니다. 그 엔지니어링 비용도 손익분기의 일부입니다.

숫자는 Apple 모양이지만, 곡선은 그렇지 않다

위의 모든 수치는 Apple M2 Max입니다: GPU와 CPU가 하나의 풀을 공유하는 통합 메모리 장치이자, 배정밀도가 없는 fp32 전용 GPU. 개별 NVIDIA나 AMD 카드는 상수를 바꾸며, 각각이 어느 방향으로 움직이는지 명시할 가치가 있습니다. 숫자는 살아남지 못하더라도 논증의 형태는 살아남기 때문입니다.

• 전송 오버헤드 $O$는 나아지는 게 아니라 나빠집니다. 개별 카드는 PCIe 뒤에 앉아 있어서, 입력과 결과가 통합 메모리라면 피했을 실제 복사를 버스 너머로 만듭니다. 그것은 배치 능선 $O/b$를 오른쪽으로 밀어냅니다 — 개별 GPU가 실행 비용을 상각하려면 더욱 넓은 스윕이 필요합니다. 루프라인의 왼쪽 가장자리는 PCIe 장치에서 더 완만한 게 아니라 더 가파릅니다.
• 평평한 천장 $a/b$는 더 높아집니다. 데이터센터 GPU는 통합형보다 훨씬 많은 FLOP/s와 대역폭을 가지므로, 포화하는 스윕에서 점근적 하드웨어 승리는 우리의 6.2배보다 큽니다. 곡선의 오른쪽에 도달하는 보상이 커집니다. 왼쪽에 앉아 있는 대가도 커집니다.
• fp64가 돌아오고, 그와 함께 접두합 트릭도 돌아옵니다. 진짜 배정밀도가 있는 카드에서는 O(n) 접두합 WMA가 다시 실행 가능해지고, 일치성 게이트는 비트 단위 정확성을 향해 조여질 수 있습니다. 우리가 치른 특정 fp32 세금 — 접두합 대신 직접 컨볼루션, assert 대신 발산을 측정하는 게이트 — 은 법칙이 아니라 Apple Silicon의 세부 사항입니다.

이 중 어느 것도 테제를 바꾸지 않습니다. 어떤 장치에서든, $S(B) = aB/(O + bB)$: 여러분이 상각해야 하는 고정 오버헤드, 오직 오른쪽에서만 다가가는 점근선. 상수는 하드웨어이고, 곡선은 산술입니다. 누구의 헤드라인이든 — 우리 것을 포함해서 — 믿기 전에, 다섯 줄짜리 배치 스윕으로 여러분 자신의 $O$, $a$, $b$를 측정하십시오.

이것이 어디로 연결되는가

이것은 백테스트 속도가 실제로 어디에서 오는가에 관한 작은 하위 시리즈의 네 번째 측정이며, 각 조각은 돈을 쓰기 전에 무엇을 최적화할 것인가에 관한 하나의 논증으로 맞물립니다:

• 속도 사다리는 CPU만으로 298배를 내며 pandas에서 병렬 numba까지 올라갔고, GPU는 열린 질문으로 남겨두었습니다. 이 글이 그에 답합니다: GPU는 실재하지만 조건부인 다섯 번째 단이며, 최상위 CPU 단 대비 3.2배–6.2배의 값어치가 있고, 오직 스윕이 루프라인을 오를 만큼 충분히 넓어졌을 때만 그렇습니다.
• IPC 세금은 같은 수를 반대 방향으로 두었습니다 — 프로세스를 벗어나는 데 드는 비용을 측정하며 — 그리고 같은 형태의 결론에 도달했습니다: 경계(소켓, GPU 실행)는 저렴하고, 세금은 그것을 얼마나 자주, 얼마나 수다스럽게 건너느냐에 있습니다. IPC를 배치하는 것과 같은 이유로 GPU 호출을 배치하십시오: 건널 때마다 드는 고정 비용을 상각하기 위해서.
• 집계된 parquet 캐시는 GPU 사전 계산이 하는 일의 CPU 쪽 버전입니다 — 공유 지표를 한 번 계산하고, 모든 콤보에 걸쳐 재사용하는 것. GPU는 그 재사용-및-배치 원리를 실리콘으로 가져갈 뿐입니다.
• 그리고 fp32 일치성 게이트는 백테스트-라이브 일치성 문제의 축소판입니다: 여러분의 빠른 경로가 참조값과 조금이라도 다른 것을 계산하는 순간, 여러분은 손사래가 아니라 발산에 대한 정량화된 설명을 빚지게 됩니다.

연결하는 규율은 이 시리즈 전체가 밀어붙이는 바로 그것입니다: 여러분이 실제로 팔리고 있는 그것을 측정하라. 속도 향상은 비율이고, 비율에는 분자와 분모가 있습니다. 대부분의 GPU 실망은 아첨하도록 고른 분모 — CPU 기준선 — 에서 오고, 대부분의 GPU 낭비는 루프라인의 왼쪽 가장자리를 벗어나기에 너무 작은 스윕을 돌리는 데서 옵니다.

핵심 요점

1. GPU 속도 향상은 숫자가 아니라 곡선입니다. 우리의 멀티 타임프레임 사전 계산에서 CPU에 대한 우위는 호출당 콤보 하나일 때 54.5배부터 예순한 개일 때 359.6배까지 이르렀습니다 — 같은 칩, 같은 데이터. 어떤 단일 수치든 그 곡선 위의 한 점입니다. 그것이 어떤 배치 크기에서 측정되었는지 물으십시오.
2. CPU 기준선을 항상 심문하십시오. 167배라는 멀티 타임프레임 헤드라인은 27배의 알고리즘(바당-에서-컨볼루션으로의 붕괴로, CPU도 똑같이 빠르게 만듭니다) 곱하기 6.2배의 실제 하드웨어로 깔끔하게 인수분해됩니다. 여기서 공정한 GPU 대 최선의 CPU 승리는 단일 타임프레임에서 3.2배, 멀티에서 6.2배이지 167배가 아닙니다.
3. 우위는 문제 크기와 함께 커지고, 하드웨어 요인도 마찬가지입니다. 더 큰 배치와 더 풍부한 콤보당 작업이 여러분을 루프라인 위로 밀어 올립니다: 정직한 하드웨어 승리 자체가 순전히 워크로드를 더 크게 만드는 것만으로 3.2배에서 6.2배로 올랐습니다. 작은 스윕은 능선의 왼쪽에 앉아 거의 이득을 못 봅니다.
4. 먼저 알고리즘을 고치고 CPU 사다리를 오르십시오 — GPU 승리는 그것들 대신이 아니라 그것들 위에 얹힙니다. 6.2배는 어차피 작성해야 했던 붕괴된 알고리즘을 상대로 측정된 것입니다. 순진한 파이프라인에 GPU를 볼트로 조여 붙이면, 여러분이 측정하는 것 대부분은 실리콘이 아니라 그 순진함입니다.
5. GPU로 간다는 것은 수치 일치성 이야기를 떠안는 것을 의미합니다. Metal에는 fp64가 없고, 접두합 WMA 트릭은 가격 스케일에서 죽으며(상대 오차 ~2e2), 크로스-부호 전략은 경계선 바에서 뒤집힙니다. 발산을 베이시스 포인트로 정량화하는 동등성 게이트를 출하하고, 그 엔지니어링 비용을 손익분기에 셈하십시오.

누군가가 GPU가 자기 백테스트를 백 배 빠르게 만들었다고 말한다면, 그는 여러분에게 사실상 아무것도 말하지 않은 것입니다. 그에게 배치 크기와 CPU 기준선을 물어보십시오. 그러면 그 백 배는 대개 공짜로 가질 수 있었던 알고리즘 승리를 감싼 한 자릿수 하드웨어 승리로 풀립니다 — 충분히 큰 스윕에서라면, 정확히 루프라인이 말하는 이유로, 그 이상 단 하나의 이유도 없이 가질 값어치가 있는 것입니다.