> How is it a lot more work? I would think that the hard part is > tracking the previously scheduled events so that you know when you > have two at the same tick. Having a base ChainableEvent class that > has a next pointer in it and a method to process the events linked off > of that doesn't sound so bad. Plus it sounds like you already have > that code written :-). Mostly because you must define it, initialize it, and schedule it. It's also not necessarily trivial to know when you need to schedule it. What if you have no events on a particular cycle? I've added support for all of this stuff, but it still feels clunky.
> Depends on how you structure the processing of the chained events, I > guess. I don't have a clear enough picture of what you're doing to > follow. Well, right now, there are two pointers in the event class. One is to link "bins" where each bin is a different tick/priority. The other is to link elements that are in the same bin. So, right now, adding elements to a bin doesn't cost extra. (This was a huge performance win). > Plus you would save a few instructions by not having to compare each > timestamp against curTick as you walk the list... You don't have to check once you've found the bin. > I don't have a really strong feeling either way, but my gut reaction > is that it's a very specific and perhaps uncommon situation, and I'm > reluctant to extend a very universal and generic interface to optimize > for it unless there's really no comparable way to handle this special > case outside of the core event queue. Well, it wouldn't be a mandatory interface, I'd actually implement it as an overloaded version of schedule, so the impact would be nil if you didn't use it. I also suspect that it would mostly be used so I could make my implementation of "ChainableEvent" cleaner. Very related, I wanted to implement a timing wheel class where I could schedule on specific cycles in the future. With the hint mechanism, I could keep a short list of hints for the next N cycles in the future, and if I go beyond N, I could just schedule it normally on the event queue. I could (and have) created a TimingWheel class that is a single scheduleable entity (it actually derives from event), but it's not easy to avoid scheduling on a specific cycle because what happens if the next cycle you have an event for is 9, so you schedule that, but then in between, something (like an interrupt) comes by and tries to schedule something for something sooner. You can just schedule the event then, but it's just simpler to use the main event queue to do it. So, I don't expect people to use the hint generally, rather, I plan to build useful primitives on top of the event queue with it. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
