Cool VL Viewer forum http://sldev.free.fr/forum/ |
|
Improving LLVCacheLRU::updateScores() with OpenMP http://sldev.free.fr/forum/viewtopic.php?f=10&t=2070 |
Page 1 of 1 |
Author: | kathrine [ 2020-10-03 14:30:25 ] | |||||||||
Post subject: | Improving LLVCacheLRU::updateScores() with OpenMP | |||||||||
Hi Henri, i ran the Visual Studio Profiler on a viewer run and found that updateScores() eats around 5% CPU time. It can be parallelized quite simple with OpenMP, as illustrated below (use /openmp with VisualStudio). Are you interested in a proper patch for this?
|
Author: | Henri Beauchamp [ 2020-10-03 14:51:26 ] | |||||||||||||||||||||||||||
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP | |||||||||||||||||||||||||||
|
Author: | kathrine [ 2020-10-03 15:12:21 ] |
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP |
Ok, that might explain a bit. I profiled for an hour and that part was when jumping to HBC with lots of AVs around and a clean cache, so lots of texture fetches etc. Will have a look at some more quiet spots, but the threading optimization looks useful anyway. Its a bit sad VC only has openmp 2.0, but better than nothing for a start. Thats actually the reason for that int64_t stuff, as VC cannot simply use the iterators there. |
Author: | Henri Beauchamp [ 2020-10-03 16:34:38 ] | ||
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP | ||
OK, reusing my former OpenMP tests, I came up with the attached patch (to apply to the experimental branch sources) which should allow compiling your proposed code for Linux, Windows and even macOS (for Windows and macOS, uncomment "#set(OPENMP ON)" in indra/cmake/00-BuildOptions.cmake, and for Linux simply add the "-o" option to the buildlinux.sh command line). Sadly, the result under Linux (with gcc 10.2.0 as the compiler) is a hanging mesh repository (it stays stuck forever when it attempts the first mesh cache optimization)... You may review the patch to see if I made any mistake, but aside from the cmake/linking stuff, and a couple minor changes (coding standard-related), it's the code you posted here. There might be some issue with threading (the mesh repository being itself a thread: not too sure how OpenMP deals with threads under Linux; I'd have to investigate). EDIT: same results when compiling with llvm/clang 10.0.1.
|
Author: | kathrine [ 2020-10-03 18:05:08 ] |
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP |
Will have a look. Probably messed something up on my side. Kathrine |
Author: | Henri Beauchamp [ 2020-10-03 19:43:53 ] | |||||||||
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP | |||||||||
Also, regarding this particular mesh optimizing method, I don't think the result you got while benchmarking it is very relevant (at least on multi-core CPUs). Why ? Because you apparently (if I understood correctly what you wrote) measured the CPU load, but not the relative time slice it takes in the main thread (which would be close to zero and only the cause of mutex locks overhead and such, since this method is called from the mesh repository thread). On a mono-core CPU, your "5%" would definitely be a relevant measure and would deserve optimization, but on a multi-core CPU and considering this method is called in a child thread, it does not really impact the main thread loop run time (i.e. the rendering itself, the objects list and UI refreshes, plus all the sundry synchronization tasks between threads). Granted, spreading the mesh optimization on more cores would definitely lower the rezzing time of meshes (so your work is not at all useless), even if by a small amount (relatively to the download time of the said meshes). I do not know how the VS profiler works, but if possible, it would be worth running it only on the main viewer thread to highlight the hot spots that do count for the user. |
Author: | kathrine [ 2020-10-03 20:52:00 ] | |||||||||
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP | |||||||||
Yeah, maybe not worth it, as it is not on the main loop. But faster rezzing is nice too, if it works out. It seems i messed up my cut© and got an older broken version. This one actually works and does something useful.
|
Author: | Henri Beauchamp [ 2020-10-03 21:58:46 ] | |||||||||
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP | |||||||||
Got a magnificent crash under Linux with this version:
I still got the feeling that threading via OpenMP within a pthread thread is "wrong" (under Linux... or macOS !)... Probably a pthread reentrancy issue (as you can see in the stack trace, two pthread calls get nested). EDIT: just found the answer confirming my inference on OpenMP forum. So, sadly, I must reject this patch. |
Author: | kathrine [ 2020-10-04 08:36:52 ] |
Post subject: | Re: Improving LLVCacheLRU::updateScores() with OpenMP |
Ah well, happens. Maybe my next patch will work better. |
Page 1 of 1 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |