Lanier Watkins, 404-406-5426
----- Reply message ----- From: [email protected] To: <[email protected]> Subject: gem5-users Digest, Vol 83, Issue 18 Date: Thu, Jun 6, 2013 11:36 am Send gem5-users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of gem5-users digest..." Today's Topics: 1. Re: Timing CPU model (Guru Prasad) ---------------------------------------------------------------------- Message: 1 Date: Thu, 6 Jun 2013 11:43:18 -0400 From: Guru Prasad <[email protected]> To: gem5 users mailing list <[email protected]> Subject: Re: [gem5-users] Timing CPU model Message-ID: <CAMefCkAA9e_+Tf9CTBfW3-sWS3bfvG4Equ58rur=2jrwico...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Please disregard the previous E-mail. It has some wrong facts Hi All, A small follow-up on this question. TimingSimpleCPU model seems to work more consistently with --caches enabled. However, the Linux kernel is still unable to accurately compute loops per jiffy for the timing model CPU..(it always computes 997 BogoMIPS) My program output also seems to suggest that regardless of the --clock frequency specified, the output is always the same and it is close to the values obtained from AtomicSimpleCPU model running at 1GHz. AtomicSimpleCPU build/ARM/gem5.fast configs/example/fs.py -b cpufreq_test --kernel /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image /home/guru/gem5/gem5-dev/system/disks/android_jb_pa_final.img --machine-type=VExpress_EMM --clock=1GHz --cpu-type=atomic --num-cpus=1 [ 1.769154] Time taken :0.0100000s [ 1.769157] Number :14249 TimingSimpleCPU (with --caches) build/ARM/gem5.fast configs/example/fs.py -b cpufreq_test --kernel /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image /home/guru/gem5/gem5-dev/system/disks/android_jb_pa_final.img --machine-type=VExpress_EMM --clock=1GHz --cpu-type=timing --caches --num-cpus=1 [ 1.925451] Time taken :0.0100010s [ 1.925457] Number :12300 I have also noticed that without --caches, the kernel always computes 32.97 BogoMIPS regardless of the --clock argument specified.. TimingSimpleCPU (without --caches) build/ARM/gem5.fast configs/example/fs.py -b cpufreq_test --kernel /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image /home/guru/gem5/gem5-dev/system/disks/android_jb_pa_final.img --machine-type=VExpress_EMM --clock=1GHz --cpu-type=timing --num-cpus=1 [ 5.286962] Time taken :0.0100310s [ 5.287082] Number :454 In both TimingSimpleCPU configurations, regardless of the --clock parameter specified, the output does not vary much from the specified values. I'm still not sure as to why this is happening.. Any thoughts? Regards On Thu, Jun 6, 2013 at 11:01 AM, Guru Prasad <[email protected]> wrote: > Hi All, > > A small follow-up on this question. > > @Tao Zhang was actually right. > Timing CPU works as 'expected' when I enable caches with it. > > Why I say 'expected' is because, the Linux kernel is still unable to > accurately compute loops per jiffy for the timing model CPU..(it always > computes 997 BogoMIPS) > However, the output seems to now correlate with changes in --clock values > (I don't know if its correct though..what I mean is - higher clock seems to > correspond to more operations executed). > > I have also noticed that without --caches, the kernel always computes 32.7 > BogoMIPS regardless of the --clock argument specified.. > I'm still not sure as to why this is happening.. > > Any thoughts? > > > Regards > Guru > > > > On Mon, Jun 3, 2013 at 10:31 AM, Guru Prasad <[email protected]> wrote: > >> Hello All, >> >> I received clarification from qa.gem5.org( >> http://qa.gem5.org/132/timing-cpu-model) on this issue. >> "The TimingSimpleCPU is a 1 CPI CPU model that uses a timing back-end for >> memory latencies, so it's not surprising that you'd see little change in a >> cpu-bound benchmark when varying the clock. Try running a memory intensive >> benchmark, such as mcf from SPEC, and you should see a difference. If you >> need detailed timing information out of the CPU, use the O3 model." - Tony >> >> Regarding the other questions that I have not responded to, >> >> @Tao Zhang, >> I just never enabled --caches as Gem5 did not complain about it (Gem5 >> does complain about it when trying to use o3 model without caches). >> I was a little doubtful about --cpu-type=detailed..I had questioned this >> earlier as well..My CPU bound benchmark works as intended while using >> arm_detailed with --caches. >> >> @Rehab Massoud, >> The time does make sense, yes. But the last number computed should be >> proportional to the CPU frequency..the higher the frequency, the more >> computations per unit time. However, the timing model was not reflecting >> this..hence my post. >> >> @Andrws Vieira, >> The variable 'Number' is the last number that it tried to test (whether >> it was prime or not). >> >> My primality test function is as follows, >> >> typedef unsigned long long ull; >> static inline int is_prime(int number) { >> >> ull divisor = 3; >> >> if(number == 1ULL ) { >> //1 is neither prime nor composite >> return 0; >> } >> >> if(number % 2 == 0) { >> return 0; //even no. >> } >> >> // Every prime number is of the form 6n (+|-) 1 >> if(number % 6 != 1 || number % 6 != 5) { >> return 1; >> } >> >> while ( divisor <= (number / 2) ) { >> if (number % divisor == 0) { >> return 0; >> } >> divisor += 2; >> } >> return 1; >> } >> >> Below is the pseudo code of my main function >> main(argc, argv) { >> ... >> start_time = get_current_time() >> >> ull number = 1; >> while(1) { >> is_prime(number); >> if( (get_current_time() - start_time) >= end_time //end_time >> part of argv >> break; >> number++; >> } >> } >> >> Thank you for your insights into this issue.. >> >> Regards >> Guru >> >> >> >> On Fri, May 31, 2013 at 6:27 AM, Andrws Vieira <[email protected]>wrote: >> >>> Hello Guru, >>> >>> What is the variable "Nunber" ? >>> >>> >>> []'s >>> >>> >>> 2013/5/31 Rehab Massoud <[email protected]> >>> >>>> Didn't you say that you're running a program that's given a timeout? >>>> The timeout you specify is expected to be the time you got, so your results >>>> make all the sense, isn't it? >>>> On May 31, 2013 8:24 AM, "Guru Prasad" <[email protected]> wrote: >>>> >>>>> Hi Andrws, >>>>> This is the output i obtained running with the configuration mentioned. >>>>> >>>>> 01 GHz >>>>> Time taken :0.1000000s >>>>> Number :189055 >>>>> >>>>> >>>>> 04 GHz >>>>> Time taken :0.1000000s >>>>> Number :392151 >>>>> >>>>> >>>>> 10 GHz >>>>> Time taken :0.1000000s >>>>> Number :472726 >>>>> >>>>> It does seem to correlate with what I would expect to be the output >>>>> with change in frequency. >>>>> >>>>> I will need to test further (or read appropriate documentation) to >>>>> ensure that timing model is actually being used in the command line >>>>> mentioned above. >>>>> >>>>> Thank you for your suggestions. >>>>> >>>>> Regards >>>>> Guru >>>>> >>>>> >>>>> >>>>> On Thu, May 30, 2013 at 2:55 PM, Guru Prasad <[email protected]>wrote: >>>>> >>>>>> Hi Andrws, >>>>>> >>>>>> I'm running the simulations right now.. >>>>>> Could I ask how this makes a difference? >>>>>> >>>>>> Also, (How) is this different from --cpu-type=arm_detailed? >>>>>> >>>>>> This will be my command line..do let me know if there is an issue >>>>>> with it >>>>>> build/ARM/gem5.fast configs/example/fs.py --kernel >>>>>> /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image >>>>>> /home/guru/gem5/gem5-stable/system/disks/android_jb_pa_spec.img >>>>>> --machine-type=VExpress_EMM --clock=1GHz --cpu-type=timing --num-cpus=1 >>>>>> --caches --cpu-type=detailed >>>>>> >>>>>> >>>>>> >>>>>> R >>>>>> egards >>>>>> >>>>>> Guru >>>>>> >>>>>> >>>>>> >>>>>> On Thu, May 30, 2013 at 2:36 PM, Andrws Vieira < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Guru, >>>>>>> >>>>>>> Try to put in the end of command line: *cpu-type=detailed* >>>>>>> * >>>>>>> * >>>>>>> Like this -> build/ARM/gem5.fast configs/example/fs.py --kernel >>>>>>> /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image >>>>>>> /home/guru/gem5/gem5-stable/system/disks/android_jb_pa_spec.img >>>>>>> --machine-type=VExpress_EMM --clock=4GHz --cpu-type=timing --num-cpus=1 >>>>>>> -- >>>>>>> *cpu-type=detailed* >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> []'s >>>>>>> >>>>>>> >>>>>>> 2013/5/30 Guru Prasad <[email protected]> >>>>>>> >>>>>>>> Here are some results >>>>>>>> >>>>>>>> Atomic >>>>>>>> 01 GHz >>>>>>>> Time taken :0.1000006s >>>>>>>> Number :142617 >>>>>>>> >>>>>>>> 04 GHz >>>>>>>> Time taken :0.1000003s >>>>>>>> Number :575327 >>>>>>>> >>>>>>>> 10 GHz >>>>>>>> Time taken :0.1000003s >>>>>>>> Number :1428815 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Timing >>>>>>>> 01 GHz >>>>>>>> Time taken :0.1000310s >>>>>>>> Number :4597 >>>>>>>> >>>>>>>> 04 GHz >>>>>>>> Time taken :0.1000302s >>>>>>>> Number :4657 >>>>>>>> >>>>>>>> 10 GHz >>>>>>>> Time taken :0.1000297s >>>>>>>> Number :4643 >>>>>>>> >>>>>>>> >>>>>>>> Maybe this is how timing is supposed to work..I'm not sure.. >>>>>>>> I just didn't understand it and wanted to ask other users >>>>>>>> >>>>>>>> Regards >>>>>>>> Guru >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, May 30, 2013 at 2:09 PM, Guru Prasad >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi Andreas, >>>>>>>>> >>>>>>>>> The output of my program is the same. >>>>>>>>> I'm running primality test program that is given a time bound. >>>>>>>>> >>>>>>>>> I >>>>>>>>> t returns the last number that it tested when it runs out of time. >>>>>>>>> >>>>>>>>> I would expect the last number computed to differ based on >>>>>>>>> frequency specified while running Gem5. >>>>>>>>> >>>>>>>>> This differs significantly when using both, Atomic model and O3.. >>>>>>>>> But regardless of the --clock parameter, timing model always gives >>>>>>>>> me results that are very close. >>>>>>>>> >>>>>>>>> >>>>>>>>> My command line parameters are >>>>>>>>> >>>>>>>>> build/ARM/gem5.fast configs/example/fs.py --kernel >>>>>>>>> /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image >>>>>>>>> /home/guru/gem5/gem5-stable/system/disks/android_jb_pa_spec.img >>>>>>>>> --machine-type=VExpress_EMM --clock=4GHz --cpu-type=timing >>>>>>>>> --num-cpus=1 >>>>>>>>> >>>>>>>>> I am working with a slightly outdated gem5 source..I believe my >>>>>>>>> revision is 9197 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, May 30, 2013 at 1:57 PM, Andreas Hansson < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Guru, >>>>>>>>>> >>>>>>>>>> Could you perhaps elaborate on "same results"? Are all stats >>>>>>>>>> exactly the same, or is the output of the program the same? Also, >>>>>>>>>> what >>>>>>>>>> config script are you running? >>>>>>>>>> >>>>>>>>>> Andreas >>>>>>>>>> >>>>>>>>>> From: Guru Prasad <[email protected]> >>>>>>>>>> Reply-To: gem5 users mailing list <[email protected]> >>>>>>>>>> Date: Thursday, 30 May 2013 18:45 >>>>>>>>>> To: "[email protected]" <[email protected]>, " >>>>>>>>>> [email protected]" <[email protected]> >>>>>>>>>> Subject: [gem5-users] Timing CPU model >>>>>>>>>> >>>>>>>>>> I was recently running some tests using the timing CPU model >>>>>>>>>> and noticed that my cpu-bound workload was always producing the same >>>>>>>>>> results regardless of the --clock parameter specified. >>>>>>>>>> >>>>>>>>>> I tested this with >>>>>>>>>> --clock=0.1GHz (not sure if floating points work for parameters) >>>>>>>>>> --clock=1GHz >>>>>>>>>> --clock=4GHz >>>>>>>>>> --clock=10GHz >>>>>>>>>> >>>>>>>>>> Could anyone explain to me why this is the case? Is there >>>>>>>>>> something implicit in the timing model that I'm not quite grasping? >>>>>>>>>> >>>>>>>>>> -- 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. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Andrws Aires Vieira * >>>>>>> Mestrando em Computa??o >>>>>>> Universidade Federal do Rio Grande do Sul - UFRGS >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> >>> -- >>> *Andrws Aires Vieira * >>> Mestrando em Computa??o >>> Universidade Federal do Rio Grande do Sul - UFRGS >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://m5sim.org/cgi-bin/mailman/private/gem5-users/attachments/20130606/00b572ed/attachment.html> ------------------------------ _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users End of gem5-users Digest, Vol 83, Issue 18 ******************************************
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
