Hi all, You can use python multiprocessing with gem5. See https://github.com/gem5/gem5/tree/develop/src/python/gem5/utils/multiprocessing for details.
So, in theory, you can create scripts such that you can run `./gem5 run.py` which will run a set of different experiments. You could potentially even send a subset of stats back to the main `run.py` script for post-processing, though I haven't tested that, yet. We are planning to add extensions to the simulator module to make this more user friendly in gem5 23.1 (the release after gem5 23.0). Cheers, Jason On Wed, Jun 14, 2023 at 11:01 AM Eliot Moss via gem5-users < gem5-users@gem5.org> wrote: > On 6/14/2023 11:30 AM, Derek Christ wrote: > > Hello Eliot Moss, [one ell please] > > > a shared Python file with parameter settings sounds useful. > > > What I meant with running gem5 without the gem5 executable was to use the > > compiled library directly from the Python configuration script. > > > From what I have seen, the gem5 executable sets up some internal state > and > > then directly calls the embedded Python interpreter to launch the > > user-provided script. > > > But as I see it there is no technical reason why it shouldn't be > possible to > > call this setup routine directly from Python. This would reduce the > > complexity to only one single Python script. > > Well, there may remain value to having a standard setup/run script that > invokes a user supplied script. It helps keep gem5 per se separate from > the > user's setup / configuration - a principle of modularity. > > A quick look at main.cc suggests you may be right that this *could* be > done, > though I have no idea what those various setup functions do and whether > any of > that would be hard to do from python. What I suppose I am missing is the > motivation - why such a change would be substantially better. My > applications > tend to be quite complex and I find I need the layers of script, for > various > reasons. Maybe this has more to do with preference to write in python vs > bash > scripts vs C++ code. > > gem5 is not currently packaged as a library, I don't think, though I > suppose > it could be. Given the amount of existing projects and infrastructure, one > would need to continue to support the current way of doing things as well. > This might further complicate the system and its maintenance - one hopes by > not very much. > > HTH - EM > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
