Xdata. If I increase its length by a factor of ten, then the times I get will be larger by that factor as well, but TU will still be zero.
|While the cluster seems to be faster than my laptop, the numbers for TG imply a factor of 3. Why does TU evaluate to 0?|
high_resolution_clockis supposed to be the clock with the highest resolution (shortest tick period), but I don't think there is a guarantee on what the resolution (tick period) actually is on a specific system:
system_clockmight be affected when the clock on your computer is adjusted.
|The high_resolution_clock is not implemented consistently across different standard library implementations, and its use should be avoided. It is often just an alias for std::chrono::steady_clock or std::chrono::system_clock, but which one it is depends on the library or configuration. When it is a system_clock, it is not monotonic (e.g., the time can go backwards). For example, for gcc's libstdc++ it is system_clock, for MSVC it is steady_clock, and for clang's libc++ it depends on configuration.|
Generally one should just use std::chrono::steady_clock or std::chrono::system_clock directly instead of std::chrono::high_resolution_clock: use steady_clock for duration measurements, and system_clock for wall-clock time.
|TG = 27,000 ms|
TU = 14,000 ms
get_noisy_force_GM( )is a simple structure consisting of two
|When it's not a factor but 18ms faster then you will have 0 in case of 14ms.|
|In Python, this would be trivial..|
|Because Python code is not optimized as aggressively?|
|python makes everything easier. It typically runs between 3 and 10(!!) times slower than half decent c++ depending on what you are doing.|
get_noisy_force_GM()function from above, which dominates the workload in a single iteration.
U_pot_GM()in each iteration, and both of them dominate the workload per iteration.
U_pot_GM()was twice as costly as
get_noisy_force_GM(), the number of iterations in method B should be three times lower than in method A.
chronoclocks to measure the elapsed time in each iteration, and stop the iterations when the total elapsed time reaches the given admissible execution time. That would tie in with what @jonnin recommended, focussing on measuring the times used in an "in practice" run.
Or, if you want to know how many of each one you can do in X time
count # of iterations with the loop counters or whatever.