sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gem5/tests/long/se/40.perlbmk/ref/alpha/tru64/simple-atomic/stats.txt

135 lines
14 KiB
Text
Raw Normal View History

config file updates --HG-- extra : convert_revision : b873e0b436d71d86b87b8d9df7115bcc7ceb2b50
2006-10-12 21:04:14 +02:00
---------- Begin Simulation Statistics ----------
Stats: Update the stats. --HG-- extra : convert_revision : 888b6e3bcd432a9318d4b8741a8b274c6f37f1a8
2007-08-27 05:27:53 +02:00
sim_seconds 1.004711 # Number of seconds simulated
sim_ticks 1004710587000 # Number of ticks simulated
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
final_tick 1004710587000 # Number of ticks from beginning of simulation (restored from checkpoints and never reset)
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
sim_freq 1000000000000 # Frequency of simulated ticks
stats: Bump stats for the fixes, and mostly DRAM controller changes
2014-05-10 00:58:50 +02:00
host_inst_rate 2670371 # Simulator instruction rate (inst/s)
host_op_rate 2670371 # Simulator op (including micro ops) rate (op/s)
host_tick_rate 1335473702 # Simulator tick rate (ticks/s)
host_mem_usage 265688 # Number of bytes of host memory used
host_seconds 752.33 # Real time elapsed on the host
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
sim_insts 2008987605 # Number of instructions simulated
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
sim_ops 2008987605 # Number of ops (including micro ops) simulated
stats: update stats for cache occupancy and clock domain changes
2014-01-24 22:29:33 +01:00
system.voltage_domain.voltage 1 # Voltage in Volts
system.clk_domain.clock 1000 # Clock period in ticks
all: Update stats for memory per master and total fix.
2012-06-05 07:23:16 +02:00
system.physmem.bytes_read::cpu.inst 8037684280 # Number of bytes read from this memory
system.physmem.bytes_read::cpu.data 3569416716 # Number of bytes read from this memory
system.physmem.bytes_read::total 11607100996 # Number of bytes read from this memory
system.physmem.bytes_inst_read::cpu.inst 8037684280 # Number of instructions bytes read from this memory
system.physmem.bytes_inst_read::total 8037684280 # Number of instructions bytes read from this memory
system.physmem.bytes_written::cpu.data 1586125963 # Number of bytes written to this memory
system.physmem.bytes_written::total 1586125963 # Number of bytes written to this memory
system.physmem.num_reads::cpu.inst 2009421070 # Number of read requests responded to by this memory
system.physmem.num_reads::cpu.data 511070026 # Number of read requests responded to by this memory
system.physmem.num_reads::total 2520491096 # Number of read requests responded to by this memory
system.physmem.num_writes::cpu.data 210794896 # Number of write requests responded to by this memory
system.physmem.num_writes::total 210794896 # Number of write requests responded to by this memory
system.physmem.bw_read::cpu.inst 7999999586 # Total read bandwidth from this memory (bytes/s)
system.physmem.bw_read::cpu.data 3552681501 # Total read bandwidth from this memory (bytes/s)
system.physmem.bw_read::total 11552681087 # Total read bandwidth from this memory (bytes/s)
system.physmem.bw_inst_read::cpu.inst 7999999586 # Instruction read bandwidth from this memory (bytes/s)
system.physmem.bw_inst_read::total 7999999586 # Instruction read bandwidth from this memory (bytes/s)
system.physmem.bw_write::cpu.data 1578689409 # Write bandwidth from this memory (bytes/s)
system.physmem.bw_write::total 1578689409 # Write bandwidth from this memory (bytes/s)
system.physmem.bw_total::cpu.inst 7999999586 # Total bandwidth to/from this memory (bytes/s)
system.physmem.bw_total::cpu.data 5131370910 # Total bandwidth to/from this memory (bytes/s)
system.physmem.bw_total::total 13131370496 # Total bandwidth to/from this memory (bytes/s)
stats: Update the stats to reflect bus and memory changes This patch updates the stats to reflect the addition of the bus stats, and changes to the bus layers. In addition it updates the stats to match the addition of the static pipeline latency of the memory conotroller and the addition of a stat tracking the bytes per activate.
2013-05-30 18:54:18 +02:00
system.membus.throughput 13131370496 # Throughput (bytes/s)
system.membus.data_through_bus 13193226959 # Total data (bytes)
system.membus.snoop_data_through_bus 0 # Total snoop data (bytes)
stats: update stats for cache occupancy and clock domain changes
2014-01-24 22:29:33 +01:00
system.cpu_clk_domain.clock 500 # Clock period in ticks
tests: update tests for TLB unification
2009-04-09 07:21:30 +02:00
system.cpu.dtb.fetch_hits 0 # ITB hits
system.cpu.dtb.fetch_misses 0 # ITB misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dtb.fetch_acv 0 # ITB acv
system.cpu.dtb.fetch_accesses 0 # ITB accesses
Stats: Update the stats. --HG-- extra : convert_revision : 888b6e3bcd432a9318d4b8741a8b274c6f37f1a8
2007-08-27 05:27:53 +02:00
system.cpu.dtb.read_hits 511070026 # DTB read hits
system.cpu.dtb.read_misses 418884 # DTB read misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dtb.read_acv 0 # DTB read access violations
system.cpu.dtb.read_accesses 511488910 # DTB read accesses
Stats: Update the stats. --HG-- extra : convert_revision : 888b6e3bcd432a9318d4b8741a8b274c6f37f1a8
2007-08-27 05:27:53 +02:00
system.cpu.dtb.write_hits 210794896 # DTB write hits
system.cpu.dtb.write_misses 14581 # DTB write misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dtb.write_acv 0 # DTB write access violations
system.cpu.dtb.write_accesses 210809477 # DTB write accesses
system.cpu.dtb.data_hits 721864922 # DTB hits
system.cpu.dtb.data_misses 433465 # DTB misses
system.cpu.dtb.data_acv 0 # DTB access violations
system.cpu.dtb.data_accesses 722298387 # DTB accesses
tests: update tests for TLB unification
2009-04-09 07:21:30 +02:00
system.cpu.itb.fetch_hits 2009421070 # ITB hits
system.cpu.itb.fetch_misses 105 # ITB misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.itb.fetch_acv 0 # ITB acv
system.cpu.itb.fetch_accesses 2009421175 # ITB accesses
tests: update tests for TLB unification
2009-04-09 07:21:30 +02:00
system.cpu.itb.read_hits 0 # DTB read hits
system.cpu.itb.read_misses 0 # DTB read misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.itb.read_acv 0 # DTB read access violations
system.cpu.itb.read_accesses 0 # DTB read accesses
tests: update tests for TLB unification
2009-04-09 07:21:30 +02:00
system.cpu.itb.write_hits 0 # DTB write hits
system.cpu.itb.write_misses 0 # DTB write misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.itb.write_acv 0 # DTB write access violations
system.cpu.itb.write_accesses 0 # DTB write accesses
system.cpu.itb.data_hits 0 # DTB hits
system.cpu.itb.data_misses 0 # DTB misses
system.cpu.itb.data_acv 0 # DTB access violations
system.cpu.itb.data_accesses 0 # DTB accesses
system.cpu.workload.num_syscalls 39 # Number of system calls
Stats: Update the stats. --HG-- extra : convert_revision : 888b6e3bcd432a9318d4b8741a8b274c6f37f1a8
2007-08-27 05:27:53 +02:00
system.cpu.numCycles 2009421175 # number of cpu cycles simulated
Stats: Re update stats.
2011-02-08 04:23:13 +01:00
system.cpu.numWorkItemsStarted 0 # number of work items this cpu started
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.numWorkItemsCompleted 0 # number of work items this cpu completed
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.committedInsts 2008987605 # Number of instructions committed
system.cpu.committedOps 2008987605 # Number of ops (including micro ops) committed
Stats: Re update stats.
2011-02-08 04:23:13 +01:00
system.cpu.num_int_alu_accesses 1779374816 # Number of integer alu accesses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.num_fp_alu_accesses 71831671 # Number of float alu accesses
system.cpu.num_func_calls 79910682 # number of times a function call or return occured
system.cpu.num_conditional_control_insts 172959296 # number of instructions that are conditional controls
Stats: Re update stats.
2011-02-08 04:23:13 +01:00
system.cpu.num_int_insts 1779374816 # number of integer instructions
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.num_fp_insts 71831671 # number of float instructions
Stats: Re update stats.
2011-02-08 04:23:13 +01:00
system.cpu.num_int_register_reads 2314712013 # number of times the integer registers were read
system.cpu.num_int_register_writes 1332688300 # number of times the integer registers were written
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.num_fp_register_reads 77066699 # number of times the floating registers were read
system.cpu.num_fp_register_writes 52280770 # number of times the floating registers were written
Stats: Re update stats.
2011-02-08 04:23:13 +01:00
system.cpu.num_mem_refs 722298387 # number of memory refs
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.num_load_insts 511488910 # Number of load instructions
Stats: Re update stats.
2011-02-08 04:23:13 +01:00
system.cpu.num_store_insts 210809477 # Number of store instructions
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.num_idle_cycles 0 # Number of idle cycles
system.cpu.num_busy_cycles 2009421175 # Number of busy cycles
system.cpu.not_idle_fraction 1 # Percentage of non-idle cycles
system.cpu.idle_fraction 0 # Percentage of idle cycles
stats: updates due to branch predictor warming
2014-02-16 18:40:34 +01:00
system.cpu.Branches 266706457 # Number of branches fetched
stats: Bump stats for the fixes, and mostly DRAM controller changes
2014-05-10 00:58:50 +02:00
system.cpu.op_class::No_OpClass 185946986 9.25% 9.25% # Class of executed instruction
system.cpu.op_class::IntAlu 1058512437 52.68% 61.93% # Class of executed instruction
system.cpu.op_class::IntMult 15158 0.00% 61.93% # Class of executed instruction
system.cpu.op_class::IntDiv 0 0.00% 61.93% # Class of executed instruction
system.cpu.op_class::FloatAdd 27517120 1.37% 63.30% # Class of executed instruction
system.cpu.op_class::FloatCmp 8254514 0.41% 63.71% # Class of executed instruction
system.cpu.op_class::FloatCvt 6876464 0.34% 64.05% # Class of executed instruction
system.cpu.op_class::FloatMult 4 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::FloatDiv 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::FloatSqrt 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdAdd 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdAddAcc 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdAlu 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdCmp 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdCvt 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdMisc 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdMult 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdMultAcc 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdShift 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdShiftAcc 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdSqrt 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatAdd 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatAlu 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatCmp 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatCvt 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatDiv 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatMisc 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatMult 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatMultAcc 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::SimdFloatSqrt 0 0.00% 64.05% # Class of executed instruction
system.cpu.op_class::MemRead 511488910 25.45% 89.51% # Class of executed instruction
system.cpu.op_class::MemWrite 210809477 10.49% 100.00% # Class of executed instruction
system.cpu.op_class::IprAccess 0 0.00% 100.00% # Class of executed instruction
system.cpu.op_class::InstPrefetch 0 0.00% 100.00% # Class of executed instruction
system.cpu.op_class::total 2009421070 # Class of executed instruction
config file updates --HG-- extra : convert_revision : b873e0b436d71d86b87b8d9df7115bcc7ceb2b50
2006-10-12 21:04:14 +02:00
---------- End Simulation Statistics ----------
Reference in a new issue Copy permalink