


루프 카운터를 `unsigned`에서 `uint64_t`로 변경하면 x86 CPU에서 `_mm_popcnt_u64`의 성능에 큰 영향을 미치는 이유는 무엇이며 컴파일러 최적화 및 변수 선언은 어떻게 영향을 줍니까?
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):
- unsigned 41959360000 0.401554초 26.113GB/초
- uint64_t 41959360000 0.759822초 13.8003 GB/sec
보시다시피 uint64_t 버전은 서명되지 않은 버전에 비해 처리량이 절반입니다! 문제는 서로 다른 어셈블리가 생성되는 것 같은데, 그 이유는 무엇일까요? 먼저 컴파일러 버그인 줄 알고 clang(Ubuntu Clang 버전 3.4-1ubuntu3)을 시도해 보았습니다. GB/sec
clang++ -O3 -march=native -std=c++11 teest.cpp -o test
- 그래서 거의 같은 결과를 얻으면서도 여전히 이상합니다. 그런데 이제 정말 이상해졌습니다. 입력에서 읽은 버퍼 크기를 상수 1로 대체하여
- 에서
로 변경했습니다. 따라서 컴파일러는 이제 컴파일 타임에 버퍼 크기를 알게 됩니다. 어쩌면 일부 최적화를 추가할 수도 있습니다! g 단위의 숫자는 다음과 같습니다.
uint64_t size = atol(argv[1]) << 20;
unsigned 41959360000 0.509156초 20.5944GB/sec
uint64_t size = 1 << 20;
- 이제 두 버전 모두 속도가 동일합니다. 하지만 벨로시데이드는 unsigned에 비해 훨씬 느려집니다! 26GB/초에서 20GB/초로 떨어졌기 때문에 일반적이지 않은 상수를 상수 값으로 바꾸면
- 최적화 해제 가 발생했습니다. 진지하게, 나는 여기에 단서가 없습니다! 하지만 이제 clang과 새 버전에서는
결과:
- 부호 없음 41959360000 0.677009초 15.4884GB/s
- uint64_t 41959360000 0.676909초 15.4906 GB/s
잠깐, 무슨 일이 일어난 걸까요? 이제 두 버전 모두 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:
- unsigned 41959360000 0.396728초 26.4306GB/초
- uint64_t 41959360000 0.509484초 20.5811GB/초
아, 또 다른 대안이 있습니다! u3에는 여전히 32GB/s가 있지만 최소한 13GB/s 버전에서 20GB/s 버전으로 u64를 얻을 수 있었습니다! 내 동료의 컴퓨터에서는 u64 버전이 u32 버전보다 훨씬 빨라서 최상의 결과를 얻었습니다. 불행히도 이것은 g 에서만 작동하며 clang은 정적에 신경 쓰지 않는 것 같습니다.
**내 질문
위 내용은 루프 카운터를 `unsigned`에서 `uint64_t`로 변경하면 x86 CPU에서 `_mm_popcnt_u64`의 성능에 큰 영향을 미치는 이유는 무엇이며 컴파일러 최적화 및 변수 선언은 어떻게 영향을 줍니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

C#과 C의 역사와 진화는 독특하며 미래의 전망도 다릅니다. 1.C는 1983 년 Bjarnestroustrup에 의해 발명되어 객체 지향 프로그래밍을 C 언어에 소개했습니다. Evolution 프로세스에는 자동 키워드 소개 및 Lambda Expressions 소개 C 11, C 20 도입 개념 및 코 루틴과 같은 여러 표준화가 포함되며 향후 성능 및 시스템 수준 프로그래밍에 중점을 둘 것입니다. 2.C#은 2000 년 Microsoft에 의해 출시되었으며 C와 Java의 장점을 결합하여 진화는 단순성과 생산성에 중점을 둡니다. 예를 들어, C#2.0은 제네릭과 C#5.0 도입 된 비동기 프로그래밍을 소개했으며, 이는 향후 개발자의 생산성 및 클라우드 컴퓨팅에 중점을 둘 것입니다.

