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. 


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.

Reply via email to