On Mon, 24 Jan 2011, Nilay Vaish wrote:
On Tue, 18 Jan 2011, Beckmann, Brad wrote:
Hi Nilay,
My plan is to tackle the functional access support as soon as I check in
our current group of outstanding patches. I'm hoping to at least check in
the majority of them in the next couple of days. Now that you've completed
the CacheMemory access changes, you may want to re-profile GEM5 and make
sure the next performance bottleneck is routing network messages in the
Perfect Switch. In particular, you'll want to look at rather large (16+
core) systems using a standard Mesh network. If you have any questions on
how to do that, Arka may be able to help you out, if not, I can certainly
help you. Assuming the Perfect Switch shows up as a major bottleneck (>
10%), then I would suggest that as the next area you can work on. When
looking at possible solutions, don't limit yourself to just changes within
Perfect Switch itself. I suspect that redesigning how destinations are
encoded and/or the interface between MessageBuffer dequeues and the
PerfectSwitch wakeup, will lead to a better solution.
Brad
Hi Brad,
I was thinking about the design of the PerfectSwitch. I have at least one
very simple optimization (just need to add one character to
PerfectSwitch.cc). But then, the gains are not that much (about 1% for the
particular instance that I saw).
Do you think most of the messages that are sent out have a single
destination? I am not sure if that statement is clear. What I want to say is
that whether the number of destinations where a message needs to be
delievered is one with a high probability. Can we redesign the routing table
so that instead of being from a mapping from links to destinations, it maps
destinations to links? Or may be we can have both the representation?
I believe, and this is really my belief (no empirical evidence), that most of
the time is spent in going through all the links, setting values that would
not be used at all and checking whether a link can route to a destination or
not.
Suppose most of the messages are to be delivered to a single destination.
Then, with the redesigned routing table, we only look at the links that can
route to that destination and then choose one adaptively or otherwise.
What do you think?
--
Nilay
I tested my hypothesis yesterday. About 90% of the messages have
destination count = 1. I think, for such messages, we should avoid going
through the entire routing table. Instead, we should also keep a mapping
from destination to set of output links and use that mapping for routing.
--
Nilay
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
