Closed gforney closed 7 years ago
I just committed a change to the code so that now the output quantity 'CPU TIME'
is the Fortran intrinsic function CPU_TIME
. See how this output compares to 'WALL CLOCK TIME'
.
Thanks!
On Mar 18, 2017 3:52 PM, "Kevin McGrattan" notifications@github.com wrote:
I just committed a change to the code so that now the output quantity 'CPU TIME' is the Fortran intrinsic function CPU_TIME. See how this output compares to 'WALL CLOCK TIME'.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/4840#issuecomment-287570341, or mute the thread https://github.com/notifications/unsubscribe-auth/AL1BRgU0ZUchV1yV2mwWZkLRvnZhh0euks5rnDXvgaJpZM4Mhgmy .
I'm investigating the random openmp warnings we get from blaze firebot runs . I have found that timings seem to be more random on the blaze cluster than the burn cluster. Not sure why yet.
The openmp benchmark cases use the following line to to record timings &DEVC XYZ=0.5,0.5,0.5, QUANTITY='WALL CLOCK TIME ITERATIONS', ID='clock time' /
kevin could you take a look at how hard it would be to add an option to record CPU time, something like
&DEVC XYZ=0.5,0.5,0.5, QUANTITY='CPU CLOCK TIME ITERATIONS', ID='clock time' /
I'm curious to see if this would reduce the random nature of the timings.
In the attached plots, I run the 8 open_mp benchmark cases several times. Each time I plot (wall_clock_time(case_I)/wall_clock_time(case_one) - 0.55) where 'I' is the number of openmp threads I used to run the case. 0.55 is the success criteria. Since we check case 4 (4 threads), positive values indicate failure, negative values indicate success. The fact that the plots are noisy and are close to 0 for case '4' is why the cases fail sometimes and succeed another.
THey question then is why are the plots for the burn cases "tight" but the plots for the blaze cases are random.