Hi Brandon,
> Not looking to pick sides here, but I have also encountered problems with > global/static variables in Ruby as well. This past December, I spent a > couple of weeks trying to clean up the Ruby code so that we could invoke > two instances of Ruby at the same time in the simulator. It was not > trivial as the problems extended into slicc auto-generated code as well and > I ended up temporarily abandoning it. The high level code organization and > design decisions should not prevent us from doing simple straight-forward > things like invoking two Ruby instances at the same time. > > When I was trying to solve the problem, I independently followed the same > method as Nilay. I added ruby system pointers to most of the objects so > that they could back-reference the system object (since it's the central > point of that Ruby instance) and obtain access to the other subsidiary > objects. I felt really dirty while writing the code and frankly the code > was painful to look at, but there didn't appear to be a better method (at > least not one that I could see). A couple of folks that I spoke with here > at AMD felt that the global/static variables needed to be fixed, but agreed > that there was no easy solution. > Thank you for this input. I completely agree that the code organization is pretty problematic for using multiple instances of the RubySystem, which would be nice for simulating multiple systems in a single simulation. I also thought through this during my review of the patch in question. That said, it seems that your argument here favors neither or both Nilay's and my positions, but not either. First, I haven't heard publicly that the gem5 community has adopted the aim developing gem5 toward allowing multiple RubySystem instances. I'd prefer the community unite on a multiple-RubySystem aim before we use the possible functionality to support either position. Now, I'm willing to accept that there are gem5 users who may desire to simulate multiple systems and that it may be in the community's interest to adopt this direction. However, as the code is currently written, this cannot work (as you note) due to inappropriately scoped RubySystem variables. It's hard to say whether/how the RubySystem should exist in a multi-system simulation, and I can envision organizations that support both Nilay and me. Some details: Part of my original suggestion on this patch was aimed at better scoping, which would support multiple RubySystem instances: we should statically (i.e. "globally") define the warmup and cooldown variables of the RubySystem. Warmup and cooldown are simulator-wide operations, which could cause activity across separate RubySystem instances, depending on the simulated systems' organizations. Second, some variables that are currently static in the RubySystem cannot be. For example, cache block size could be different between two separate RubySystems. Such variables should likely be instance variables. So, it is likely that there are parts of the RubySystem that should be specific to each instance, and there are likely parts that should still be global. Does that mean we'd need to pass a local RubySystem pointer to each controller? If we improve the variable scoping, it should be less likely we need local pointers, but it's still unclear. For now, I expect that keeping the code consistent (i.e. just using the existing g_system_ptr) will make it the most extensible for adding the multiple RubySystem functionality later. Joel > ________________________________________ > From: gem5-dev [[email protected]] on behalf of Nilay Vaish [ > [email protected]] > Sent: Tuesday, April 14, 2015 11:33 AM > To: gem5 Developer List > Subject: Re: [gem5-dev] changeset in gem5: ruby: allow restoring from > checkpoint when us... > > On Tue, 14 Apr 2015, Joel Hestness wrote: > > > This patch didn't address my requested change ( > > http://reviews.gem5.org/r/2702/), and shouldn't have been checked in. > The > > AbstractController should not have or even need another pointer to the > > RubySystem, because it can access it with g_system_ptr. This is a dead > > simple fix. Adding the pointer is going in the wrong direction for > > abstraction. > > > > Joel, in my opinion we should be eliminating global / static variables. > I have personally found them to be a problem while trying to parallelize > Ruby. > > -- > Nilay > _______________________________________________ > 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 > -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
