Hi Brad, I can confirm that this is indeed the cause of the problem. Without any patches applied, changing the hash_map to std::map as suggested changes the regression stats slightly. Hence, the order is of importance.
I will post a patch with only this change, and then eventually also update to the statistics on committing this patch. (An alternative would be to have e.g. a vector next to the hash_map holding the keys in a well-defined order.) Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Beckmann, Brad Sent: 09 April 2012 17:47 To: gem5 Developer List Subject: Re: [gem5-dev] Failing Ruby regressions with gcc >= 4.6 Hi Andreas, I'm pretty confident that this code works correctly independent of the iterator order, however the order will impact the determinism of the simulation. Yes, when I wrote that code, I was leveraging the ordering of the ext/hash_map implementation. I can check in a simple patch that uses the stl::map instead, but it is not easy for me to test with gcc 4.6+. Can I just assume that will fix things, or would you like to test out the changes? Below is the diff (again a very simple change). Brad diff --git a/src/mem/ruby/buffers/MessageBuffer.hh b/src/mem/ruby/buffers/MessageBuffer.hh --- a/src/mem/ruby/buffers/MessageBuffer.hh +++ b/src/mem/ruby/buffers/MessageBuffer.hh @@ -162,7 +162,7 @@ Consumer* m_consumer_ptr; // Consumer to signal a wakeup(), can be NULL std::vector<MessageBufferNode> m_prio_heap; - typedef m5::hash_map< Address, std::list<MsgPtr> > StallMsgMapType; + typedef std::map< Address, std::list<MsgPtr> > StallMsgMapType; typedef std::vector<MsgPtr>::iterator MsgListIter; StallMsgMapType m_stall_msg_map; diff --git a/src/mem/slicc/symbols/StateMachine.py b/src/mem/slicc/symbols/StateMachine.py --- a/src/mem/slicc/symbols/StateMachine.py +++ b/src/mem/slicc/symbols/StateMachine.py @@ -324,7 +324,7 @@ bool m_is_blocking; std::map<Address, MessageBuffer*> m_block_map; typedef std::vector<MessageBuffer*> MsgVecType; -typedef m5::hash_map< Address, MsgVecType* > WaitingBufType; +typedef std::map< Address, MsgVecType* > WaitingBufType; WaitingBufType m_waiting_buffers; int m_max_in_port_rank; int m_cur_in_port_rank; > -----Original Message----- > From: [email protected] [mailto:gem5-dev- > [email protected]] On Behalf Of Andreas Hansson > Sent: Saturday, April 07, 2012 4:18 AM > To: gem5 Developer List > Subject: [gem5-dev] Failing Ruby regressions with gcc >= 4.6 > > Hi everyone, > > With the latest patches for compiling using -std=c++0x and gcc 4.6, there are > sporadic failures for some Ruby regressions, e.g. last night: > > > ***** > build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/ > memtest-ruby-MOESI_hammer FAILED! > > ***** > build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/lin > ux/rubytest-ruby-MOESI_CMP_token FAILED! > > ***** > build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/lin > ux/memtest-ruby-MOESI_CMP_token FAILED! > > > I suspect that this is due to the different implementation of the hash map > (used to be ext/hash_map, and is now unordered map) and the use of > iterators to traverse this map in parts of Ruby. For example, in > StateMachine.py: > > for (WaitingBufType::iterator buf_iter = m_waiting_buffers.begin(); > buf_iter != m_waiting_buffers.end(); > ++buf_iter) { > for (MsgVecType::iterator vec_iter = buf_iter->second->begin(); > vec_iter != buf_iter->second->end(); > ++vec_iter) { > if (*vec_iter != NULL) { > (*vec_iter)->reanalyzeAllMessages(); > } > } > wokeUpMsgVecs.push_back(buf_iter->second); > } > > I am not sure if this particular piece of code is the issue, but in general we > have to ensure that any iteration over a hashtable does not have _any > ordering dependency_ since nothing can be assumed about the order of the > traversal. I can try and look through some of the files, but would greatly > appreciate if someone more at home with Ruby could help and track down all > the places where iteration takes place and confirm that the behaviour is > deterministic independent of the order (or alternatively add an ordered > container next to the hash table for keeping an ordered list/vector etc). > > Thanks, > > Andreas > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
