Closed ranocha closed 3 years ago
In GitLab by @ranocha on May 18, 2020, 16:29
changed the description
In GitLab by @sloede on May 20, 2020, 10:08
So what exactly is your suggestion what we should do? So far, Gregor's and my perspective on this was that we do not want to sprinkle the code with @inbounds
statements as it makes it harder to read, understand, and sometimes modify. Instead, whenever we run a performance-critical simulation, we restart Julia anyways to enable threading and can then also supply --check-bounds=no
.
In GitLab by @ranocha on May 20, 2020, 10:09
That's also okay for me (for now).
What do you mean by "restart Julia anyways to enable threading"?
In GitLab by @sloede on May 20, 2020, 10:31
By default, I (we?) do not have JULIA_NUM_THREADS
set, thus Threads.nthreads() == 1
. Personally, I only enable threading when I know I have a longer-running simulation.
In GitLab by @ranocha on May 20, 2020, 10:32
Okay, thanks for the info. I just have JULIA_NUM_THREADS
set to the number of CPU cores on my machine by default.
Superseded by #210
In GitLab by @ranocha on May 18, 2020, 16:25
By default, Julia checks bounds for every index operation into arrays. It is possible to tell Julia "Hey, I know this will be safe" by using
@inbounds
after an initial boundschek has been done by something along the lines ofIt is also possible to disable bound checks entirely by calling
julia --check-bounds=no
. On the other hand, it is possible to enforce bound checks by callingjulia --check-bounds=yes
, which might be nice for tests.Without disabling boundschecks, further optimizations such as SIMD cannot be performed in general.
An initial test starting from !43 yields
for the current behavior for
examples/parameters_ec_longrun.toml
andwith
julia --check-bounds=no
. That's a performance difference of ca. 20%.