I agree that single-threaded simulations should not be paying any significant overhead. It would be nice to make this a runtime thing though. For example, a lot of the multi-thread overhead is in the periodic synchronization events, and if we know we're in single-threaded mode we just don't ever schedule any of those, so then there's no overhead but no ifdef required either.
Some of the other things might me a little trickier; for example, for things like the etherlink or bus that require internal locking, perhaps we want the multithread version to be a subclass, then if we know all the communicating objects are on the same thread we just instantiate the base class that doesn't have the locking in it. For DPRINTFs we can probably just leave the locks in; they're expensive enough anyway that the extra overhead of doing a lock on a single-threaded system is probably negligible. Thoughts? Any other specific cases where this approach wouldn't work? Steve On Tue, Feb 5, 2013 at 11:30 AM, Nilay <ni...@cs.wisc.edu> wrote: > We need to decide on whether the code for multi-threading the simulation > is always compiled or is it optional. I am right now leaning towards it > being optional. All the code required for multi-threading should be > protected by a #ifdef macro. This is so that the performance impact on > single threaded simulations is kept to the minimal. > > -- > Nilay > > On Mon, February 4, 2013 10:11 am, Steve Reinhardt wrote: > > I agree, this seems like a good time to clean things up and get them > > committed, and ideally create a regression test too. > > > > My preference for the next step after that is to start doing some > > intra-node parallelization, which would mean doing to some internal > > interconnect what was done to the etherlink. This would be either the > Bus > > object for the classic memory system or something else (maybe > > MessageBuffer?) for Ruby. > > > > Steve > > > > > > On Mon, Feb 4, 2013 at 6:32 AM, Ali Saidi <sa...@umich.edu> wrote: > > > >> > >> > >> Hi Nilay, > >> > >> That is awesome! If I understand then you have two > >> systems communicating together over an ethernet link. I would suggest > >> that this might be a good time for a checkpoint, getting the patches in > >> state that are good, deciding on a threading model, and getting the > >> first pass committed. > >> > >> Thanks, > >> > >> Ali > >> > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
