On Wednesday, October 3, 2018 at 1:43:40 PM UTC+2, Julien Radoux wrote: > > With the help of my colleague, we found a workaround to the problem. It > seems to be linked with some libraries that force the use of a single > library when it initialize. We did not identify the "guilty" library, but > it seems to be linked with OpenCV. > > Anyway, here is our temporary solution for those who want to make their > own filter with parallel processing (ThreadedGenerateData) > > in the CMakeLists.txt, add the following line just after "project" > > SET(CMAKE_EXE_LINKER_FLAGS "-Wl,--no-undefined -Wl,--as-needed" CACHE > INTERNAL "" FORCE) > > it reduces the chances to load the "guilty" library as it only loads the > one that are usefull. I guess that this is a good practice and many of you > already do it, but we didn't. >
see this doc https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/blob/develop/Modules/IO/TestKernel/test/CMakeLists.txt#L36 > > Le lundi 17 septembre 2018 22:06:29 UTC+2, Julien R a écrit : >> >> Hi Victor, >> >> Thanks for your answer. I've tried it but my problem is that it does not >> fully use the threads (8 thread -> 12.5% on each thread, and I would like >> 100% for each thread) >> >> Le jeudi 13 septembre 2018 11:09:17 UTC+2, Julien R a écrit : >>> >>> We have a few custom filters that use ThreadedGenerate data. We didn't >>> realize immediately, but it seems that the parallel computing is not >>> working properly with our new configuration : >>> >>> openSuse 15.0, OTB 6.7 (git), gcc 7.3.1 >>> >>> When we launch a filter with ThreadedGenerateData, the number of thread >>> is well equal to the number of core (8 threads for 8 cores in my case), >>> but it only uses 1. This is not the case when we use otbcli_applications. >>> >>> Diagnostic: >>> $ taskset -p $(pgrep LWSmoothing) >>> pid 29938's current affinity mask: 1 >>> $ htop # => process total: 100%, 8 sub-processes: 12% >>> >>> If we specify before, it does not change anything >>> $ taskset ff /usr/local/lifewatch/tools/LWSmoothing ... >>> $ taskset -p $(pgrep LWSmoothing) >>> pid 30241's current affinity list: 0 >>> >>> If it specify after, it works as expected (800%) >>> $ taskset -p ff $(pgrep LWSmoothing) >>> pid 30312's current affinity mask: 1 >>> pid 30312's new affinity mask: ff >>> $ htop # => ok, 800% >>> >>> Does anyone have an idea about the reason for this difference ? Is there >>> something to change in the cxx, the txx or in the compiler's configuration ? >>> >>> Thanks, >>> >>> Julien >>> >>> -- -- Check the OTB FAQ at http://www.orfeo-toolbox.org/FAQ.html You received this message because you are subscribed to the Google Groups "otb-users" group. To post to this group, send email to otb-users@googlegroups.com To unsubscribe from this group, send email to otb-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/otb-users?hl=en --- You received this message because you are subscribed to the Google Groups "otb-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
