Re: [gem5-users] Sources of In-determinism in Full System Simulators
One possible source is if your benchmark interacts with the host through a system call that returns a non-deterministic result. You could try running with the SyscallVerbose debug flag to see what syscalls it is making. Steve On Sat, Aug 15, 2015 at 6:53 PM Prathap Kolakkampadath kvprat...@gmail.com wrote: I am observing this behaviour with a synthetic benchmark(Nonlinear Predictive Control). I am not sure if this benchmark is adding any kind of randomness. I need to look in to this. I tested with eembc benchmarks, where i don't see any variations with the repeated runs. So as andreas mentioned this must be introduced by this specific benchmark. Thanks Andreas and Steve. On Thu, Aug 13, 2015 at 1:22 PM, Steve Reinhardt ste...@gmail.com wrote: Even with x86 you should be seeing deterministic results. If you are regularly seeing inconsistencies, you can try running two copies with debug tracing (I suggest Exec,ExecMacro,Cache as a starting set of flags) and comparing their output with util/tracdiff to see where they diverge. Steve On Thu, Aug 13, 2015 at 9:44 AM Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, That sounds very odd and should not happen unless the workload itself is somehow random. What is it you are running? Are you sure you’re running exactly the same thing? If it does indeed vary then it would be good if you can track down why by running two simulations in lock-step and determining where they diverge. We regularly run the ARM regressions with UBSan to ensure there is no undefined behaviour in the simulator. I know that for X86 there are quite a few warnings from UBSan, so that could be a reason if you’re using x86. Andreas From: gem5-users gem5-users-boun...@gem5.org on behalf of Prathap Kolakkampadath kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Thursday, 13 August 2015 09:11 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] Sources of In-determinism in Full System Simulators Hello User, I am running a benchmark in gem5 full system mode. Checkpoint is created in atomic mode and then switches to detailed mode before starting the benchmark. On repeated runs of the benchmark from same checkpoint, the number of memory requests arriving at DRAM banks differs; up-to 5% variation. Can someone point out, what could be the sources of in-determinism? Thanks, Prathap -- 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Sources of In-determinism in Full System Simulators
I am observing this behaviour with a synthetic benchmark(Nonlinear Predictive Control). I am not sure if this benchmark is adding any kind of randomness. I need to look in to this. I tested with eembc benchmarks, where i don't see any variations with the repeated runs. So as andreas mentioned this must be introduced by this specific benchmark. Thanks Andreas and Steve. On Thu, Aug 13, 2015 at 1:22 PM, Steve Reinhardt ste...@gmail.com wrote: Even with x86 you should be seeing deterministic results. If you are regularly seeing inconsistencies, you can try running two copies with debug tracing (I suggest Exec,ExecMacro,Cache as a starting set of flags) and comparing their output with util/tracdiff to see where they diverge. Steve On Thu, Aug 13, 2015 at 9:44 AM Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, That sounds very odd and should not happen unless the workload itself is somehow random. What is it you are running? Are you sure you’re running exactly the same thing? If it does indeed vary then it would be good if you can track down why by running two simulations in lock-step and determining where they diverge. We regularly run the ARM regressions with UBSan to ensure there is no undefined behaviour in the simulator. I know that for X86 there are quite a few warnings from UBSan, so that could be a reason if you’re using x86. Andreas From: gem5-users gem5-users-boun...@gem5.org on behalf of Prathap Kolakkampadath kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Thursday, 13 August 2015 09:11 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] Sources of In-determinism in Full System Simulators Hello User, I am running a benchmark in gem5 full system mode. Checkpoint is created in atomic mode and then switches to detailed mode before starting the benchmark. On repeated runs of the benchmark from same checkpoint, the number of memory requests arriving at DRAM banks differs; up-to 5% variation. Can someone point out, what could be the sources of in-determinism? Thanks, Prathap -- 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Sources of In-determinism in Full System Simulators
Even with x86 you should be seeing deterministic results. If you are regularly seeing inconsistencies, you can try running two copies with debug tracing (I suggest Exec,ExecMacro,Cache as a starting set of flags) and comparing their output with util/tracdiff to see where they diverge. Steve On Thu, Aug 13, 2015 at 9:44 AM Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, That sounds very odd and should not happen unless the workload itself is somehow random. What is it you are running? Are you sure you’re running exactly the same thing? If it does indeed vary then it would be good if you can track down why by running two simulations in lock-step and determining where they diverge. We regularly run the ARM regressions with UBSan to ensure there is no undefined behaviour in the simulator. I know that for X86 there are quite a few warnings from UBSan, so that could be a reason if you’re using x86. Andreas From: gem5-users gem5-users-boun...@gem5.org on behalf of Prathap Kolakkampadath kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Thursday, 13 August 2015 09:11 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] Sources of In-determinism in Full System Simulators Hello User, I am running a benchmark in gem5 full system mode. Checkpoint is created in atomic mode and then switches to detailed mode before starting the benchmark. On repeated runs of the benchmark from same checkpoint, the number of memory requests arriving at DRAM banks differs; up-to 5% variation. Can someone point out, what could be the sources of in-determinism? Thanks, Prathap -- 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Sources of In-determinism in Full System Simulators
Hi Prathap, That sounds very odd and should not happen unless the workload itself is somehow random. What is it you are running? Are you sure you’re running exactly the same thing? If it does indeed vary then it would be good if you can track down why by running two simulations in lock-step and determining where they diverge. We regularly run the ARM regressions with UBSan to ensure there is no undefined behaviour in the simulator. I know that for X86 there are quite a few warnings from UBSan, so that could be a reason if you’re using x86. Andreas From: gem5-users gem5-users-boun...@gem5.orgmailto:gem5-users-boun...@gem5.org on behalf of Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Thursday, 13 August 2015 09:11 To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] Sources of In-determinism in Full System Simulators Hello User, I am running a benchmark in gem5 full system mode. Checkpoint is created in atomic mode and then switches to detailed mode before starting the benchmark. On repeated runs of the benchmark from same checkpoint, the number of memory requests arriving at DRAM banks differs; up-to 5% variation. Can someone point out, what could be the sources of in-determinism? Thanks, Prathap -- 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Sources of In-determinism in Full System Simulators
Hello User, I am running a benchmark in gem5 full system mode. Checkpoint is created in atomic mode and then switches to detailed mode before starting the benchmark. On repeated runs of the benchmark from same checkpoint, the number of memory requests arriving at DRAM banks differs; up-to 5% variation. Can someone point out, what could be the sources of in-determinism? Thanks, Prathap ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
