프로그램에서 알고리즘이 얼마나 빨리 실행되는지를 결정할 때 QueryPerformanceFrequency()와 함께 QueryPerformanceCounter()를 항상 사용했지만 핵심 i5를 사용하면 어떻게됩니까?/7 아키텍처?핵심 i5/7 아키텍처의 프로그램 런타임 결정
터보 부스트가 갑자기 내 알고리즘을 반쯤 쯤 돌릴 가능성이 있으며 갑자기 내 성능 타이머가 더 이상 정확하지 않습니다. 내 클럭 주파수가 더 이상 상수가 아니거나이 문제가 아니기 때문입니까? 이것이 문제라면 알고리즘을 정확하게 시간을 재는 더 좋은 방법은 무엇입니까?
간단히 말하면, 어떤 일이 일어날 수 있습니다. 현대 CPU는 단순한 평범함으로 현실 세계의 성능을 예측하기가 어렵습니다. 이것은 최신 Intel x86-64 cpus에만 국한되지 않고 8 비트 PIC 마이크로 컨트롤러와 모든 기능을 동일하게 적용합니다.
단지 합리적인 일은 더 많은 것을 테스트하는 것입니다. 실제 작업 부하에 대한 실제 하드웨어의 실제 런타임 성능에 대한 정확한 아이디어를 얻으려면 여러 번 반복 된 테스트를 수행해야합니다.
반면에 하나의 알고리즘이 동일한 하드웨어 ("내 컴퓨터"에있는)에서 다른 알고리즘보다 뛰어난 성능을 보일 경우 일정한 요인에 따라 달라질 수 있지만 일반적으로 다른 설정에서 유사한 비교 결과를 제공합니다.
정말 제가 알고리즘 프로세스가 주파수로 나뉘어서 나노 초 단위로 시간을 얻는 데 걸리는 평균 CPU 사이클 수를 조사해야합니까? – Faken
Boost.Date_Time : long total_nanoseconds() 남은 자릿수를 자르는 총 나노초 수를 가져옵니다. – Hank
Faken : 측정중인 코어 단위에 대해서만 생각하면됩니다. 타이밍 함수가 나노초를 반환하면 고려해야 할 사항입니다. 그들이 단순히 유익하지 않기 때문에 여분의 선회를 거치지 않아도됩니다. – SingleNegationElimination
여기 QueryPerformanceCounter에의 주제에 흥미로운 기사입니다 :
http://www.virtualdub.org/blog/pivot/entry.php?id=106
을 분명히, VirtualDub의 친구는 사용을 중단하고, 지금 timeGetTime을 선호한다. 좋은 읽을 거리.
나는 Boost.Date_Time, 특히 부스트 :: posix_time 물건을 사용하는 것이 좋습니다.
여기서 실제로 두 개의 문제가있다 : 임의의 소정의 타이밍에있어서의
신뢰성이 때 (예를 들면 터보 부스트 통해 증가 또는 때문에 예 절전 또는 발로 열관리 저하 중) CPU 클록 주파수 변화 - 이것은 다른 답변에서 다루어집니다.
신뢰할 수있는 시계가있는 벤치 마크 측정의 신뢰성 (이것은 더 문제가 있습니다) - 최적화 작업과 작은 개선을 찾고 있다면 약 10 %이면, Turbo Boost의 시계 변이 효과에 의해 오해를 받기 쉽습니다. 가능한 해결책은 다음과 같습니다 :
2.1. Turbo Boost 및 기타 클록 주파수 스케일링 비활성화
2.2.
QPC의 타이밍 소스는 전통적으로 클럭 주파수에서 파생되지 않았습니다. 마더 보드 제조업체들은 1 페니 또는 2 페니를 면도하려고 노력하면서 코너를 자르고 있습니다. 그들은 일반적으로 어딘가에서 칩셋 내부의 주파수를 선택합니다. QPF 값이 2GHz 인 누군가의 AMD 머신에 대해 들었습니다. 위험에 처해진 후 CPU 클럭에 대한 값에 가깝습니다. 그런 큰 가치를 얻는 경우에만 신경이 쓰일 수 있습니다.
QPC의 절대 값은 이 아니어야합니다.을 신경 써야합니다. 코어의 품질에 크게 의존 할 것입니다. QPC 측정 만 사용하여 코드의 점진적 개선을 찾습니다.
예 터보 부스트가 시작될 수 있습니다. 좋은 관찰 :) – basarat