Thanks for the patches.  Just a few comments/questions:

- Does the indirection of the debug info in Event really save
anything?  As long as TRACING_ON is enabled, you're paying an extra
pointer of storage plus an extra dynamic allocation on every event,
and it's not clear to me just how much you're gaining.

- Does anybody actually use the when_scheduled and when_created
fields?  I don't think I ever have.  Steve Raasch put them in, I
believe.  If you're concerned about the space overhead I'd just whack
those two fields entirely, and then leave the instanceId inline (still
ifdefd with TRACING_ON).

- Does it really matter that events with the same tick and priority
are FIFO vs LIFO?  Seems like it would be just as easy to leave it as
LIFO, which at least wouldn't change the stats.  Not saying that's a
huge reason, but I'm curious what you're motivation is for FIFO that
trumps that.

- Can you find better names than 'one' and 'two' for those lists?
Maybe 'nextBin' and 'nextInThisBin'... those aren't great, but at
least they're descriptive.

Steve

On Mon, Jun 9, 2008 at 10:23 PM, Nathan Binkert <[EMAIL PROTECTED]> wrote:
> Since I'm hoping to have the repo all set soon, I figured I'd start
> sending things out.
>
> This my new event queue data structure.  It is considerably faster (3x
> simulation speed for me) for systems that make heavy use of multiple
> events at the same tick/priority.  Stats will change a bit because
> events of same tick/priority are now FIFO instead of LIFO.  I've been
> using this for quite some time, so it's reasonably tested, but I
> wanted to give people a look see.
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to