> On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq_impl.hh, line 55 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55> > > > > is it worth checking inParallelMode first? > > > > As a side not, do we know what the performance impact is when not > > running in parallel mode? (perhaps this has been resolved already) > > Nilay Vaish wrote: > I'll run the regression tests and report the execution time differences > soon.
My _very_ early results suggest around -15% host_inst_rate for most of the regressions, but I'll get back to you tomorrow with a more conclusive result. > On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq.hh, line 472 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line472> > > > > Nothing urgent, but is a list really the best choice here? > > Nilay Vaish wrote: > If you are suggesting that we use a deque, I think there is > no difference in time and space complexities. It's fine. I'm not too worried about the time complexity. Vectors are nice and sequential in memory, lists are scattered all over the place (with some interesting effects http://ecn.channel9.msdn.com/events/GoingNative12/GN12Cpp11Style.pdf). Anyhow, let's wait with the tweaking until we have some more conclusive performance numbers to base it on. On Sept. 21, 2013, 3:39 p.m., Nilay Vaish wrote: > > Some minor comments. One thing I'd like to understand is how this affects > > the ongoing work to run gem5 together with SystemC (as an SC_THREAD in > > fact). Does this patch make the SC integration impossible? If so I think > > there are good reasons to discuss the trade-off in a lot more depth before > > pushing this. > > Ali Saidi wrote: > Why would it make integration with SC impossible? It might require some > changes, but in theory if you were using SC then you could just run it in > thread. Either way, being pragmatic this works now. It allows us to thread > multiple-systems, and lets us make the KVMCPU work with an MP system. > > Steve Reinhardt wrote: > I agree with Ali... I'd think that at worst using SystemC and multiple > threads would be mutually exclusive runtime options, but I can't see why they > would be statically incompatible. Plus since the SystemC stuff is not yet > committed, being able to use multiple threads only when we're not doing > SystemC is clearly not a near-term limitation ;-). There should be a > discussion about how these features work together in the long run, but I > don't see a reason to hold up committing this code while we work that out. Don't get me wrong, I'm not saying there will be trouble. I am merely hoping to understand what this does to the SystemC line of work, and how it would interact. SystemC natively support the notion of multiple threads with quantum-based synchronisation, but the openly available implementation is still single threaded. We should at least understand what pain might arise in the merging of the two. I fully agree that multiple event queues is a useful addition. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1667/#review4727 ----------------------------------------------------------- On Sept. 21, 2013, 6:36 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1667/ > ----------------------------------------------------------- > > (Updated Sept. 21, 2013, 6:36 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9885:ab020183761b > --------------------------- > sim: simulate with multiple event queues > This patch extends the patch Steve posted on the reviewboard (846). The patch > updated with all the changes that have taken place over last 15 months. Code > has been added so as actually carry out a quantum-based parallel simulation. > > The patch was tested in two different configurations: > 1. ruby_network_test.py: in this simulation L1 cache controllers receive > requests from the cpu. The requests are replied to immediately without > any communication taking place with any other level. > 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server > system which are connected by an ethernet link. > > We still lack the ability to communicate using message buffers or ports. But > other things like simulation start and end, synchronizing after every quantum > seem to be working. > > > Diffs > ----- > > src/SConscript 372d3611c693 > src/base/barrier.hh PRE-CREATION > src/cpu/base.cc 372d3611c693 > src/dev/etherlink.cc 372d3611c693 > src/python/m5/SimObject.py 372d3611c693 > src/python/m5/event.py 372d3611c693 > src/python/m5/main.py 372d3611c693 > src/python/m5/simulate.py 372d3611c693 > src/python/swig/event.i 372d3611c693 > src/sim/Root.py 372d3611c693 > src/sim/SConscript 372d3611c693 > src/sim/core.hh 372d3611c693 > src/sim/core.cc 372d3611c693 > src/sim/debug.cc 372d3611c693 > src/sim/eventq.hh 372d3611c693 > src/sim/eventq.cc 372d3611c693 > src/sim/eventq_impl.hh 372d3611c693 > src/sim/global_event.hh PRE-CREATION > src/sim/global_event.cc PRE-CREATION > src/sim/root.cc 372d3611c693 > src/sim/serialize.hh 372d3611c693 > src/sim/serialize.cc 372d3611c693 > src/sim/sim_events.hh 372d3611c693 > src/sim/sim_events.cc 372d3611c693 > src/sim/sim_exit.hh 372d3611c693 > src/sim/sim_object.cc 372d3611c693 > src/sim/simulate.hh 372d3611c693 > src/sim/simulate.cc 372d3611c693 > src/sim/stat_control.cc 372d3611c693 > > Diff: http://reviews.gem5.org/r/1667/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
