@ Laurae2 GBT 벤치 마크를 준비해 주셔서 감사합니다. 문제 지점을 식별하는 데 도움이되었습니다.

@ hcho3 OpenMP guided 일정이 부하 분산에 도움이됩니까? 그렇다면 ellpack은 그다지 유용하지 않을 것입니다.

내 생각에 ellpack을 사용한 작업의 정적 할당은 OpenMP의 guided 또는 dynamic 모드보다 낮은 오버 헤드로 균형 잡힌 워크로드를 달성 할 것입니다. dynamic 를 사용하면 작업 도용 대기열을 유지하는 데 드는 런타임 오버 헤드가 발생합니다.

약간의 주제에서 벗어난 것일 수 있습니다. approx 의 벤치 마크 결과가 있습니까?

우리는 내부 환경에서 멀티 스레딩을 사용하여 최적이 아닌 속도 향상을 발견합니다. 다른 사람의 데이터를보고 싶어합니다.

@CodingCat 연결된 벤치 마크 제품군은 hist 만 사용합니다. approx 가 hist 와 같은 성능 저하를 표시합니까 (예 : 3 개 스레드보다 36 개 스레드가 느림)?

@ hcho3 클러스터의 제한으로 인해 최대 8 개의 스레드로만 테스트 할 수

@CodingCat 8 스레드가 4보다 느리게 실행된다는 의미입니까?

@CodingCat approx 은 (는) 스케일링이 너무 나빠서 벤치마킹도하고 싶지 않았습니다. 4 코어 노트북 (3.6GHz)에서도 제대로 확장되지 않기 때문에 64 또는 72 스레드로 상상조차 할 수 없습니다.

@ hcho3 나중에 VTune과 함께 저장소를 사용하여 살펴볼 것입니다.

VTune에서 자세한 성능을 얻으려는 사람들은 다음을 사용하여 헤더에 추가 할 수 있습니다.

#include <ittnotify.h> // Intel Instrumentation and Tracing Technology

루프 외부에서 추적하려는 항목 앞에 다음을 추가합니다 (문자열 / 변수 이름 변경).

__itt_resume();
__itt_domain* domain = __itt_domain_create("MyDomain");
__itt_string_handle* task = __itt_string_handle_create("MyTask");
__itt_task_begin(domain, __itt_null, __itt_null, task);

루프 외부에서 추적하려는 항목 뒤에 다음을 추가합니다 (문자열 / 변수 이름 변경).

__itt_task_end(domain);
__itt_pause();

그리고 스레드 수에 대한 올바른 매개 변수를 사용하여 VTune으로 프로젝트를 시작하십시오. 성능 분석을 수행하려면 일시 중지 된 계측으로 실행 파일을 시작합니다.

