variations in values colletced in different runs

variations in values colletced in different runs

Hi All,
I used Vtune to count the #clocktics and instructions on gzip(obtained from spec cpu2000 benchmark). The Input file is the same and I get vastly different numbers.
Run 1: --------------------------- Run2:
Clocktics: 13,924,603,990 ----- 12,950,202,200
Branch Retd:878,840,820 ----- 811,071,221
Instr. Retd:6,817,168,212 ----- 97,848,146
CPI: 2.043 ----- 132.350.
The test environment was the same.
Are these results Valid and why is there such an huge disparity between the reults collected in the first run aand Second run.
Any help will be sincerely Appreciated,
Ajay Krishnamurthy.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The 10% difference you see in clockticks and branches retired could be due to some kind of buffering of the disk files involved, but the reduced instructions retired are quite puzzling. Was the CPI value you show calculated by VTune or did you calculate it yourself? Usually when we a CPI that high its because there weren't enough samples to provide statistically meaningful data, but you have enough samples.

Dear Gary,
Thanks a lot for your reply.
CPI value was the value obtained from Vtune.
Today I compiled the same program with the default compiler optimazations on two different pentium 4 systems with identical configurations.Even then there is a vast disaprity between the results obtained.

In the reply you attribute the difference in clocktics is due to some kind of buffering.(I believe that should be the reason). is there any way to free the buffer after every run so that the results obtained are comaprable.

Did you ever run an application twice and compare the results obtained on the application using Vtune and were the results comaprable .

Thanks A lot for your time,
Ajay Krishnamurthy.

Yes, we regularly test rerunning an application to see how things change and we see the same phenomenon you did, that clockticks are usually less which we attribute to various kinds of buffering. But we also see the CPI remain reasonably constant.

I don't know of a way to shut off the O.S.'s buffereing, but I'm not really an O.S. expert.

May I ask you how did you tell the reason of 10% difference in clocktick and branches retired was the buffering of the disk files? Was it from the process view?



How big is the file you are using as an input to gzip also do you have calibration on or off?

Leave a Comment

Please sign in to add a comment. Not a member? Join today