On Thu, 9 Jul 2015, Andreas Hansson wrote:
On July 6, 2015, 10:13 p.m., Andreas Hansson wrote:
I'm not too fond of how this is done, since it essentially creates a base class
that only adds baggage to the classic memory system. Is it not possible to
align the two rather? Also, besides the bloat, I am also worried about
performance. Have you measured the impact on the overall regression?
Nilay Vaish wrote:
You are so predictable. I expected those two comments from
you: that I am adding stuff to classic and that I might hurt performance.
I agree with you on both the counts. I personally see this
patch a temporary arrangement (that might remain around for long).
I am trying to improve ruby' speed of simulation. To do that
I need to do away with things that ruby is doing even though those
things are not required. The first thing I am trying to tackle is to
do away with the conversion from a packet to a ruby request. This would
mean that we would need to insert packets into message buffers.
To achieve that end, I need to add this BasePacket class, with both
Packet and Message deriving from it.
I would like to do away with MessageBuffer class today itself. But
Port and MessageBuffer behave differently. Therefore, I don't think people
would
agree to doing away with the MessageBuffer class that easily.
Andreas, I think simulation performance would not be impacted since not
much
code is being added (a few instructions at time of construction of a
packet).
I doubt those few instructions would hurt performance. Just for the sake
of argument, assume for a moment that with this patch applied, there is a
10% increase in simulation time for the classic memory system. I request
you and others who use classic memory system to please bear this loss in
performance for an interim period. As and when we are able to do away
with the MessageBuffer, the BasePacket class would most likely be dropped.
Or redesigned so as to share the common aspects of Packet and Message
classes.
Andreas Hansson wrote:
Predictable you say. I can live with that :-)
I'd normally draw the line at ~2%. 10% is _very_ painful (let's quantify
the actual impact).
Just a thought, can you not simply make the Ruby Message inherit from
Packet?
Nilay Vaish wrote:
I will quantify the actual impact on both classic and Ruby,
once I get to a state where I think people on both sides would
be willing to accept the changes.
Message class can inherit from Packet, but that would mean a lot of
stuff (much more than what BasePacket adds to Packet) getting added
to Message. I initially wanted to drop Message class and use
Packet class throughout Ruby. But that would loss of some
flexibility that Ruby has wrt messages.
Thanks. Based on empirical evidence, Ruby slows down gem5 ~2x compared to
classic, so adding a bit of extra to the Ruby message is probably not a deal
breaker.
I have also observed similar slow downs. In fact O3 CPU + Classic is
faster than Timing Simple CPU + Ruby. But I don't how deriving Message
from Packet class would help here. Again, I am trying to make first
level controllers process packets instead of messages to avoid the
conversion from a packet to a message. This requires that we push packets
in to Message Buffers. And one way of doing that is what I have posted.
If you think that same result can be achieved by deriving Message from
Packet, you need to explain more.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
