Hi,
What about your DRAM model. Are using DDR3 or the similar ones???
On Wed, Nov 6, 2013 at 9:33 PM, Saptarshi Mallick <
saptarshi.mall...@aggiemail.usu.edu> wrote:
> Hello Fulya,
> Can you please give the command line for both the cases,
> which you run for getting the results? I also had the same kind of problem,
> maybe there is some mistake in the command line which we are using.
>
> On Tuesday, November 5, 2013, Fulya Kaplan <fkapl...@bu.edu> wrote:
> > Number of committed instructions
> (system.switch_cpus.committedInsts_total) for;
> > Case 1: 100,000,000
> > Case 2: cpu0->100,045,354
> > cpu1->100,310,197
> > cpu2-> 99,884,333
> > cpu3-> 99,760,117
> > Number of cycles for;
> > Case 1: 150,570,516
> > Case 2: 139,230,042
> > For both cases, they switch cpus to detailed mode at instruction #2
> billion. All the reported data correspond to the 100 million instructions
> in detailed mode.
> > From the config.ini files I can see that separate L2 caches are defined
> for Case 2. My modified CacheConfig.py file to have private L2 caches looks
> like:
> > def config_cache(options, system):
> > if options.cpu_type == "arm_detailed":
> > try:
> > from O3_ARM_v7a import *
> > except:
> > print "arm_detailed is unavailable. Did you compile the O3
> model?"
> > sys.exit(1)
> > dcache_class, icache_class, l2_cache_class = \
> > O3_ARM_v7a_DCache, O3_ARM_v7a_ICache, O3_ARM_v7aL2
> > else:
> > dcache_class, icache_class, l2_cache_class = \
> > L1Cache, L1Cache, L2Cache
> > if options.l2cache:
> > # Provide a clock for the L2 and the L1-to-L2 bus here as they
> > # are not connected using addTwoLevelCacheHierarchy. Use the
> > # same clock as the CPUs, and set the L1-to-L2 bus width to 32
> > # bytes (256 bits).
> > system.l2 = [l2_cache_class(clock=options.clock,
> > size=options.l2_size,
> > assoc=options.l2_assoc,
> > block_size=options.cacheline_size)
> for i in xrange(options.num_cpus)]
> >
> > system.tol2bus = [CoherentBus(clock = options.clock, width = 32)
> for i in xrange(options.num_cpus)]
> > #system.l2.cpu_side = system.tol2bus.master
> > #system.l2.mem_side = system.membus.slave
> > for i in xrange(options.num_cpus):
> > if options.caches:
> > icache = icache_class(size=options.l1i_size,
> > assoc=options.l1i_assoc,
> > block_size=options.cacheline_size)
> > dcache = dcache_class(size=options.l1d_size,
> > assoc=options.l1d_assoc,
> > block_size=options.cacheline_size)
> > # When connecting the caches, the clock is also inherited
> > # from the CPU in question
> > if buildEnv['TARGET_ISA'] == 'x86':
> > system.cpu[i].addPrivateSplitL1Caches(icache, dcache,
> >
> PageTableWalkerCache(),
> >
> PageTableWalkerCache())
> > else:
> > system.cpu[i].addPrivateSplitL1Caches(icache, dcache)
> > system.cpu[i].createInterruptController()
> > if options.l2cache:
> > system.l2[i].cpu_side = system.tol2bus[i].master
> > system.l2[i].mem_side = system.membus.slave
> > system.cpu[i].connectAllPorts(system.tol2bus[i],
> system.membus)
> > else:
> > system.cpu[i].connectAllPorts(system.membus)
> > return system
> >
> >
> >
> > Best,
> > Fulya
> >
> >
> >
> >
> > On Mon, Nov 4, 2013 at 10:35 PM, biswabandan panda <biswa....@gmail.com>
> wrote:
> >
> > Hi,
> > Could you report the number of committedInsts for both the cases.
> >
> >
> > On Tue, Nov 5, 2013 at 7:04 AM, fulya <fkapl...@bu.edu> wrote:
> >
> > In single core case, there is a 1 MB L2 cache. In 4-core case, each core
> has its own private L2 cache of size 1 MB. As they are not shared, i dont
> understand the reason for different cache miss rates.
> >
> > Best,
> > Fulya Kaplan
> > On Nov 4, 2013, at 7:55 PM, "Tao Zhang" <tao.zhang.0...@gmail.com>
> wrote:
> >
> > Hi Fulya,
> >
> >
> >
> > What’s the L2 cache size of the 1-core test? Is it equal to the total
> capacity of 4-core case? The stats indicates that 4-core test has less L2
> cache miss rate, which may be the reason of IPC improvement.
> >
> >
> >
> > -Tao
> >
> >
> >
> > From: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org]
> On Behalf Of Fulya Kaplan
> > Sent: Monday, November 04, 2013 10:20 AM
> > To: gem5 users mailing list
> > Subject: [gem5-users] Weird IPC statistics for Spec2006 Multiprogram mode
> >
> >
> >
> > Hi all,
> >
> > I am running Spec 2006 on X86 with the version gem5-stable-07352f119e48.
> I am using multiprogram mode with syscall emulation. I am trying to compare
> the IPC statistics for 2 cases:
> >
> > 1)Running benchmark A on a single core
> >
> > 2)Running 4 instances of benchmark A on a 4-core system with 1MB private
> L2 cashes.
> >
> > All parameters are the same for the 2 runs except the number of cores.
> >
> > I am expecting some IPC decrease for the 4-core case as the cores will
> share the same system bus. However, for CactusADM and Soplex benchmarks, I
> see higher IPC for case2 compared to case 1.
> >
> > I look at the same phase of execution for both runs. I fastforward for 2
> billion instructions and grab the ipc for each of the cores corresponding
> to the next 100 million instructions in detailed mode.
> >
> > I ll report some other statistics for CactusADM to give a better idea of
> what is going on.
> >
> > Case 1: ipc=0.664141, L2_overall _accesses=573746, L2_miss_rate=0.616
> >
> > Case 2: cpu0_ipc=0.718562, cpu1_ipc= 0.720464, cpu2_ipc=0.717405,
> cpu3_ipc= 0.716513
> >
> > L2_0_accesses=591607, L2_1_accesses=581846,
> L2_2_accesses=568095, L2_3_accesses=561180, L2_0_missrate=0.452978,
> L2_1_missrate=0.454510, L2_2_missrate=0.475646, L2_3_missrate=0.488171
> >
> >
> >
> > Case 1:Running Time for 100M insts = 0.0716
>
> --
> Thank you,
> Saptarshi Mallick
> Department of Electrical and Computer Engineering
> Utah State University
> Utah, USA.
>
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> 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
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
