- Performance optimizations: I can't commit anyone. The semester is starting and the younger students are figuring out their class schedules, and in one instance, studying for the qualifying examination. If the optimizations are important to be done quickly, someone else should look into them.
- Atomic mode: I like the idea of a SLICC implementation that spits out a 'timing protocol' and an 'atomic protocol'. I.e., have slicc spit out its current set of files, plus *_Atomic.[cc,hh] versions? However, I don't have the SLICC knowledge to know if we can expect them to inter-operate -- in particular it seems that in-flight messages would be very troublesome. Perhaps the proper approach is to quiesce ruby, then switch to atomic mode SLICC? Regards, Dan On Thu, Sep 9, 2010 at 5:29 PM, Steve Reinhardt <[email protected]> wrote: > I don't want to distract anyone from Brad's performance optimization > question, but since his email brought this thread back to the top of > my inbox, I wanted to make a comment on this statement before it > drifted back off the top of the stack and I forgot about it again: > > On Tue, Aug 24, 2010 at 9:43 AM, Dan Gibson <[email protected]> wrote: > > Unfortunately, the architecture of Ruby requires events to 'run' in order > to > > service requests. > > How hard would it really be to change this? This is basically the > distinction between "atomic" and "timing" modes in the m5 classic > memory system, and it's good for a 2X performance boost for things > like cache warmup or other cache studies where running for a long time > is more valuable than worrying about detailed timing effects. I > understand that it's a big change from the current design, but given > that SLICC is supposed to be a more abstract definition of the > protocol, it seems to me that having a single SLICC definition drive > both timed and untimed implementations should be fairly natural. > > In the near term it's more important to focus on the 5X performance > difference between Ruby and m5 classic timing mode, but in the long > run I don't want this assumption that Ruby requires events to go > unchallenged... > > Steve > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > -- http://www.cs.wisc.edu/~gibson [esc]:wq!
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
