Re: [Gems-users] Ruby_current_time

["Dan Gibson" <degibson@xxxxxxxx>]

Jesus,
I think we can attribute the difference in behavior to program phase behavior. I would expect that the fft_ready checkpoint is likely simulating quite a bit of process setup code (e.g. mmap() calls, compulsory TLB misses, thread creation, etc), whereas the one that has been running for a short while, fft_ready2, is probably farther along in execution and actually running mostly FFT.

Here is our usual procedure for ensuring that we only simulate the interesting portions of our benchmarks, and not process setup and teardown:

1) Insert RUBY_MAGIC_CALL()s to break the simulation right after binding threads to processors, and another as soon as the parallel phase is done. An example can be found in $GEMS/microbenchmarks/multiprocessor/parallel.C .
2) Make sure you pass the command 'magic-break-enable' to Simics before you start execution.
3) Load ruby when the simulator breaks on the first magic call.
4) When Simics breaks on the second magic call, dump your stats (end of simulation).

Regards,
Dan

On Mon, Oct 20, 2008 at 6:18 AM, Jesús Camacho <jesuscamacho10@xxxxxxxxxxx> wrote:

Thanks for your answer Dan!
This paper is very interesting.

About your question, my checkpoints only differs because when I execute "write-configuration file", the time is different. For example, I execute "write-configuration fft_ready" when the console shows "./FFT -p16 -m16" and I continue "c"  with the simulation. If one second later I stop the simulation (Ctrl+c) and the console shows the same "./FFT -p16 -m16" (FFT is not running yet, only I prepare a checkpoint) and I execute  "write-configuration fft_ready2", the checkpoints differs in time, but I think checkpoint configuration is the same.

I think the operating system might make different scheduling decisions.
What do you think about?

Thanks again!
Jesús CV.

________________________________
> Date: Fri, 17 Oct 2008 08:36:01 -0500
> From: degibson@xxxxxxxx
> To: gems-users@xxxxxxxxxxx
> Subject: Re: [Gems-users] Ruby_current_time

>
> Jesus,
> I'm not entirely sure what you mean by 'different checkpoints', but this is a known behavior even with the same checkpoint and a different random seed. See Alameldeen et al.: Addressing Workload Variability in Architectural Simulations, in HPCA 2003 or Micro top picks of that year. (Here: http://www.cs.wisc.edu/multifacet/papers/by_topic.html#topic_method)
>
> Basically, if even one processor, say, takes an interrupt and does something else for awhile, system-wide statistics change. This could be going on if you are indeed using different checkpoints. Can you please clarify what you mean by 'different checkpoints'? How do your two .check files differ?
>
> Regards,
> Dan
>

> On Fri, Oct 17, 2008 at 5:51 AM, Jesús Camacho  wrote:
>
> Hi everybody,
> I,m running a FFT simulation on Solaris9 using garnet tools.
> If I run "./FFT -p16 -m16" from different checkpoints (but both from the same machine -Solaris9-) the ruby_current_time and other networks statics differs notably.
> For example, between two different simulations with the same parameters (./FFT -p16 -m16) Network Statics are:
>
> WITH FIRST SIMULATION:
>
> Network Stats
> -------------
>
> Average Link Utilization :: 0.00318694 flits/cycle
> -------------
> Average VC Load [0] = 0.0383004 flits/cycle
> Average VC Load [1] = 0.0384338 flits/cycle
> Average VC Load [2] = 0.0382636 flits/cycle
> Average VC Load [3] = 0.0383937 flits/cycle
> Average VC Load [4] = 0.00280336 flits/cycle
> Average VC Load [5] = 0.00280562 flits/cycle
> Average VC Load [6] = 0.00280483 flits/cycle
> Average VC Load [7] = 0.00280415 flits/cycle
> Average VC Load [8] = 0.00482712 flits/cycle
> Average VC Load [9] = 0.00482258 flits/cycle
> Average VC Load [10] = 0.00481352 flits/cycle
> Average VC Load [11] = 0.00478037 flits/cycle
> Average VC Load [12] = 0.0699856 flits/cycle
> Average VC Load [13] = 0.0694528 flits/cycle
> Average VC Load [14] = 0.0683858 flits/cycle
> Average VC Load [15] = 0.0672418 flits/cycle
> Average VC Load [16] = 0 flits/cycle
> Average VC Load [17] = 0 flits/cycle
> Average VC Load [18] = 0 flits/cycle
> Average VC Load [19] = 0 flits/cycle
> -------------
> Ruby_current_time: 70858800
> Average network latency = 26.8642
> -------------
> Total Link Power = 0.113967 W
> Total Router Power = 9.44946 W
> -------------
>
>
>
> WITH SECOND SIMULATION:
>
> Network Stats
> -------------
>
> Average Link Utilization :: 0.00455201 flits/cycle
> -------------
> Average VC Load [0] = 0.0504177 flits/cycle
> Average VC Load [1] = 0.0511613 flits/cycle
> Average VC Load [2] = 0.0504452 flits/cycle
> Average VC Load [3] = 0.0511084 flits/cycle
> Average VC Load [4] = 0.00406614 flits/cycle
> Average VC Load [5] = 0.00406986 flits/cycle
> Average VC Load [6] = 0.00406815 flits/cycle
> Average VC Load [7] = 0.00406722 flits/cycle
> Average VC Load [8] = 0.00821589 flits/cycle
> Average VC Load [9] = 0.00818839 flits/cycle
> Average VC Load [10] = 0.00814064 flits/cycle
> Average VC Load [11] = 0.00808597 flits/cycle
> Average VC Load [12] = 0.102727 flits/cycle
> Average VC Load [13] = 0.101945 flits/cycle
> Average VC Load [14] = 0.100312 flits/cycle
> Average VC Load [15] = 0.09847 flits/cycle
> Average VC Load [16] = 0 flits/cycle
> Average VC Load [17] = 0 flits/cycle
> Average VC Load [18] = 0 flits/cycle
> Average VC Load [19] = 0 flits/cycle
> -------------
> Ruby_current_time: 50830773
> Average network latency = 25.8351
> -------------
> Total Link Power = 0.162784 W
> Total Router Power = 13.0997 W
> -------------
>
>
> I think the difference in Ruby_current_time between two simulations is not normal.
> Anyone help me?
> Thank you very much,
> Jesús CV.
>
> _________________________________________________________________
> ¡Entra en el Club oficial de Messenger y te enterarás de todas las novedades!
> http://www.vivelive.com/ilovemessenger
> _______________________________________________
> 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.
>
>
>
>
> --
> http://www.cs.wisc.edu/~gibson [esc]:wq!

_________________________________________________________________
¿Eres un cotilla? Disfruta de todas las novedades en MSN Corazón
http://entretenimiento.es.msn.com/corazon/

_______________________________________________
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.

--
http://www.cs.wisc.edu/~gibson [esc]:wq!