Thanks for the reply. So I guess it lets the TCG do a better job of creating optimized code sequences for your CPU? But that *does* impact the simulation side of things since the instruction stream that results is then run through marssx86, correct?
I'd be willing to help out with doing some cleanup on the scripts (create_checkpoints.py could definitely use some basic features like optparse and run_bench.py could use some sanity checks on making sure the checkpoint exists and how many cores/megs of memory it was created with). On Mon, Mar 25, 2013 at 3:23 PM, Brendan Fitzgerald <[email protected] > wrote: > Paul, > > After searching the -cpu option performs better with an architecture most > similar to the one you're machine has. It helps to provide features > specific to your cpu. > > Look in qemu/target-i386/cpuid.c for the list of cpu's provided and the > available options. > > Brendan > > On Mon, Mar 25, 2013 at 2:34 PM, Paul Rosenfeld <[email protected]>wrote: > >> I noticed that by default, the create_checkpoints.py file passes the flag >> '-cpu core2duo' to QEMU. Does this have any impact on the checkpoint >> creation process? Should I be passing the same flag when I run the >> checkpoints in marss? >> >> I ask because I've noticed sometimes I get checkpoints that behave >> strangely (i.e., random intervals of inactivity in the benchmark that will >> go away randomly if I re-checkpoint). I'm wondering if there's something >> about the checkpoint creation that might be causing this non-determinism. >> >> Thanks, >> Paul >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
