On Tue, Jan 17, 2012 at 4:09 AM, 呂敏中 Min-Zhong Lu <[email protected] > wrote:
> Hello Everyone, > > We're currently using MARSSx86 and have countered some problem that we > hope you can help solve. > > We have installed Ubuntu 10.04 (Lucid) 64-bit Server as the guest > operation system, and run several SEPComp benchmarks on the guest operation > system. > > For now, we use the "start-sim, run benchmark, kill-sim" shell command > sequence (as outlined in the MARSSx86 wiki: ) to run the benchmarks. > > However, we found that the resulting statistics (such as those reported by > DRAMSim2) vary a lot across different runs with the same configuration. > > Because our benchmarks load and parse data from disk when its run (with > the "disk" being a QEMU disk image on the host harddisk), and such > loading/parsing can take several seconds (in native mode), our educated > guess is that, since we have set the configuration file such that PTLsim > will only simulate for 1 billion cycles (which translates to only 0.25 > seconds of guest environment given the 4GHz core frequency), we have > probably only simulated the load-data-from-disk stage instead of the actual > computation stage. Since the actual time spent on the load-data-from-disk > stage depends on how the host environment schedule disk requests, the time > may not consistent across different runs, and thus the inconsistent > statistics reported. > > We wonder if there is any mechanism in MARSSx86/PTLSim/QEMU such that we > can bypass the load-data-from-disk stage, or bypass/ignore any influences > it brings, and directly simulate the actual computation stages of the > benchmarks? Currently we work-around this problem in a quite manual way: > for each benchmark, we insert the "start-sim" call in its source code just > before the computation stage starts; however, this approach may not only be > likely to be imprecise but also become a hassle to apply to the vast number > of benchmarks. > > The approach of *marking* start of the computation phase is the most used method for capturing the region-of-interest. We use 'create_checkpoint' function instead of 'start-sim' so once we have the checkpoints then we dont have to manually start the benchmarks. I agree that modifying benchmarks takes a time and its one of the most tedious work, but that the part of research process and its inevitable. If you don't use 'ptlcalls' then please use them as they are more precise. Talking about variations, in our studies with Parsec benchmarks we have found that in few benchmarks - 'Vips', 'ferret', 'dedup', we have very high variation between simulation runs. One common issue among these benchmarks is *thread-affinity*. With 'vips' it uses some library that automatically spawns the threads and we can't assign each thread to a core. With 'ferret' and 'dedup' when we specify 'n' parallelism, it creates 'n*3' and 'n*4' number of threads respectively, and due to high number of threads in system the pthread scheduler will introduce lot of variations between runs. So to generate more deterministic simulation runs you have to control your simulation environment which is a very tricky part. Hope this helps. - Avadh As a side note: we use a machine configuration based on the ooo core, with > four cores on the CPU. The host is also an Ubuntu 10.04 64-bit Server. > > Your answer is greatly appreciated. > > My regards, > Min-Zhong Lu ([email protected]) > Dept. of Computer Science and Information Engineering, > National Taiwan University > > ------------------------------**------------------------------**---- > This message was sent using IMP, the Internet Messaging Program. > > > > ______________________________**_________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected].**edu <[email protected]> > https://www.cs.binghamton.edu/**mailman/listinfo/marss86-devel<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
