Hey Andreas, I also apologize for ignoring this for a while. I need to get back in the habit of responding to dev list emails and reviews :/...
My personal opinion, and what I've been telling my students, is that when running research experiments for papers/presentations, there should be at most 2 command line parameters to your run script: One for the workload to run and one to specify the configuration under test. Everything else should be in the python run script or python config scripts (which are two different scripts, too). However, I understand that when exploring things before running careful experiments it's useful to have command line parameters. I (again, personally) think that all of these command line parameters should be things the user (experimenter) explicitly decides is important to vary. As such, I've been discouraging everyone from using scripts like se/fs.py which are the antithesis to this outlook. That said, I can see how this feature could be useful. And I appreciate how you've separated structure from parameters. Although, there's cases where this isn't clear cut. E.g., the branch predictor isn't really structure, but it's not a simple parameter, either. I also want to echo Gabe's point on building brittle hierarchies of scripts. I've seen some gem5 script script scripts that haunt my nightmares. I think, as a community project we should try to steer our users towards good development practices. However, we also shouldn't dictate to them how to use the tool. In conclusion, I think this idea is a huge improvement over se/fs.py. However, it does have the chance to be abused, but I don't think it's necessarily our responsibility to build a tool that is impossible to use incorrectly. Instead, I think it's our responsibility to document how to use the tool correctly. I definitely won't block this change going in, but I might still discourage people from using it ;). I'll try to set aside some time tomorrow to catch up on these patches and other patches on gerrit. I'll probably have more specific things to say after digging into the code. Cheers, Jason On Thu, Oct 4, 2018 at 2:37 PM Gabe Black <gabebl...@google.com> wrote: > Hi, sorry for taking a while to reply to this. > > I think this is a good idea if kept small/limited, but has a lot of > potential for abuse. gem5 seems to oscillate (over long periods of time) > between command line arguments and languages/files to configure itself. > People want command line options because they're easy to adjust from the > command line, but then they're too limited and there are too many of them, > so then the add a layer of scripts on top of that to set all the options. > But then they want to be able to adjust what they're scripts do, and so > they add command line arguments. And then somebody else comes along and > doesn't want to mess with any of the things that exist, so they add a > script on top of the arguments on top of the script on top of the arguments > on top of gem5, perhaps in the form of a Makefile, local bash script, etc. > The tower gets taller and taller, and more and more fragile, etc. > > However, I think this idea has the potential to short circuit that cycle a > bit by making it possible to have a very simple but very general purpose > command line argument that lets you make small adjustments to a script > without having to add a knob for every little thing. If, however, it gets > to be more and more powerful (filters, wildcards, then small lambdas, etc.) > it just turns into a tortured little scripting language in and of itself > which is even worse than just using a real language like python. If you're > doing something more complicated, you should just bite the bullet and > modify the underlying script. > > So, after some thought, I think this is an idea worth pursuing, and its > scope should be carefully limited and controlled. > > Gabe > > On Wed, Sep 26, 2018 at 7:01 AM Andreas Sandberg <andreas.sandb...@arm.com > > > wrote: > > > Hi Everyone, > > > > One of my colleagues just posted a couple of RFC patches [1, 2] that > > introduce functionality to override SimObject param values from the > > command line. These patches aim to solve the explosion of command line > > arguments that tend to build up in example scripts when people want to > > tune various parameters. I'd like to start a discussion around these > > features and some feedback from the wider gem5 community. > > > > There has been talk about adding this type of functionality, both on > > the dev list and offline, for quite some time. I am of the opinion that > > there should be a clear distinction between structural configuration > > (instantiating objects and wiring ports) and parameter tuning. For that > > reason, these changes don't provide a mechanism to instantiate new > > SimObjects. Structural configuration is left to the configuration script. > > > > It supports simple statements like "test_sys.cpu[0].socket_id = 2". > > Unlike "normal" Python statements, you can operate on multiple > > SimObjects at the same time using Python's slice syntax. For example, > > "test_sys.cpu[0:3].socket_id = 2" sets the socket_id param on CPU 0-2. > > In addition to slicing, it's posssible to select multiple indices: > > "test_sys.cpu[0,1,2].socket_id = 2" > > > > The current mini-language is a proof-of-concept and build uses a custom > > Python eval environment to override parameters. The implementation > > ensures that it only operates on SimObjects and Params. Other object > > attributes cannot be overridden. > > > > It would be really cool to have a richer language (e.g., something like > > similar to XPath or ObjectPath[3]) to select objects with specific > > properties. The current implementation tries to balance implementation > > simplicity and usability by (ab)using eval in a limited environment. If > > you know of a better way of doing this, please let us know. > > > > Cheers, > > Andreas > > > > [1] https://gem5-review.googlesource.com/c/public/gem5/+/12984 > > [2] https://gem5-review.googlesource.com/c/public/gem5/+/12985 > > [3] http://objectpath.org/ > > > > 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 > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
