Andrea,
On Tue, Feb 23, 2010 at 12:05 PM, Andrea Bartolini <a.bartolini@xxxxxxxx> wrote:
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?
I don't know if Simics 4 will allow instruction fetches to be stalled or not on x86.
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.
In theory, the Ruby event queue could be parallelized. In practice, retro-fitting parallelization is rather difficult, and as I said before, there isn't much to be gained (at least, not when I did my profiling experiments). At the time of the profiling, applying infinite speedup to the event queue would only yield a 1.42x increase in performance in the best observed case (f = 18%), with more typical speedups at about 1.1x.
About the second point, do you remember if when you try it you where running entire gems (ruby + opal) or only ruby.
I ran experiments with both. The former was dominated by overhead in SIM_continue(), and in the latter Ruby's event queue was only running 10-18% of the time. The rest of the time, Simics was running.
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?
When I ran my profiling, I profiled the event queue by measuring the time spent in Ruby, via the cycle counter. There is no built-in way to do this.
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
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}