I'm not entirely sure how interrupts are handled between QEMU and MARSS,
but I wonder if this could be an artifact of a faster emulation speed
causing interrupts to essentially move up in time. So if the hardware
interrupts are moving out of the way faster on a faster host, the
simulation is able to proceed quicker?

I could be completely off base here.

On Wed, May 16, 2012 at 4:32 AM, Stefan Neumann <
[email protected]> wrote:

> Hi,
>
> I did a rerun of the benchmark with the latest MARSSx86 version
> (code-cleanup branch) and the results are the same as for my previous run.
> Still there are significant variations when running the benchmark on
> machines with a different host frequency.
>
> Any guesses how to resolve this?
>
> Regards,
> Stefan
>
> 2012/5/12 YaoQing,Wang <[email protected]>
>
> Hi Avadh
>>
>> Thanks for providing marssx86 simulator
>>
>> I have some question about this topic.
>> The source code I checked out is from the "feature" branch with commit id
>> a3aa5ad2db (committed on Feb 28,2012)
>>
>> Is this version free from this sim_cycle variation problem ?
>>
>> Thanks and Regards.
>>
>> Yao-Qing
>>
>>
>> On Sat, May 12, 2012 at 12:07 AM, avadh patel <[email protected]>wrote:
>>
>>>
>>>
>>> On Fri, May 11, 2012 at 3:46 AM, Stefan Neumann <
>>> [email protected]> wrote:
>>>
>>>> Sorry, the formatting got a little messed up.
>>>>
>>>>       Host1:
>>>>
>>>>
>>>>
>>>>
>>>> Host2:
>>>>
>>>>
>>>>
>>>>  user uops
>>>> kernel uops
>>>> sim_cycle
>>>> user uops
>>>> kernel uops
>>>> sim_cycle  7210746924
>>>> 1331578150
>>>> 13797811843
>>>> 7210744488
>>>> 1331141836
>>>> 13315031456  7210745232
>>>> 1331564187
>>>> 13767346806
>>>> 7210744417
>>>> 1331064636
>>>> 13343311719  7210744826
>>>> 1331475921
>>>> 13803067702
>>>> 7210745025
>>>> 1331429686
>>>> 13362192919  7210744068
>>>> 1331046761
>>>> 13778895729
>>>> 7210745138
>>>> 1331530721
>>>> 13371649704  7210743664
>>>> 1331602038
>>>> 13741170045
>>>> 7210746956
>>>> 1332519415
>>>> 13340211019  7210745221
>>>> 1331551159
>>>> 13765271526
>>>> 7210744700
>>>> 1332103942
>>>> 13357991805  7210747188
>>>> 1331712213
>>>> 13739122442
>>>> 7210744523
>>>> 1331264662
>>>> 13289832849  7210745019
>>>> 1331550151
>>>> 13758991929
>>>> 7210744052
>>>> 1331141885
>>>> 13791512144
>>>>
>>>>
>>>> This seems like an issue with VM's clock that was fixed in 0.3 release.
>>> Which version are you using? Can you give the 'HEAD' commit id?
>>>
>>> - Avadh
>>>
>>>
>>>> 2012/5/11 Stefan Neumann <[email protected]>
>>>>
>>>>> Hi,
>>>>>
>>>>> I am running some simulations of SPEC2006 benchmarks an noticed some
>>>>> variations of the sim_cycle count when I run MARSS on different host
>>>>> machines.
>>>>>
>>>>> Just an example: ROI of GemsFDTD
>>>>>
>>>>> I ran the simulation a couple of times on each host.
>>>>>
>>>>> Host1: Xeon X5670  @ 2.93GHz, dual socket, HT enabled
>>>>> Host2: Xeon X5675  @ 3.07GHz, dual socket, HT enabled
>>>>> OS configuration is exactly the same on both machines.
>>>>>
>>>>> Now when I compare the numbers:
>>>>>
>>>>>     Host1:
>>>>>
>>>>>
>>>>> Host2:
>>>>>
>>>>>  user uops kernel uops sim_cycles
>>>>> user uops kernel uops sim_cycles  7210746924 1331578150 13797811843
>>>>> 7210744488 1331141836 13315031456  7210745232 1331564187 13767346806
>>>>> 7210744417 1331064636 13343311719  7210744826 1331475921 13803067702
>>>>> 7210745025 1331429686 13362192919  7210744068 1331046761 13778895729
>>>>> 7210745138 1331530721 13371649704  7210743664 1331602038 13741170045
>>>>> 7210746956 1332519415 13340211019  7210745221 1331551159 13765271526
>>>>> 7210744700 1332103942 13357991805  7210747188 1331712213 13739122442
>>>>> 7210744523 1331264662 13289832849  7210745019 1331550151 13758991929
>>>>> 7210744052 1331141885 13791512144
>>>>> The number of simulated instructions is pretty stable for all runs,
>>>>> but the sim_cycles, hence the IPC number differ.
>>>>> Any idea what the reason for this might be, as it seems that those
>>>>> differences more or less correlate with the clock rate of the host.
>>>>>
>>>>> Regards,
>>>>> Stefan
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> http://www.marss86.org
>>>> Marss86-Devel mailing list
>>>> [email protected]
>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> http://www.marss86.org
>>> Marss86-Devel mailing list
>>> [email protected]
>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>>
>>>
>>
>
> _______________________________________________
> http://www.marss86.org
> Marss86-Devel mailing list
> [email protected]
> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>
>
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel

Reply via email to