C# 및 C 및 개발자 경험의 학습 곡선에는 상당한 차이가 있습니다. 1) C#의 학습 곡선은 비교적 평평하며 빠른 개발 및 기업 수준의 응용 프로그램에 적합합니다. 2) C의 학습 곡선은 가파르고 고성능 및 저수준 제어 시나리오에 적합합니다.

C 학습자와 개발자는 StackoverFlow, Reddit의 R/CPP 커뮤니티, Coursera 및 EDX 코스, GitHub의 오픈 소스 프로젝트, 전문 컨설팅 서비스 및 CPPCon에서 리소스와 지원을받을 수 있습니다. 1. StackoverFlow는 기술적 인 질문에 대한 답변을 제공합니다. 2. Reddit의 R/CPP 커뮤니티는 최신 뉴스를 공유합니다. 3. Coursera와 Edx는 공식적인 C 과정을 제공합니다. 4. LLVM 및 부스트 기술 향상과 같은 GitHub의 오픈 소스 프로젝트; 5. JetBrains 및 Perforce와 같은 전문 컨설팅 서비스는 기술 지원을 제공합니다. 6. CPPCON 및 기타 회의는 경력을 돕습니다

C는 XML과 타사 라이브러리 (예 : TinyXML, Pugixml, Xerces-C)와 상호 작용합니다. 1) 라이브러리를 사용하여 XML 파일을 구문 분석하고 C- 처리 가능한 데이터 구조로 변환하십시오. 2) XML을 생성 할 때 C 데이터 구조를 XML 형식으로 변환하십시오. 3) 실제 애플리케이션에서 XML은 종종 구성 파일 및 데이터 교환에 사용되어 개발 효율성을 향상시킵니다.

C는 여전히 현대 프로그래밍과 관련이 있습니다. 1) 고성능 및 직접 하드웨어 작동 기능은 게임 개발, 임베디드 시스템 및 고성능 컴퓨팅 분야에서 첫 번째 선택이됩니다. 2) 스마트 포인터 및 템플릿 프로그래밍과 같은 풍부한 프로그래밍 패러다임 및 현대적인 기능은 유연성과 효율성을 향상시킵니다. 학습 곡선은 가파르지만 강력한 기능은 오늘날의 프로그래밍 생태계에서 여전히 중요합니다.

C의 미래는 병렬 컴퓨팅, 보안, 모듈화 및 AI/기계 학습에 중점을 둘 것입니다. 1) 병렬 컴퓨팅은 코 루틴과 같은 기능을 통해 향상 될 것입니다. 2)보다 엄격한 유형 검사 및 메모리 관리 메커니즘을 통해 보안이 향상 될 것입니다. 3) 변조는 코드 구성 및 편집을 단순화합니다. 4) AI 및 머신 러닝은 C가 수치 컴퓨팅 및 GPU 프로그래밍 지원과 같은 새로운 요구에 적응하도록 촉구합니다.

c is nontdying; it'sevolving.1) c COMINGDUETOITSTIONTIVENICICICICINICE INPERFORMICALEPPLICATION.2) thelugageIscontinuousUllyUpdated, witcentfeatureslikemodulesandCoroutinestoimproveusActionalance.3) despitechallen

C에서 정적 분석의 적용에는 주로 메모리 관리 문제 발견, 코드 로직 오류 확인 및 코드 보안 개선이 포함됩니다. 1) 정적 분석은 메모리 누출, 이중 릴리스 및 초기화되지 않은 포인터와 같은 문제를 식별 할 수 있습니다. 2) 사용하지 않은 변수, 데드 코드 및 논리적 모순을 감지 할 수 있습니다. 3) Coverity와 같은 정적 분석 도구는 버퍼 오버플로, 정수 오버플로 및 안전하지 않은 API 호출을 감지하여 코드 보안을 개선 할 수 있습니다.
