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
