Dear Avais, I think it is reasonable to normalize with the numbers of executed instructions, but it still is a weakness that the running sections of benchmarks are not same totally. In my case, it was my best to exit the simulation by the total numbers of executed instructions. But if you can apply FIESTA methodology, it will be better.
Best Regards, Haeyoon Cho. 2018-05-25 12:17 GMT+09:00 Muhammad Avais <avais.suh...@gmail.com>: > Dear Haeyoon Cho., > > I am really thankful to you for this help. Actually, i am not very good in > modifying gem5 and this code will be very helpful for me. > > I have one more question, is it good idea to normalize the stats with > number of instructions simulated to calculate energy or other things? Does > people use this? Or some other metric to compare energy? > > Many thanks for your help, > Best Regards, > Avais > > On Thu, May 24, 2018 at 5:45 PM, 조해윤 <chohy2...@gmail.com> wrote: > >> Dear Avais, >> >> I think running workloads fairly is very important in multi-core >> experiments, because the number of executed instructions of each core can >> be changed depend on each experimental configuration. >> There is a prior work how to experiment fairly on multi-core system; A. >> Hilton et al., "FIESTA: A Sample-Balanced Multi-Program Workload >> Methodology", MoBS, 2009. >> However, implementing this methodology in gem5 is another problem, and I >> couldn't do that. >> >> Alternatively, I modified the gem5 code to terminate by the number of >> total executed instructions of all cores. >> Existing gem5 code can only terminate by the maximum or minimum number of >> executed instructions per core. >> Since LocalSimLoopExitEvent() is called in CPU class in existing gem5 >> code, I modified system class code to correct the number of executed >> instructions of all cores and to call LocalSimLoopExitEvent() by system >> class. >> As I think, the most important part is whether you can call >> LocalSimLoopExitEvent() when you want. >> I attach total_sim_exit.patch just for reference. >> I modified followed six files. >> /configs/commom/Simulation.py >> /src/sim/system.hh >> /src/sim/system.cc >> /src/sim/System.py >> /src/cpu/simple/base.hh >> /src/cpu/o3/cpu.cc >> This attached file may not compatible with current gem5 code, because I >> modified code base on stable version of gem5 code. >> Also, this modification is just for restrictive situation that one fast >> forward and one real simulation, and coding style is not good. >> >> If you can modify gem5 code better than me, please let me know. >> >> Best Regards, >> Haeyoon Cho. >> >> >> 2018-05-23 15:55 GMT+09:00 Muhammad Avais <avais.suh...@gmail.com>: >> >>> Dear All, >>> >>> I want to measure dynamic energy of L2 cache for multi-core >>> simulations. For this purpose, i measure stats from gem5 like # of hits, # >>> of misses and # of writebacks. >>> As, multi-core simulation in gem5 terminates, as soon as, any >>> workload reaches maximum count. Therefore, while comparing different >>> schemes, each scheme terminates after different number of instructions, so >>> stats like # of hits, # of misses and # of writebacks are not useful. >>> Is there any other metric that can be used to compare energy in >>> multicore systems like weighted speed up for performance. Or is it possible >>> that simulation always runs for fixed number of instruction. >>> >>> Many Thanks, >>> Best Regards, >>> Avais >>> >>> _______________________________________________ >>> gem5-users mailing list >>> firstname.lastname@example.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> email@example.com >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > firstname.lastname@example.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list email@example.com http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users