I have more questions/issues on this topic of protocol specific profiling. I do not believe this issues should be fixed by having SLICC understand more STL types. I should have pointed out before that many times it is not one specific protocol that needs special profiling, but rather a set of protocols that need special profiling. In the past, this has been handled by adding special profiling to either the profiler or sequencer, often by using the GenericMachineType. Unfortunately, you've removed GenericMachineType so if one where to compile a protocol that did not create those specific machine types, any special profiling functions that relied on them will fail to build. Why did you remove that enum definition from RubySlicc_Types.sm? Is there any reason we cannot add it back?
Brad -----Original Message----- From: Nilay Vaish [mailto:[email protected]] Sent: Monday, November 24, 2014 6:50 PM To: Beckmann, Brad Cc: gem5 Developer List ([email protected]) Subject: RE: Protocol Specific Profiling On Tue, 25 Nov 2014, Beckmann, Brad wrote: > Thanks Nilay for the prompt reply. An example of a protocol specific > statistic would be if say in a region coherence protocol [Power et > al.], I was profiling the latencies of downgrade request-acks and I > wanted to do that for the cross-product of requestor and request type. > That is just one example, there are a million different possible > statistics one could imagine wanting to collect. The specific example > isn't important, the important part is we need any easy way to add > protocol specific statistic processing. In other words, I want to > collect data that doesn't neatly match a current gem5 statistic type > and instead requires some sort of C++ customization before being added to a > static data type. I think you are using a map or vector of some type. I would probably make SLICC understand what those types are. If you don't want to go that way, then you will have to do something similar to the earlier setup. Prototype a function in one of the .sm files, then define it say in RubySlicc_Util.hh and add the corresponding variable in the Profiler class. > > I'm not advocating for the prior solution. I completely agree going > through the RubySlicc_Profile files was not great, but it is better > than going through the AbstractController. At least the > RubySlicc_Profile files were only collecting profile features. The > AbstractController is growing into a beast. Perhaps what I'm looking > for is an AbstractProfiler class that we can offload the current > profiling work done by the AbstractController. Going through the abstract controller can be another way. I am actually not worried about the size of the class, unless you think that some function or data member is unecessary. We can define a class with in the AbstractController if you are worried about the profiling variables. If I am counting correctly, there are just three of them right now. > > I like the work you've done to collate statistics from independent > object instantiations to a common set of data structures. We need to > work on how those data structures are printed out, but your overall > approach seems great. It seems the real problem we have now is that > the generated collateStats functions directly cast to the > AbstractController, thus all the stat interface functions need to be > in the AbstractController. Instead, we to generate a protocol > specific controller profiler that perhaps inherits from a > to-be-determined AbstractProfiler class. > The Profiler class still exists. You can still define a globally visible function that calls on the profiler to store some statistic. This is what use to happen before. The only other way I can think of is to make SLICC understand the different data structures we want to work with and use them in .sm files. -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
