Thanks Dan! I'm not using Opal now, as I got
confused at the way IPC is calculated. I'm pasting a question I asked before on
the list. Unfortunately it was not answered at that time.
I simulated a four core CMP system with both Opal
and Ruby. I found in results.opal the runtime stats for processor
[0],[1],[2],[3]. But as can be seen from below, how come only processor
[0] executed 100 million instructions specified by "opal0.sim-step 100000000",
but processor [1] and [2] have more total number of instructions than what
I've specified ?
Is there a way in Opal to let the simulator run for
a certain number of cycles, instead of instructions (like "cc N" and "c N"
in simics)?
[0] *** Runtime statistics:
[0] number of continue
calls
100000003
[0] Instruction per
cycle:
1.55227
[0] Total Elapsed
Time:
36060 sec 0 usec
[0] Total Retirement
Time:
1522 sec 670804 usec
[0] Approximate cycle per
sec:
1786.52
[0] Approximate instructions per
sec:
2773.15
[0] This processor's Simics overhead
(retire/elapsed): 4.22%
[0] Average number of
instructions per continue
1.00
[1] *** Runtime statistics:
[1]
Total number of
instructions
255117523
[1] Total number of
cycles
64421882
[1] number of continue
calls
255117523
[1] Instruction per
cycle:
3.96011
[1] Total Elapsed
Time:
36060 sec 0 usec
[1] Total Retirement
Time:
3740 sec 262608 usec
[1] Approximate cycle per
sec:
1786.52
[1] Approximate instructions per
sec:
7074.79
[1] This processor's Simics overhead
(retire/elapsed): 10.37%
[1] Average number of instructions
per continue
1.00
[2] *** Runtime statistics:
[2]
Total number of
instructions
256142056
[2] Total number of
cycles
64421882
[2] number of continue
calls
256142056
[2] Instruction per
cycle:
3.97601
[2] Total Elapsed
Time:
36060 sec 0 usec
[2] Total Retirement
Time:
3713 sec 458821 usec
[2] Approximate cycle per
sec:
1786.52
[2] Approximate instructions per
sec:
7103.2
[2] This processor's Simics overhead
(retire/elapsed): 10.30%
[2] Average number of instructions
per continue
1.00
[3] *** Runtime statistics:
[3]
Total number of
instructions
40012500
[3] Total number of
cycles
64421882
[3] number of continue
calls
40012500
[3] Instruction per
cycle:
0.621101
[3] Total Elapsed
Time:
36060 sec 0 usec
[3] Total Retirement
Time:
600 sec 825168 usec
[3] Approximate cycle per
sec:
1786.52
[3] Approximate instructions per
sec:
1109.61
[3] This processor's Simics overhead
(retire/elapsed): 1.67%
[3] Average number of
instructions per continue
1.0
----- Original Message -----
Sent: Wednesday, March 28, 2007 8:42
AM
Subject: Re: [Gems-users] IPC and Ruby
cycles
If you're using Opal, then Opal will calculate its IPC for
you.
If you're not using Opal, then the IPC is a meaningless measure, since
Simics is an extremely idealized in-order processor model.
If IPC is a
metric that you absolutely MUST know, change SIMICS_RUBY_MULTIPLIER to 1 and
double all your ruby latencies (to achieve an approximately identical timing).
Then use RUBY_CYCLES to calculate IPC.
Regards,
Dan
Lei Yang
wrote:
Dear list,
I noticed that with SIMICS_RUBY_MULTIPLIER set
to 2, the Ruby_cycles shown in Ruby stats is always half of the cycle count
shown by simics. When calculating the IPC, which cycle count should I use,
Ruby_cycles or the cycle count of Simics? I'm quite curious why there is a
SIMICS_RUBY_MULTIPLIER parameter and what's its purpose. As always,
thanks a lot for your comments!
Lei
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}