u64 루프 카운터와 x86 CPU의 _mm_popcnt_u64 간의 특이한 성능 차이 탐색
소개
대규모 데이터 배열에 대한 작업을 빠르게 수행할 수 있는 방법을 찾고 있습니다. popcount 메서드를 사용할 때 매우 이상한 동작이 발생했습니다. 루프 변수를 unsigned에서 uint64_t로 변경하면 PC 성능이 50% 저하되었습니다.
벤치마크
#include <iostream>
#include <chrono>
#include <x86intrin.h>
int main(int argc, char* argv[]) {
using namespace std;
if (argc != 2) {
cerr << "usage: array_size in MB" << endl;
return -1;
}
uint64_t size = atol(argv[1])<<20;
uint64_t* buffer = new uint64_t[size/8];
char* charbuffer = reinterpret_cast<char*>(buffer);
for (unsigned i=0; i<size; ++i)
charbuffer[i] = rand()%256;
uint64_t count,duration;
chrono::time_point<chrono::system_clock> startP,endP;
{
startP = chrono::system_clock::now();
count = 0;
for( unsigned k = 0; k < 10000; k++){
// Tight unrolled loop with unsigned
for (unsigned i=0; i<size/8; i+=4) {
count += _mm_popcnt_u64(buffer[i]);
count += _mm_popcnt_u64(buffer[i+1]);
count += _mm_popcnt_u64(buffer[i+2]);
count += _mm_popcnt_u64(buffer[i+3]);
}
}
endP = chrono::system_clock::now();
duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "unsigned\t" << count << '\t' << (duration/1.0E9) << " sec \t"
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
{
startP = chrono::system_clock::now();
count=0;
for( unsigned k = 0; k < 10000; k++){
// Tight unrolled loop with uint64_t
for (uint64_t i=0;i<size/8;i+=4) {
count += _mm_popcnt_u64(buffer[i]);
count += _mm_popcnt_u64(buffer[i+1]);
count += _mm_popcnt_u64(buffer[i+2]);
count += _mm_popcnt_u64(buffer[i+3]);
}
}
endP = chrono::system_clock::now();
duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "uint64_t\t" << count << '\t' << (duration/1.0E9) << " sec \t"
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
free(charbuffer);
}보시다시피 xMB 크기의 무작위 데이터 버퍼를 생성했습니다. 여기서 x는 명령줄에서 읽혀집니다. 그런 다음 버퍼를 반복하고 x86 popcount 내장 함수의 펼쳐진 버전을 사용하여 popcount를 수행합니다. 보다 정확한 결과를 얻기 위해 popcount를 10,000번 수행합니다. 팝카운트를 측정하는 시간입니다. 첫 번째 경우 내부 루프 변수는 부호가 없으며 두 번째 경우 내부 루프 변수는 uint64_t입니다. 나는 이것이 아무런 차이가 없어야 한다고 생각했지만 그렇지 않습니다.
(완전 미친) 결과
이렇게 컴파일했습니다(g 버전: Ubuntu 4.8.2-19ubuntu1):
g++ -O3 -march=native -std=c++11 test.cpp -o test
이것 Haswell Core i7-4770K CPU @ 3.50GHz에서 테스트를 실행했습니다. 1에 대한 결과(임의의 데이터 1MB):
보시다시피 uint64_t 버전은 서명되지 않은 버전에 비해 처리량이 절반입니다! 문제는 서로 다른 어셈블리가 생성되는 것 같은데, 그 이유는 무엇일까요? 먼저 컴파일러 버그인 줄 알고 clang(Ubuntu Clang 버전 3.4-1ubuntu3)을 시도해 보았습니다. GB/sec
clang++ -O3 -march=native -std=c++11 teest.cpp -o test
로 변경했습니다. 따라서 컴파일러는 이제 컴파일 타임에 버퍼 크기를 알게 됩니다. 어쩌면 일부 최적화를 추가할 수도 있습니다! g 단위의 숫자는 다음과 같습니다.
uint64_t size = atol(argv[1]) << 20;
unsigned 41959360000 0.509156초 20.5944GB/sec
uint64_t size = 1 << 20;
결과:
잠깐, 무슨 일이 일어난 걸까요? 이제 두 버전 모두 15GB/s의 낮은 속도로 낮아졌습니다. 따라서 색다른 상수 값을 상수 값으로 바꾸면 Clang의 두 가지 버전 코드가 느려지는 결과가 발생하기도 했습니다!
Ivy Bridge CPU를 사용하는 동료에게 벤치마크를 컴파일해 달라고 요청했습니다. 그는 비슷한 결과를 얻었으므로 이것은 Haswell에만 국한된 것 같지 않습니다. 여기서 두 개의 컴파일러가 이상한 결과를 생성하므로 이 역시 컴파일러 버그는 아닌 것 같습니다. 여기에는 AMD CPU가 없으므로 테스트에는 Intel만 사용할 수 있습니다.
더 광란을 불러주세요!
첫 번째 예(atol(argv[1])가 있는 예)를 사용하여 변수 앞에 정적 변수를 넣습니다. 예:
#include <iostream>
#include <chrono>
#include <x86intrin.h>
int main(int argc, char* argv[]) {
using namespace std;
if (argc != 2) {
cerr << "usage: array_size in MB" << endl;
return -1;
}
uint64_t size = atol(argv[1])<<20;
uint64_t* buffer = new uint64_t[size/8];
char* charbuffer = reinterpret_cast<char*>(buffer);
for (unsigned i=0; i<size; ++i)
charbuffer[i] = rand()%256;
uint64_t count,duration;
chrono::time_point<chrono::system_clock> startP,endP;
{
startP = chrono::system_clock::now();
count = 0;
for( unsigned k = 0; k < 10000; k++){
// Tight unrolled loop with unsigned
for (unsigned i=0; i<size/8; i+=4) {
count += _mm_popcnt_u64(buffer[i]);
count += _mm_popcnt_u64(buffer[i+1]);
count += _mm_popcnt_u64(buffer[i+2]);
count += _mm_popcnt_u64(buffer[i+3]);
}
}
endP = chrono::system_clock::now();
duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "unsigned\t" << count << '\t' << (duration/1.0E9) << " sec \t"
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
{
startP = chrono::system_clock::now();
count=0;
for( unsigned k = 0; k < 10000; k++){
// Tight unrolled loop with uint64_t
for (uint64_t i=0;i<size/8;i+=4) {
count += _mm_popcnt_u64(buffer[i]);
count += _mm_popcnt_u64(buffer[i+1]);
count += _mm_popcnt_u64(buffer[i+2]);
count += _mm_popcnt_u64(buffer[i+3]);
}
}
endP = chrono::system_clock::now();
duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "uint64_t\t" << count << '\t' << (duration/1.0E9) << " sec \t"
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
free(charbuffer);
}여기에 그녀가 결과는 g:
아, 또 다른 대안이 있습니다! u3에는 여전히 32GB/s가 있지만 최소한 13GB/s 버전에서 20GB/s 버전으로 u64를 얻을 수 있었습니다! 내 동료의 컴퓨터에서는 u64 버전이 u32 버전보다 훨씬 빨라서 최상의 결과를 얻었습니다. 불행히도 이것은 g 에서만 작동하며 clang은 정적에 신경 쓰지 않는 것 같습니다.
**내 질문
위 내용은 루프 카운터를 `unsigned`에서 `uint64_t`로 변경하면 x86 CPU에서 `_mm_popcnt_u64`의 성능에 큰 영향을 미치는 이유는 무엇이며 컴파일러 최적화 및 변수 선언은 어떻게 영향을 줍니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
