You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we are still chasing performance over here at RISE and I think we have spotted a part of the afserver code that can potentially be mutli-threaded easily.
I am talking about the for-loop in the hasTickets function over here:
Hello, Oli!
If most time solving finds out tickets and this is read-only function, we can try to slit solving on reading and writing sections. Launch several threads to solve (for the entire solve and to read and to write) and block writing secions to run only by thie one thread at the same time. Yes, this is the easiest way, i think.
we have just tried using OpenMP to multithread the hasTickets function but it seems that the overhead of spawning new threads is bigger than the benefit that the multi-threading would give.
Another solution could be a thread-pool to mitigate the overhead of frequent thread creation and destruction, especially with small task sizes.
Hey Timur,
we are still chasing performance over here at RISE and I think we have spotted a part of the afserver code that can potentially be mutli-threaded easily.
I am talking about the for-loop in the hasTickets function over here:
cgru/afanasy/src/server/renderaf.cpp
Line 801 in a1b60c5
This is one of the largest bottlenecks in the performance analysis from @sebastianelsner in #592
what do you think?
cheers
Oli
The text was updated successfully, but these errors were encountered: