Thanks a lot Steve!
I am running single threaded SPECCPU2006 in SE mode. There are two types of
differences that I cannot explain:
1. the Dcache misses: It is odd that the number of misses with # of MSHRs=1
differs greatly from that with # of MSHRs=2, 3, and 64
dcache.demand_misses #MSHR=1 2 3 64
perlbench
bzip2 19689745 26038677 26516618 26735342 gcc 45823664 135639303 139563223
140089710 mcf 443916465 750312689 775689337 778847055 gobmk 13434336
61116394 76427232 76904280 hmmer 5530238 11112974 11596759 11635027
2. When the # of MSHRs increases, some of the benchmarks show much more idle
cycles. I can expected that the number of CPU idle cycle can go up to some
extend when # of MSHRs increase due to the dynamic of OOO. But increasing
the # of MSHRs leads to a significant increase on CPU idle cycles sounds a
little bit odd, since it implies that the non-blocking cache will not do
anything good to increase ILP. (For the stats as below, the CPU idle cycles
increase by up to 3 time when increasing # of MSHRs from 1 to 64)
system.cpu.idleCycles #MSHR=1 2
3 64
perlbench
bzip2 67208884 159744704 166071685 160962558 gcc 287686271 401952006
397529359 396262747 mcf 1769063728 4012335393 4760390720 5164620424
Thanks!
-Sheng
On Mon, Feb 14, 2011 at 8:23 AM, Steve Reinhardt <[email protected]> wrote:
> If you're running a single-threaded program in SE mode there should not be
> significant differences. There may be very minor differences due to TLB
> misses (since these are handled in software on Alpha). How big are the
> changes you are seeing? You can run tests/diff-out on the two stats files
> with different MSHR counts to show the differences.
>
> Thanks,
>
> Steve
>
>
> On Mon, Feb 14, 2011 at 12:21 AM, Sheng Li <[email protected]> wrote:
>
>> Thanks Steve,
>>
>> While doing the detailed analysis, I found many other stats change when
>> the number of MSHR changes. These include number of L1D
>> accesses/misses/hits. I do not think they should change. Did I miss
>> something?
>>
>> thanks
>> -Sheng
>>
>> On Thu, Feb 10, 2011 at 12:06 AM, Steve Reinhardt <[email protected]>wrote:
>>
>>> Yes, if the behavior of your simulated program changes just from changing
>>> the number of MSHRs then that is almost certainly an m5 bug. Are you using
>>> the most recent code from the m5 (not m5-stable) repo?
>>>
>>> You are right that those trapping mode warnings are nothing to worry
>>> about.
>>>
>>> Steve
>>>
>>>
>>> On Wed, Feb 9, 2011 at 7:53 PM, Ali Saidi <[email protected]> wrote:
>>>
>>>> There could be a bug. You should compare an execution trace with mshr=1
>>>> to the other ones and see where it diverges. You could also compare it to
>>>> an
>>>> atomic cpu. See the tracediff script in the util directory.
>>>>
>>>> Ali
>>>>
>>>>
>>>>
>>>> On Feb 9, 2011, at 11:02 AM, Sheng Li wrote:
>>>>
>>>> Hi,
>>>>
>>>> Sorry I sent out my last email too early...
>>>>
>>>> I am comparing: sim_insts # Number of instructions simulated. I
>>>> understand that if the instruction counts are off by a few, but in my case
>>>> it differs greatly as below:
>>>>
>>>>
>>>> ./MSHR=1/gamess/gamess_stats.
>>>> out:sim_insts
>>>> 2252121281 # Number of instructions simulated
>>>> ./MSHR=2/gamess/gamess_stats.out:sim_insts
>>>> 76662635 # Number of instructions simulated
>>>> ./MSHR=3/gamess/gamess_stats.out:sim_insts
>>>> 76662625 # Number of instructions simulated
>>>> ./MSHR=64/gamess/gamess_stats.out:sim_insts
>>>> 99903638 # Number of instructions simulated
>>>>
>>>> A closer look reveals that only when MSHR=1 the benchmark finishes
>>>> properly. For MSHR = 2, 3, and 64, there is an error " STOP IN ABRT" that
>>>> makes simulations exit early. I am wondering how could change number of
>>>> MSHR results in this error?
>>>>
>>>> I also saw a bunch of warnings as following. But I think the warnings
>>>> are OK since the one finished successfully also has these warinings
>>>>
>>>> warn: addt/sud f13,f12,f14: non-standard trapping mode not supported
>>>> For more information see: http://www.m5sim.org/warn/f7ecd6d6
>>>> warn: addt/sud f16,f16,f0: non-standard trapping mode not supported
>>>> For more information see: http://www.m5sim.org/warn/f7ecd6d6
>>>>
>>>> Thanks!
>>>> -Sheng
>>>>
>>>>
>>>> On Tue, Feb 8, 2011 at 5:22 PM, Ali Saidi <[email protected]> wrote:
>>>>
>>>>> And what are the exact stats names that you're comparing? With an o3
>>>>> cpu some stats that count instructions don't care if the instruction was
>>>>> useful (not squashed). What architecture as well? I'm not sure how good
>>>>> of a
>>>>> job we do identifying nops and such and not counting them in commit when
>>>>> they're sent down the pipe along with a fault or similar.
>>>>>
>>>>>
>>>>> Ali
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 8 Feb 2011 16:59:41 -0500, Korey Sewell <[email protected]>
>>>>> wrote:
>>>>>
>>>>> Which CPU model(s) are you using? what mode (FS or SE)?
>>>>>
>>>>> On Tue, Feb 8, 2011 at 4:25 PM, Sheng Li <[email protected]> wrote:
>>>>>
>>>>>> Hi Guys,
>>>>>>
>>>>>> I am simulating SPECCPU2006 and changing MSHR setup for each
>>>>>> simulation. I was surprised to see that for the same benchmark, if I just
>>>>>> change the number of MSHRs I will get different simulated instructions,
>>>>>> cache accesses, etc. I can expect that the timing (cycles) and some
>>>>>> other
>>>>>> stats may change. But how come the instruction count, cache accesses, etc
>>>>>> changed too? The benchmarks finished properly with valid output. Did I
>>>>>> missed something?
>>>>>>
>>>>>> Thanks
>>>>>> -Sheng
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> m5-users mailing list
>>>>>> [email protected]
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> - Korey
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> m5-users mailing list
>>>>> [email protected]
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> m5-users mailing list
>>>> [email protected]
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>>>
>>>
>>>
>>
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
