I see. So it needs the bits in the set to identify which controllers to send to, and it can’t just send to all controllers? That is, the on-chip doesn’t have a list of all known controllers that it could use to identify where the messages should be sent?
From: Nilay Vaish [mailto:[email protected]] On Behalf Of Nilay Vaish Sent: Thursday, September 03, 2015 1:56 PM To: Nilay Vaish; Gutierrez, Anthony; Default; Jieming Yin Subject: Re: Review Request 3014: ruby: set: reimplement using std::bitset This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3014/ On August 17th, 2015, 9:37 p.m. UTC, Jieming Yin wrote: src/mem/ruby/common/NetDest.cc<http://reviews.gem5.org/r/3014/diff/1/?file=48812#file48812line113> (Diff revision 1) NetDest::getAllDest() 113 int id = MachineType_base_number((MachineType)i) + j; 113 int id = MachineType_base_number((MachineType)i) + j; m_bits[i].getSize() returns NUMBER_BITS_PER_SET, which is 64 for all machine types. In case of broadcast, all bits are set in m_bits. Will it cause problem if the number of actual components is smaller than NUMBER_BITS_PER_SET? Perhapse in class Set, add a size parameter is a better idea to prevent such situation. On August 31st, 2015, 2:59 p.m. UTC, Nilay Vaish wrote: I have added back the m_nSize variable. On September 3rd, 2015, 6:05 p.m. UTC, Tony Gutierrez wrote: Maybe I'm missing something here, but why is m_nSize necessary for broadcast? It seemed to me that broadcast() only looks to see if all bits for the set are set, and doesn't determine how many to components to broadcast to. So it seems fine to me to have the logic of broadcast() be such that it will be considered a broadcast if all bits are set, and not a broadcast otherwise, the fact that there are extra bits set doesn't seem to matter. On Thu, 3 Sep 2015, Tony Gutierrez wrote: Maybe I'm missing something here, but why is m_nSize necessary for broadcast? It seemed to me that broadcast() only looks to see if all Because of the way broadcast is implemented by the on-chip network. bits for the set are set, and doesn't determine how many to components to broadcast to. So it seems fine to me to have the logic of broadcast() be such that it will be considered a broadcast if all bits are set, and not a broadcast otherwise, the fact that there are extra bits set doesn't seem to matter. The on-chip will try to send the broadcast message to controllers corresponding to bits that are set. Hence, if there is no size variable to determine the maximum number of bits in use, then messages will be sent to non-existent controllers. - Nilay On August 31st, 2015, 2:58 p.m. UTC, Nilay Vaish wrote: Review request for Default. By Nilay Vaish. Updated Aug. 31, 2015, 2:58 p.m. Repository: gem5 Description Changeset 11077:0dfa7e7d62d0 --------------------------- ruby: set: reimplement using std::bitset The current Set data structure is slow and therefore is being reimplemented using std::bitset. A maximum limit of 64 is being set on the number of controllers of each type. This means that for simulating a system with more controllers of a given type, one would need to change the value of the variable NUMBER_BITS_PER_SET Diffs * src/mem/ruby/common/Set.hh (969113566d50) * src/mem/ruby/common/Set.cc (969113566d50) * src/mem/ruby/common/NetDest.hh (969113566d50) * src/mem/ruby/common/SConscript (969113566d50) View Diff<http://reviews.gem5.org/r/3014/diff/> _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
