Hi Zeb, If you want to compare the number of instructions committed in O3 vs atomic, compare the following 2 stats: O3: cpu.commit.commitCommittedInsts Atomic: cpu.num_insts (which goes into sim_insts) These two should generally be equal.
The cpu.committedInsts (which goes into sim_insts) in O3 gives you the number of committed instructions excluding NOPs and prefetch instructions. I think that explains the difference. -Ashish On Wed, Mar 13, 2013 at 8:30 AM, Zebulun Barnett <[email protected]> wrote: > tl;dr Detailed cpu borked? --prog-interval borked? definitely :( > > Greetings, > > My research group has recently started using Gem5 (coming from m5) and we > have noticed an anomaly with the Alpha SE Detailed(O3) CPU model. Of the 4 > types of CPU available (Atomic, Detailed(O3), Timing, InOrder) all but the > Detailed model take the exact same number of instructions to complete a > benchmark. The Detailed CPU consistently requires less instructions (about > %10 less) to complete a given benchmark. Multiple benchmarks have indicated > the same result. We are aware that the main difference between the Detailed > CPU and the others is that it is an out-of-order processor. Is it possible > this is the cause of the difference? Is it simply handling the instructions > more efficiently? > > During our testing, we attempted to use fast forwarding to convince > ourselves that the different CPU types actually did commit a different > number of instructions. In, libquantum, one of the benchmarks in which we > noticed this behavior, the atomic cpu commits ~289 million instructions > while the detailed cpu commits ~269 million instructions. With fast > forwarding (using the atomic cpu and switching to the detailed model at 200 > million instructions) the total number of instructions committed is ~282. > This number convinces us that the detailed model indeed commits a different > amount of instructions than the other types. > > Also, during the fast forward test, we set --prog-interval to 1,000,000 > instructions. The interval behaved normally up to the switch, but once the > detailed CPU took over, it started reporting the same value every time. Each > printout after the switch was stuck at 2,000,001 instructions and the > committed instruction value was 0. However, the simulation completed as if > it committed all instructions successfully. We will submit a bug report for > this specific issue, but if anyone else has experienced this, please let us > know. > > If these are well-known or obvious issues, I apologize in advance for > wasting your time. Let it be known that I did search the archives to no > avail. > > Any insight would be most appreciated. > > Thank you, > Zeb Barnett > > ----- > Student Research Assistant > High Performance Computer Lab > Lamar University > > > > > > CONFIDENTIALITY: Any information contained in this e-mail (including > attachments) is the property of The State of Texas and unauthorized > disclosure or use is prohibited. Sending, receiving or forwarding of > confidential, proprietary and privileged information is prohibited under > Lamar Policy. If you received this e-mail in error, please notify the sender > and delete this e-mail from your system. > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
