hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/ | GSoC2018: https://wp.me/p4pxJf-k1
diehlpk_mobile has quit [Read error: Connection reset by peer]
mcopik has quit [Quit: Leaving]
diehlpk_mobile has joined #ste||ar
diehlpk_mobile has quit [Client Quit]
diehlpk_mobile has joined #ste||ar
diehlpk_mobile has quit [Ping timeout: 256 seconds]
kisaacs has quit [Ping timeout: 264 seconds]
kisaacs has joined #ste||ar
kisaacs has quit [Ping timeout: 260 seconds]
kisaacs has joined #ste||ar
hkaiser has quit [Quit: bye]
jaafar has quit [Ping timeout: 260 seconds]
nanashi55 has quit [Ping timeout: 260 seconds]
nanashi55 has joined #ste||ar
wash has quit [Ping timeout: 256 seconds]
K-ballo has quit [Quit: K-ballo]
wash has joined #ste||ar
wash has quit [Ping timeout: 252 seconds]
wash has joined #ste||ar
galabc has joined #ste||ar
kisaacs has quit [Ping timeout: 256 seconds]
jakub_golinowski has joined #ste||ar
wash has quit [Ping timeout: 245 seconds]
wash has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
parsa has quit [Client Quit]
parsa has joined #ste||ar
parsa has quit [Client Quit]
kisaacs has joined #ste||ar
kisaacs has quit [Ping timeout: 252 seconds]
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
galabc has quit [Ping timeout: 260 seconds]
ksajdh has joined #ste||ar
ksajdh has quit [Client Quit]
<M-ms>
Hey jakub_golinowski, been reading the logs, how is it going for you now? Did you overcome the worst problems with cmake?
<jakub_golinowski>
so yes, the important thing is that hpx is recompiled with c++11 enforced and I deleted any changes that included tinkering with c++ standard of opencv because changing it was breaking opencv
<M-ms>
jakub_golinowski: looks good, regarding setting num threads for hpx it basically does not apply for your initial implementation
<M-ms>
since we're assuming the user already has started the hpx runtime and is calling opencv from within hpx
<jakub_golinowski>
you mean the TODO from the paralle.cpp?
<M-ms>
yea
<M-ms>
h
<jakub_golinowski>
but it has to be handled properly in the end I think because the expected behaviour is that when user calls sth like cv::setNumThreads(1) then it should switch off the parallelism
<jakub_golinowski>
I am not sure but maybe it already works like this
<M-ms>
maybe, it looks like at least gcd and winrt ignore the number of threads in setNumThreads, but it may be that they take into account elsewhere
<M-ms>
the opencv people should hopefully be able to tell you if they have a strict convention on what to do with setNumThreads or if it's backend specific and can be ignore
<M-ms>
d
<M-ms>
what may be possible to use later is an executor that restricts work to a few cores
<jakub_golinowski>
so the numThreads is taken into account before the specific framework is chosen, in this sense: