you could fix the number of insts or simulate for fixed amount time. In this way this non-determinism can be avoided.
On Mon, Mar 10, 2014 at 6:30 PM, Mitch Hayenga <[email protected] > wrote: > Praxal, > > I'm pretty sure the other two answers answer your question. It is > completely possible for slight timing changes to change the number of > memory accesses and instructions simulated. > > Because the o3 cpu is speculative, slight timing changes can result in > fewer or more speculative memory accesses. Similarly, because you are > running full system you may see more instructions simulated with timing > changes. This is because certain threads may fail to obtain locks and have > to execute more instructions to obtain them (think spin locks). You are > running parsec in your example, so this should be expected. > > The slight differences in your example are "in the noise" regardless. > > Hope this helps. > > > > On Mon, Mar 10, 2014 at 7:54 AM, biswabandan panda <[email protected]>wrote: > >> if i am not wrong, this is FS effect. >> >> >> On Mon, Mar 10, 2014 at 6:20 PM, Praxal Shah <[email protected]>wrote: >> >>> Hi Andreas, >>> Thank you for the reply. >>> I understand that timing may change as I am changing bank configuration. >>> But my question is about *Number of memory Access to the main memory >>> and number of instructions simulated is changing for same program running >>> on different bank configuration. * >>> Sir, I am running same benchmark and not changing cache parameters. with >>> change in bank counts, Number of memory access how can change. >>> And number of Instructions simulated by CPU are also changing. Which are >>> there in stats file.Following are the numbers. >>> >>> *Bank Configuration | Memory Access >>> | Number of instructions simulated* >>> >>> 4 Banks: >>> 4207595 3752886887 >>> >>> 8Banks : >>> 4202333 3753032418 >>> >>> 8Banks 2 Ranks: >>> 4200230 3752892951 >>> >>> 16 Banks: >>> 4201427 3752889830 >>> If I am running same program, then >>> *Number of instructions simulated should not change at least. *I want >>> to understand why there is minute difference between these number in place >>> of being the same number. >>> Thank you >>> >>> On Mon, Mar 10, 2014 at 5:19 PM, Andreas Hansson < >>> [email protected]> wrote: >>> >>>> Hi Praxal, >>>> >>>> I am not using the ruby_fs.py script myself, so I could be wrong on >>>> this point, but I suspect it is using the O3 CPU by default? >>>> >>>> If it is, I'm not surprised the behaviour changes slightly when you >>>> alter the memory system. The dynamic program flow is influenced by the >>>> timing of the load/store requests, and may change. Similarly, even if >>>> you're using the simple timing CPU, as you are running full system, the OS >>>> behaviour may very well change as you perturb the memory system timings. >>>> >>>> In short, there are plenty reasons why things change, and if would be >>>> rather astonishing if you saw the same number of requests in all cases. >>>> >>>> I hope that makes things a bit more clear. >>>> >>>> Andreas >>>> >>>> From: Praxal Shah <[email protected]> >>>> Reply-To: gem5 users mailing list <[email protected]> >>>> Date: Monday, 10 March 2014 06:24 >>>> To: "[email protected]" <[email protected]> >>>> Subject: [gem5-users] Why system.ruby.dir_cntrl0.memBuffer.memReq is >>>> different for same benchmark but different Bank configurations? >>>> >>>> Hi, >>>> >>>> I am running* same benchmark with different bank configuration for >>>> main memory* (Mem-size 1GB) as follows: 4 Banks, 8Banks, 8 Banks 2 >>>> Ranks/DIMM, and 16 Bank 1 Rank/DIMM. >>>> >>>> I am not changing cache hierarchy. Cache parameters are >>>> >>>> --l1i_size=32kB --l1d_size=32kB --l2cache --num-l2cache=1 >>>> --l2_size=512kB >>>> >>>> (./build/X86/gem5.opt configs/example/ruby_fs.py >>>> --disk-image=disks/x86root-parsec.img >>>> --kernel=/binaries/x86_64-vmlinux-2.6.28.4-smp --script=/mem_access.rcS >>>> --cpu-clock=2GHz --l1i_size=32kB --l1d_size=32kB --l2cache --num-l2cache=1 >>>> --l2_size=512kB --mem-size=1GB -n 1 >>>> ) >>>> >>>> *Ideally,I should get request to main memory same for all the >>>> configureations. But I am getting following values for >>>> system.ruby.dir_cntrl0.memBuffer.memReq.* >>>> >>>> 4 Banks: 4207595 >>>> >>>> 8Banks:4202333 >>>> >>>> 8Banks 2 Ranks:4200230 >>>> >>>> 16 Banks:4201427 >>>> >>>> *Is it because of some limitation of gem-5 or something else ?* >>>> >>>> Please give me hint . >>>> I have attached stats file for each of the simulation. >>>> in rcS file. I am dumping stats ad reseting it before benchmark >>>> starts. So look at the other section of the stats. >>>> -- >>>> Praxal S Shah >>>> 9650493254 >>>> >>>> -- 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. >>>> >>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>>> Registered in England & Wales, Company No: 2557590 >>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>>> 9NJ, Registered in England & Wales, Company No: 2548782 >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> >>> -- >>> Praxal S Shah >>> 9650493254 >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> >> -- >> >> >> *thanks®ards * >> *BISWABANDAN* >> http://www.cse.iitm.ac.in/~biswa/ >> >> "We might fall down, but we will never lay down. We might not be the >> best, but we will beat the best! We might not be at the top, but we will >> rise." >> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- *thanks®ards* *BISWABANDAN* http://www.cse.iitm.ac.in/~biswa/ "We might fall down, but we will never lay down. We might not be the best, but we will beat the best! We might not be at the top, but we will rise."
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
