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