@ hcho3 더 느리지는 않지만 4 개의 스레드를 더 추가하면 15 % 정도의 속도 만 향상 될 수 있습니다 ... (더 많은 실험을 수행하면 결과가 수렴 될 것으로 의심됩니다 .....

@ Laurae2 는 내가 유일한 사람이 아닌 것 같습니다.

@ hcho3 exact , approx 및 hist , 모두 depth=6 하지 않는 경우 이번 주가 끝나기 전에 몇 가지 확장 결과를 얻을 수 있도록 노력하겠습니다 exact depth=6 , 커밋 e26b5d6.

최근에 컴퓨팅 서버를 마이그레이션했으며 이번 주에는 3.7GHz 전체 터보 / 36 코어 / 72 스레드 / 80GBps RAM 대역폭을 갖춘 새 컴퓨터에서 Bosch의 새로운 벤치 마크를 다시 수행하고 있습니다.

fast_hist 업데이트 프로그램은 분산 된 xgboost의 경우 훨씬 더 빠릅니다. @CodingCat 아무도 AllReduce 호출을 추가하려고 시도하지 않았기 때문에 분산 모드에서 작동한다는 것에 놀랐습니다.

@RAMitchell 저는 fast_hist 업데이터를 작성할 때 꽤 새롭기 때문에 분산 모드 지원이 부족합니다. 0.81 릴리스 이후에 얻고 싶습니다.

@ Laurae2 FYI, C5.9xlarge 시스템에서 벤치 마크 제품군을 실행했는데 XGBoost hist 결과가 이전 결과와 일치하는 것 같습니다. 원하시면 번호를 올려 드릴 수 있습니다.

@ Laurae2 또한 EC2 머신에 액세스 할 수 있습니다. EC2 인스턴스에서 실행하려는 스크립트가 있으면 알려주십시오.

@RAMitchell 저는 fast_hist 업데이터를 작성할 때 꽤 새롭기 때문에 분산 모드 지원이 부족합니다. 0.81 릴리스 이후에 얻고 싶습니다.

@ hcho3 괜찮다 면 분산 된 더 빠른 히스토그램 알고리즘을 얻기 위해 도전 할 수 있습니다. 저는 현재 Uber 작업에서 절반을 차지하고 있으며 내년에는 xgboost에 더 많은 시간을 할애 할 수 있습니다.

@CodingCat 그거 좋을 것입니다, 감사합니다! '히 스트'코드에 대해 궁금한 점이 있으면 알려주세요.

@CodingCat 참고로, 0.81 릴리스 직후 'hist'업데이터에 대한 단위 테스트를 추가 할 계획입니다. 분산 지원을 추가 할 때 도움이 될 것입니다.

@ hcho3 @CodingCat approx 가 지난달에 제거 된 것 같습니다. 예상되는 동작입니까?

https://github.com/dmlc/xgboost/commit/70d208d68c3a32aaa4fcd6aa456f286a4da5912f#diff -53a3a623be5ce5a351a89012c7b03a31 (PR https://github.com/dmlc/xgboost/pull/3395 제거됨 tree_method = approx ?) => 동일 해짐 약과 비 약 사이의 결과 ...

@ Laurae2 리팩터링이 approx 선택에 대한 정보 메시지를 제거한 것 같습니다. 그렇지 않으면 approx 를 계속 사용할 수 있습니다.

@ Laurae2 사실, 당신이 맞습니다. approx 가 여전히 코드베이스에 있지만 어떤 이유로 tree_method=approx 가 설정되어 있어도 호출되지 않습니다. 이 버그를 최대한 빨리 조사하겠습니다.

문제 # 3840이 제출되었습니다. 릴리스 0.81은이 문제가 수정 될 때까지 릴리스되지 않습니다.

@ hcho3 빠른 히스토그램으로 내 서버에서 매우 이상한 것을 발견하고 있습니다. 내일 벤치 마크 계산이 완료되면 결과를 알려 드리겠습니다 (빠른 히스토그램의 엄청난 부정적인 효율성에 대해 이야기하고 있습니다. 너무 큽니다. 측정하기 위해 너무 오래 걸리지 않기를 바랍니다.)

대략적으로 효율성이 낮다는 것이 예상보다 훨씬 좋지만, 어떤 컴퓨터에서도 사실 일 것이라고는 생각하지 않습니다. 빠른 히스토그램이 서버에 완료되면 데이터를 게시하겠습니다.

자세한 내용은 477 개의 기능 (결 측값이 5 % 미만인 기능)이있는 Bosch 데이터 세트를 사용하고 있습니다.

3000 시간 이상의 CPU 시간에 도달했습니다 ... (적어도 내 서버는 잠시 동안 잘 사용됩니다) 다음은 https://github.com/hcho3/xgboost-fast-hist-perf- lab / blob / master / src / build_hist.cc ( Intel VTune 포함).

@ hcho3 원하는 경우 서버가 컴퓨팅을 완료하면 벤치 마크 R 스크립트를 제공 할 수 있습니다. depth=8 및 nrounds=50 , 모든 tree_method=exact , tree_method=approx ( updater=grow_histmaker,prune 해결 방법 사용, # 3849 이전) 및 tree_method=hist , 스레드 1 개에서 72 개. 작업 할 더 흥미로운 것을 발견 할 수 있습니다 (그리고 AWS에서도 테스트 할 수 있습니다).

아래의 예비 결과를 참조하여 평균 결과를 7 회 실행했습니다. 더 잘 보려면 클릭하십시오. 합성 테이블이 제공됩니다. 플롯 쇼와 달리 CPU는 고정되지 않았습니다.

차트는 내가 준비한 차트와 분명히 다르게 보입니다 ... (동작이 얼마나 이상하기 때문에 UMA를 켜고 (NUMA를 끈 상태에서) 이것을 다시 실행하고 있습니다). 나중에 Intel VTune에서 확인하겠습니다.

하드웨어와 소프트웨어:

• CPU : Dual Xeon Gold 6154, 3.7GHz 올 터보, 2x 18 코어 / 36 스레드
• RAM : 4x 64GB RAM DDR4 2666MHz (듀얼 채널, 약 80GBps 대역폭)
• BIOS : NUMA 켜기, 하위 NUMA 클러스터링 끄기
• 운영 체제 : Pop_OS! 18.10
• 주지사 : 성능
• 커널 : 4.18.0-10
• 커널 플래그 : pti=off spectre_v2=off spec_store_bypass_disable=off l1tf=off noibrs noibpb nopti no_stf_barrier
• 컴파일러 : gcc 8.2.0
• R : gcc 8.2.0 및 Intel MKL로 컴파일 된 3.5.1
• R의 추가 컴파일 플래그 : -O3 -mtune=native

멜트 다운 / 스펙터 보호 :

laurae@laurae-compute:~$ head /sys/devices/system/cpu/vulnerabilities/*
==> /sys/devices/system/cpu/vulnerabilities/l1tf <==
Mitigation: PTE Inversion; VMX: vulnerable

==> /sys/devices/system/cpu/vulnerabilities/meltdown <==
Vulnerable

==> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass <==
Vulnerable

==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <==
Mitigation: __user pointer sanitization

==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <==
Vulnerable

| 스레드 | 정확함 (효율성) | 대략적인 (효율성) | Hist (효율성) |
| --- : | --- : | --- : | --- : |
| 1 | 1367 초 (100 %) | 1702 년대 (100 %) | 69.9 초 (100 %) |
| 2 | 758.7 초 (180 %) | 881.0 초 (193 %) | 52.5 초 (133 %) |
| 4 | 368.6 초 (371 %) | 445.6 초 (382 %) | 31.7 초 (221 %) |
| 6 | 241.5 초 (566 %) | 219.6 초 (582 %) | 24.1 초 (290 %) |
| 9 | 160.4 초 (852 %) | 194.4 초 (875 %) | 23.1 초 (303 %) |
| 18 | 86.3 초 (1583 %) | 106.3 초 (1601 %) | 24.2 초 (289 %) |
| 27 | 66.4 초 (2059 %) | 80.2 초 (2122 %) | 63.6 초 (110 %) |
| 36 | 52.9 초 (2586 %) | 60.0 초 (2837 %) | 55.2 초 (127 %) |
| 54 | 215.4 초 (635 %) | 289.5 초 (588 %) | 343.0 초 (20 %) |
| 72 | 218.9 초 (624 %) | 295.6 초 (576 %) | 1237.2 초 (6 %) |

xgboost 정확한 속도 :

xgboost 정확한 효율성 :

xgboost 대략적인 속도 :

xgboost 대략적인 효율성 :

xgboost 히스토그램 속도 :

xgboost 히스토그램 효율성 :

여러 소켓에 문제가있는 것 같습니다.

@RAMitchell NUMA 노드의 가용성에 문제가있는 것 같습니다. Sub NUMA 클러스터링 (1 소켓 = 2 NUMA 노드 대신 2 소켓 = 4 NUMA 노드)을 사용하여이 문제를 복제 할 수 있습니다 (훈련 중 스레드가 적을수록 결과가 더 나빠집니다). ).

대부분의 기계 학습 알고리즘과 마찬가지로 xgboost에는 NUMA 노드 처리를위한 최적화가 없습니다. 그러나 그것은 두 번째 문제가 될 것입니다. 따라서 다중 소켓 환경이나 COD (Cluster on Die) 또는 SNC (Sub NUMA Clustering)를 통해 NUMA 노드를 사용할 수있는 경우에는 적합하지 않으며, 하이퍼 스레딩으로 인해 워크로드 불균형이 크게 발생합니다.

문제 1은 xgboost hist 모드에서 멀티 스레드 성능이 크게 저하되는 문제입니다 (이 문제).

문제 2는 NUMA 최적화에 관한 것입니다 (열어야 할 또 다른 문제).

다음은 NUMA가 비활성화 된 결과입니다. 비교를 위해 NUMA가 활성화 된 결과를 페어링했습니다. 또한 CPU가 72 개의 스레드에서 커널 스케줄러로 압도되기 전에 성능을 보여주기 위해 71 개의 스레드를 추가했습니다 (사용 가능한 것보다 더 많은 리소스가 필요함).

멀티 스레딩의 경우 UMA 요금이 NUMA보다 훨씬 낫습니다. 이는 비 NUMA 인식 프로세스에서 메모리 인터리빙의 예상 결과입니다.

시간 시간 :

| 스레드 | 정확한
NUMA | 정확한
UMA | 대략
NUMA | 대략
UMA | Hist
NUMA | Hist
UMA |
| --- : | --- : | --- : | --- : | --- : | --- : | --- : |
| 1 | 1367 년대 | 1667 년대 | 1702 년대 | 1792 년대 | 69.9 초 | 85.6 초 |
| 2 | 758.7 초 | 810.3 초 ​​| 881.0 초 | 909.0 초 | 52.5 초 | 54.1 초 |
| 4 | 368.6 초 | 413.0 초 | 445.6 초 | 452.9 초 | 31.7 초 | 36.2 초 |
| 6 | 241.5 초 | 273.8 초 | 219.6 초 | 302.4 초 | 24.1 초 | 30.5 초 |
| 9 | 160.4 초 | 182.8 초 | 194.4 초 | 202.5 초 | 23.1 초 | 28.3 초 |
| 18 | 86.3 초 | 94.4 초 | 106.3 초 | 105.8 초 | 24.2 초 | 31.2 초 |
| 27 | 66.4 초 | 66.4 초 | 80.2 초 | 73.6 초 | 63.6 초 | 37.5 초 |
| 36 | 52.9 초 | 52.7 초 | 60.0 초 | 59.4 초 | 55.2 초 | 43.5 초 |
| 54 | 215.4 초 | 49.2 초 | 289.5 초 | 58.5 초 | 343.0 초 | 57.4 초 |
| 71 | 218.3 초 | 47.01 초 | 295.9 초 | 56.5 초 | 1238.2 초 | 71.5 초 |
| 72 | 218.9 초 | 49.0 초 | 295.6 초 | 58.6 초 | 1237.2 초 | 79.1 초 |

효율성 표 :

| 스레드 | 정확한
NUMA | 정확한
UMA | 대략
NUMA | 대략
UMA | Hist
NUMA | Hist
UMA |
| --- : | --- : | --- : | --- : | --- : | --- : | --- : |
| 1 | 100 % | 100 % | 100 % | 100 % | 100 % | 100 % |
| 2 | 180 % | 206 % | 193 % | 197 % | 133 % | 158 % |
| 4 | 371 % | 404 % | 382 % | 396 % | 221 % | 236 % |
| 6 | 566 % | 609 % | 582 % | 593 % | 290 % | 280 % |
| 9 | 852 % | 912 % | 875 % | 885 % | 303 % | 302 % |
| 18 | 1583 % | 1766 % | 1601 % | 1694 % | 289 % | 274 % |
| 27 | 2059 % | 2510 % | 2122 % | 2436 % | 110 % | 229 % |
| 36 | 2586 % | 3162 % | 2837 % | 3017 % | 127 % | 197 % |
| 54 | 635 % | 3384 % | 588 % | 3065 % | 20 % | 149 % |
| 71 | 626 % | 3545 % | 575 % | 3172 % | 6 % | 120 % |
| 72 | 624 % | 3401 % | 576 % | 3059 % | 6 % | 108 % |

UMA 모드.

xgboost 정확한 속도 :

xgboost 정확한 효율성 :

xgboost 대략적인 속도 :

xgboost 대략적인 효율성 :

xgboost 히스토그램 속도 :

xgboost 히스토그램 효율성 :

https://github.com/dmlc/xgboost/pull/3957#issuecomment -453815876에서 언급했듯이 커밋 a2dc929 (CPU 개선 전) 및 5f151c5 (CPU 개선 후) 커밋을 테스트했습니다.

듀얼 제온 6154 서버 (인텔이 아닌 gcc 컴파일러)를 사용하여 Bosch를 사용하여 500 회 반복, eta 0.10 및 깊이 8을 사용하고 1 ~ 72 개의 스레드에 대해 각각 3 번 실행을 테스트했습니다. 최대 성능에서 멀티 스레드 워크로드에 대해 약 50 % (1/3 더 빠름)의 성능 향상을 확인했습니다.

다음은 이전 # 3957 (커밋 a2dc929)에 대한 결과입니다.

다음은 # 3957 (커밋 5f151c5)에 대한 결과입니다.

효율성 곡선을 사용하면 확장 성이 50 % 증가하는 것을 볼 수 있습니다 (이는 문제가 해결되었음을 의미하는 것이 아닙니다. 가능하다면 여전히 개선해야합니다. 이상적으로는 미친 듯이 1000-2000 % 범위에 도달 할 수 있다면 큰).

a2dc929의 효율 곡선 :

5f151c5의 효율 곡선 :

@ Laurae2 감사합니다.이 문제를 고정하여 항상 문제 추적기의 맨 위에 있도록합니다. 실제로해야 할 일이 더 많습니다.

@ hcho3 @SmirnovEgorRu X 코어 x 1 xgboost 스레드에서 하이퍼 파라미터 튜닝을 수행 할 때 전체적으로 10 % -15 %의 패널티가 발생하는 커밋 5f151c5를 사용하여 100 % 고밀도 데이터의 단일 스레드 워크로드에서 작은 CPU 성능 회귀를보고 있습니다.

다음은 50M 행 x 100 개 열의 임의 밀도 데이터 (gcc 8)의 예입니다. Python / R에서 올바르게 훈련하려면 256GB 이상의 RAM이 필요하며 3 회 (6 일) 실행됩니다.

a2dc929 커밋 :

5f151c5 커밋 :

매우 유사한 다중 스레드 성능으로 이어지지 만 단일 스레드 성능은 더 느린 훈련에 의해 타격을받습니다 ( @SmirnovEgorRu 의 개선 사항은 여전히 ​​더 빠르게 확장되며, 이전에 13 개 스레드에 비해 11 개 스레드에서 500 % 효율성에 도달합니다).

gmat ​​생성 시간을 제외하고 50M x 100에서 단일 스레드를 사용합니다.

| 커밋 | 합계 | gmat ​​시간 | 기차 시간 |
| : --- | --- : | --- : | --- : |
| a2dc929 | 2926 년대 | 816 초 | 2109 초 |
| 5f151c5 | (+ 13 %) 3316 초 | (~ %) 817 초 | (+ 18 %) 2499 초 |

@ hcho3 @ Laurae2 일반적으로 하이퍼 스레딩은 메모리 바인딩 알고리즘이 아닌 코어 바인딩 알고리즘의 경우에만 도움이됩니다.
HT는 더 많은 실행 명령을 통해 CPU 파이프 라인을로드하는 데 도움이됩니다. 대부분의 명령이 이전 명령의 실행을 기다리는 경우 (대기 시간 제한)-HT가 실제로 도움이 될 수 있습니다. 일부 특정 워크로드에서 최대 1.5 배의 속도 향상을 관찰했습니다.
그러나 애플리케이션이 메모리 작업에 대부분의 시간을 소비하는 경우 (메모리 바인딩)-HT는 더욱 악화됩니다. 2 개의 하이퍼 스레드는 하나의 CPU 캐시를 공유하고 서로 유용한 정보를 대체합니다. 결과적으로 성능 저하가 발생합니다.
Gradient Boosting-메모리 바운드 알고리즘. HT 사용은 어떤 경우에도 성능 향상을 가져 오지 않아야하며 스레딩 대 1 스레드 버전으로 인한 최대 속도 향상은 하드웨어 코어 수에 의해 제한됩니다. 따라서 HT없이 CPU에서 성능을 측정하는 것이 좋습니다.

NUMA는 어떻습니까-DAAL 구현에서 동일한 문제를 관찰했습니다. 각 코어별로 메모리 사용량을 제어해야합니다. 앞으로 살펴 보겠습니다.

한 스레드에서 약간의 속도 저하는 어떻습니까? 조사하겠습니다. 제 생각에는 수정이 쉽습니다.

@ hcho3 현재 최적화의 다음 부분을 작업 중입니다. 가까운 장래에 새로운 풀 리퀘스트를 준비 할 수 있기를 바랍니다.

@SmirnovEgorRu 귀하의 노력에 다시 한번 감사드립니다. 참고로, 레벨 별 노드 확장을 수행하여 병렬 처리량을 늘리는 것에 대한 최근 논의가있었습니다 : # 4077.

@ Laurae2 이제 # 3957, # 4310 및 # 4529에 병합되었으므로 확장 문제가 해결되었다고 가정 할 수 있습니까? NUMA의 효과는 여전히 문제가 될 수 있습니다.

@ hcho3 나중에 확인하기 위해 다시 시도하지만 프로덕션 환경에서 성능 저하가 있음을 알 수 있습니다 (특히 # 3957로 인해 30 배 이상의 속도 저하가 발생 함).

@szilard 에서도 성능 결과를 확인

열기 예 : https://github.com/szilard/GBM-perf/issues/9

멀티 코어 확장 및 실제로 NUMA 문제가 실제로 크게 개선되었습니다.

멀티 코어 :

더 작은 데이터 (0.1M 행)에서 매우 주목할만한 개선 사항

자세한 내용은 여기 :

https://github.com/szilard/GBM-perf#multi-core-scaling-cpu
https://github.com/szilard/GBM-perf/issues/29#issuecomment-689713624

또한 NUMA 문제가 크게 완화되었습니다.

@szilard 벤치 마크 작업에 시간을

예,이 스레드의 모든 사람들이이 작업을 수행 한 것에 대해 훌륭합니다.

참고로, 다음은 xgboost의 다양한 버전에 대해 1, 16 (1so & no HT) 및 64 (모두) 코어에서 EC2 r4.16xlarge (각각 16c + 16HT가있는 2 소켓)의 1M 행에 대한 교육 시간입니다.

https://github.com/szilard/GBM-perf/issues/40

@szilard ,

추신 위에서 나는 XGB 1.2가 1.1 버전에 대해 약간의 회귀를 가지고 있음을 알 수 있습니다. 매우 흥미로운 정보입니다. 명확히하겠습니다. 나에게는 예상되지 않습니다.

@szilard ,이 주제가 흥미 롭다면이 블로그에서 CPU 최적화의 배경과 결과를 확인할 수 있습니다.
https://medium.com/intel-analytics-software/new-optimizations-for-cpu-in-xgboost-1-1-81144ea21115

최적화 작업과 블로그 게시물 링크에 대해 @SmirnovEgorRu 에게 감사드립니다 (이전에이 게시물을 보지 못했습니다).

내 번호를 더 쉽게 재현하고 향후 및 또는 다른 하드웨어에서 새 번호를 얻기 위해이를 위해 별도의 Dockerfile을 만들었습니다.

https://github.com/szilard/GBM-perf/tree/master/analysis/xgboost_cpu_by_version

첫 번째 소켓, 하이퍼 스레드 코어 (예 : 2 개의 소켓, 16c + 16HT가있는 r4.16xlarge의 경우 0-15) 및 xgboost 버전의 CPU 코어 ID를 설정해야합니다.

VER=v1.2.0
CORES_1SO_NOHT=0-15    ## set physical core ids on first socket, no hyperthreading
sudo docker build --build-arg CACHE_DATE=$(date +%Y-%m-%d) --build-arg VER=$VER -t gbmperf_xgboost_cpu_ver .
sudo docker run --rm -e CORES_1SO_NOHT=$CORES_1SO_NOHT gbmperf_xgboost_cpu_ver

스크립트를 여러 번 실행하는 것이 가치가있을 수 있습니다. 모든 코어의 교육 시간은 일반적으로 가상화 환경 (EC2) 때문인지 NUMA 때문인지 확실하지 않은 다소 높은 변동성을 보여줍니다.

벤치 마크에서 사용한 r4.16xlarge보다 더 높은 주파수와 더 많은 코어를 가진 c5.metal의 결과 :

https://github.com/szilard/GBM-perf/issues/41

TLDR : xgboost는 다른 lib에 비해 더 빠르고 더 많은 코어를 최대한 활용합니다. 👍

나는 이것에 대해 궁금합니다.

xgboost의 코어 1 개에서 24 개로의 속도 향상은 작은 데이터 (1M 행, 중간 열의 패널)보다 큰 데이터 (10M 행, 오른쪽 패널)에서 더 작습니다. 이것은 일종의 증가 된 캐시 적중 또는 다른 libs에는없는 것입니까?

AMD에 대한 몇 가지 결과는 다음과 같습니다.

https://github.com/szilard/GBM-perf/issues/42

xgboost 최적화가 AMD에서도 잘 작동하는 것 같습니다.