-
I have been attempting some benchmarking of using GeophysicalFlows
using BenchmarkTools
nlayers = 2
dev = CPU()
println("Number of layers: "*string(nlayers))
prob = MultiLayerQG.Problem(nlayers, dev)
@btime stepforward!(prob) I'm seeing a general increase in runtime with number of threads after around 4-8, though (see output below). Could this be due to some known bottleneck? I've tried the same with 10 layers and also with Number of layers: 2
13.258 ms (241 allocations: 16.61 KiB)
[ Info: FourierFlows will use 2 threads
Number of layers: 2
9.174 ms (23537 allocations: 2.07 MiB)
[ Info: FourierFlows will use 4 threads
Number of layers: 2
10.010 ms (23537 allocations: 2.07 MiB)
[ Info: FourierFlows will use 8 threads
Number of layers: 2
11.386 ms (23537 allocations: 2.07 MiB)
[ Info: FourierFlows will use 16 threads
Number of layers: 2
13.705 ms (23537 allocations: 2.07 MiB)
[ Info: FourierFlows will use 32 threads
Number of layers: 2
19.538 ms (23537 allocations: 2.07 MiB)
[ Info: FourierFlows will use 64 threads
Number of layers: 2
27.591 ms (23537 allocations: 2.07 MiB) |
Beta Was this translation helpful? Give feedback.
Answered by
glwagner
Jun 19, 2024
Replies: 1 comment 3 replies
-
Threads have overhead so its expected that there will be problem sizes where increasing thread count no longer produces a speed up. But maybe the problem is too small for that? |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So the result you are looking for is to find the optimal number of threads, and to find that the optimal number of threads increases for bigger problems. That would indicate things are working as expected...