Re: [Gems-users] GEMS on simics 4 - Parallelize gems - Un-stall simics for multiple cycles

[Andrea Bartolini <a.bartolini@xxxxxxxx>]

Hi Dan,
thanks for your fast reply, 

Ok if simics 4 as you pointed out at the end combined with gems does not shows significants improvements, I believe at the moment is quite useless to push for moving to it. Just one curiosity does it allow for accounting instruction fetch and istruction cache on x86 simulation?

For the other questions I trust you when you say that a parallel gems - sounds nice but at the end is quite tricky. But it could be a solution to avoid simics accelerator to not "evaporate" its benefits. 

About the second point, do you remember if when you try it you where running entire gems (ruby + opal) or only ruby. I believe in the first case you must stop anyway simics cycle-by-cycle but in only ruby configuration it should work better. There is any fast way to profile the event queue usage during a simulation. Lets say having a percentage of time in which ruby was called but actually did not have any event to process?

Thanks again.
Best,

Andrea

-------------------------------------------------------------------------------------------------------------------------------------
On Tue, Feb 23, 2010 at 11:08:34 -0600, Dan Gibson <degibson@xxxxxxxx> wrote:

Andrea,
I'm afraid you will find most of my response disappointing. Please take note of it in sections, below, in response to your individual questions.

On Tue, Feb 23, 2010 at 7:59 AM, Andrea Bartolini <a.bartolini@xxxxxxxx> wrote:

    Dear experts,
    I looked for informations on the mailing list about the possibility of run gems on simics 4. I did not found positive ones but is even true that are quite old.
    So I was wandering if anyone of you manage to run gems, mainly ruby, on  simics4.


GEMS will run on Simics 4. We have managed to mate GEMS to Simics 4 internally using a setup process identical to that of Simics 3. We have not yet fully convinced ourselves that the results of delivered by a Simics4+GEMS configuration are sufficiently identical to those of a Simics3+GEMS configuration -- that is, we have not fully evaluated how much the Simics version affects results, and we do not use Simics 4 internally. We therefore suggest users continue to use Simics3, in which we have more confidence.
 


    I noticed that the main changes are in some header files in simics 4.0, and I try to manually adapt it, but after 2 days still have compilation problem.
    I would like to use the simics 4 version since should have better performance, by meaning accelerator and native x86 executions.
    indeed I'm working with x86 simulation so I'm not using opal.


You will find that the performance claims of Simics 4 will evaporate when you use Ruby. All of the optimizations that make *emulation* faster tend to actually slow detailed *simulation* down, quite substantially. Native x86 execution is essentially useless in this context, as every memory reference, including instruction fetch, needs to stall via Ruby anyway. The performance advantage of native execution is totally lost when single-stepping instructions.
 


    I have other two questions:
    1) If is possible to run gems with simics 4 and the accellerator, 


Essentially, no. There are substantial problems. As I recall, the accelerator is parallel and not deterministic, which would make repeatability of results a substantial problem.
 

    does anyone thought about parallelize gems and the eventqueue ? 


We've talked about this for a long time. Profiling reveals that not a lot of time in a Simics+Ruby configuration actually goes to running the event queue. Most of the apparent slowdown seems to be due to the fact that stalling in Simics isn't optimized. Admittedly, the data to which I refer is quite old (4+ years), and may not reflect the behavior of Simics3/4.
 

    Ore someone of you already did it.
    2) Since I'm using gems without opal, but only ruby + simics x86 simulator, I had a thought about how to improve the performance, and I would like to have a feedback from all you experts:
    - I notice that the main slow down is due to the start and stop cycle-by-cycle of simics due to ruby module. I was wandering if it is possible to un-stall simics not cycle-by-cycle, but do it for bigger number of cycles. The number of cycles can be selected looking on the eventqueue and checking for the position of the next event posted. In this way you can speed-up the simulation by stop simics only when gems has something to do. Do you thinks this could work or there are drawbacks on doing this?


I see no reason why what you propose cannot be done. Indeed, I have tried it myself on older Simics versions. My experience was that there was no significant difference in performance, but things may have changed in the four years since my last attempt.

Best of luck.

Regards,
Dan
 


    Thanks in advance,
    Andrea Bartolini
    _______________________________________________
    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