가능한 최대 정밀도로 코드 성능을 측정해야합니다. 현재정확하게 벤치마킹 코드
내가 사용하고 있습니다 :
- 스톱워치 타이밍을
측정하기 - 같은 CPU 코어 모든 시간을 사용하도록 설정 프로세스 선호도를
- 최대
로 설정 스레드 우선 순위가 - 측정하기 전에 워밍업 실행을 수행
- 테스트를 1000 번 실행하고 평균을 계산하십시오.
그러나 벤치 마크 실행 사이에는 여전히 차이가 있습니다 (최대 1 %). 이 측정을 더 정확하게 만드는 방법에 대한 아이디어가 있습니까?
측정을 시작하기 전에 워밍업 코드를 10 초 이상 실행하십시오. CPU가 최대 속도로 실행되는지 확인해야합니다.
평균이 아닌 런타임을 측정하십시오.
이 두 가지 개선 사항을 통해 매우 안정적인 측정 결과를 얻었습니다.
외부 구성 요소와 같이 성능이 다를 수있는 이유가 있습니까?
1 %의 변동은 특히 DB 또는 서비스에 대한 연결과 같은 외부의 것에 의존하는 경우 성능이 1000 회를 넘지 않습니다.
스톱워치는 시간을 측정하는 가장 정확한 방법은 그래서 이것은 분명 수
외부와의 종속 관계가 없습니다. 내 코드와 OS 만. – user626528
다른 프로세스가 실행 중입니까? CPU 코어의 선호도를 CPU0 이외의 것으로 설정할 수 있습니까? 1 % 차이라고 말하면, 오는 시간은 얼마입니까?이상치가 드물거나 타이밍 결과가 공정하게 퍼지면 (표준 편차) – finman
다른 프로세스가 있습니까? LOL, 올해의 질문. – user626528
에 대해 우려하지 않을 것이다, 그러나 당신의 CPU는 당신의 단일 프로세스 전용되지 않습니다. 그것은 또한 OS와 하드웨어에 대한 많은 다른 것들을 담당합니다.
또한 메모리 사용, HDD 사용 및 GC 동작은 실행 사이에 다를 수 있습니다. 아마도 계산에 가상 메모리가 필요하며 이는 RAM 액세스보다 훨씬 느립니다. 등등 ...
GC에 대해서는 "GCSettings.LatencyMode"의 설정을 변경하여 재생하려고 시도 할 수 있습니다 (예 : http://blogs.microsoft.co.il/blogs/sasha/archive/2008/08/10/low-latency-gc-in-net-3-5.aspx 참조).
동일한 컴퓨터에서 단일 세션에서 스톱워치는 매우 정확합니다. 실행 시간이 실행 사이에 다른 경우 측정의 정확성 부족으로 인한 것이 아니라 프로세스 자체가 항상 같은 시간이 걸리기 때문입니다. .. 테스트의 각 "반복"은 최소한 수백 밀리 초가 걸릴 것입니다. 스톱워치는 결코 나노초 단위로 지속 시간을 측정 할 수 없습니다 ...
1 %의 변형은 전혀 놀라운 것이 아닙니다.
이것은 놀랄 것 같지만 동시에 200 개의 다른 프로세스를 실행하지 않는 자신의 OS를 작성 하시겠습니까? 진지하게 다른 실행중인 프로세스는 귀하의 벤치 마크 결과에 영향을 미칩니다. 1000 %의 런 타임에서만 실제로 1 %의 차이가 있습니까? =) –
사실, 비 실시간 OS에서 약 1 %의 차이는 걱정하지 마십시오! –