A little footnote regarding my last email: When I said that two collections of SimObjects can safely be simulated in parallel if and only if these collections of objects only interact with each other through events I assumed that causality problems are handled by Eventqueues. To be more precise, if objects in one collection can send events to another collection's EventQueue then this one should not simulate past the time of the EventQueue of the objects who can send those events. In PDES terms this collection of SimObjects would be "state objects" and together with their EventQueue they would form a "process". Just so you have an idea of what I mean with my terminology.
Stijn Souffriau wrote: > Nate, > > Sorry I didn't reply sooner. I just saw your email today when I was > searching through this thread. I must have missed it. > > >> Since this isn't likely to be the case any time soon, I don't think we >> should spend time trying to optimize for this. For the next several >> years, I'm pretty sure we'll want to simulate either a ton of simple >> cores on a modest number of real cores, or simulate, in more detail, >> more closely matched guest/host systems. There's also caches that >> should increase cycles. >> >> Anyway, we won't know how things will perform until we try. >> >> >> > > Since a low amount of thread blocks implies a low amount of mandatory > context switches, and vice versa, solving one should pretty much solve > the other. So both problems have the same solutions. > > >>> It may be easier to try to schedule a phone call or something like >>> that. If you're really committed to making this happen, I'm willing >>> to spend some time walking you through code. >>> >>> >>> > First, let me get a clearer picture of which code changes will be > required. I'll email my ideas and after some revision I would appreciate > it if you walked me through some of the code over the phone (do you Skype?). > > As far as me being committed to making this happen. I would like to but > I can't say for sure that I will have enough time (finishing my thesis > is still my primary objective). However I'm pretty sure that > implementing the code to parallelize m5 safely and generically will be > beneficial to my research and require less time, in the long run, than > quick and dirty solutions. So unless some major issue emerges I plan to > get the job done. > > I already have an idea of how m5 could safely simulate disjoint > collections of SimObjects of a configuration on different eventqueues in > parallel. The guarantee m5 would need to have, to let two collections > simulate out of sync safely, is that objects from different collections > only interact through events that can only affect the targeted object. > We would then have disjoint collections of SimObjects where the only > references an object from one collection can have to objects from > another are those of a safe type which only allow event communication. > The python initialization code could then check the SimObjects and their > references and partition the SimObjects in such collections. It could > then automatically assign eventqueues or check if the existing > assignment of eventqueues is safe. If key SimObjects in m5 are then > modified to interact through the safe type, large sections of the > simulator could safely run concurrently. Memory ports would be good > candidates for this. > > Such a safe, generic type could be implemented using templates so it > wouldn't just be a interface with one method "triggerEvent(Event *e)". > Thus still allowing event type checking . I need to figure out a few > more things and then I'll email some more concrete pseudocode. > > Stijn > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
