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

Reply via email to