K-ballo 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/
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
shahrzad has quit [Quit: Leaving]
akheir has quit [Remote host closed the connection]
bita has quit [Ping timeout: 265 seconds]
<gonidelis[m]>
hkaiser: do i need to specify boost and hwloc paths when compiling an hpx app on rostam?
<rori>
depends which versions of those libs you want to use, cmake looks what's in $HWLOC_ROOT and $BOOST_ROOT by defaul
<gnikunj[m]>
aah right. I included an HPX_ASSERT to ensure that the vector of locales that we receive as argument has a size greater than 1. Let me fix that real quick.
<hkaiser>
thanks!
<gnikunj[m]>
*greater than 0
<hkaiser>
otherwise it's good to go now
<gnikunj[m]>
yayy!!!
<gnikunj[m]>
hkaiser: done!
<hkaiser>
great!
<hkaiser>
we'll merge it once the tests have cycled
<hkaiser>
mdiers[m]: looks like the future_data went out of scope
<mdiers[m]>
<hkaiser "mdiers: looks like the future_da"> when i track it always comes out of various hpx::for_loop( ... )
<hkaiser>
ok
<hkaiser>
mdiers[m]: I think I have an idea, let me have a look
<mdiers[m]>
hkaiser: an idea sounds great
<ms[m]>
mdiers: are the variables printed inside notify_one or set_value? is it a segfault?
<mdiers[m]>
ms: printed from set_value. for notify_one i need a debug hpx build.
<ms[m]>
hkaiser: mdiers note that l is moved into notify_one so it would be empty until it gets set again after the notify_one call
<mdiers[m]>
<ms[m] "hkaiser: mdiers note that l is m"> ah exactly, thank you
<ms[m]>
hence the question, is it a segfault? or something else?
<mdiers[m]>
it is a segfault, if I remember correctly.
<hkaiser>
mdiers[m]: I'll create a PR, would you be able to try that out for me?
<mdiers[m]>
hkaiser: yes i will do it. i will try to start a debug version to get the infos from notify_one(). but it will take 1 to 2 hours until it fails.
<hkaiser>
mdiers[m]: I don't think this would help us as the future_data is gone already
<mdiers[m]>
hkaiser: Then at least I have access to the entire callstack.
<gonidelis[m]>
Can I use both `std::execution::par` and `hpx::execution::par` in the same program ?
<hkaiser>
gonidelis[m]: I wouldn't suggest you do
<gonidelis[m]>
oh 0.0
<gonidelis[m]>
for some reason when I `import <execution>` it does recognize `hpx::execution`, isn't that weird?
<ms[m]>
gonidelis[m]: are you including any other hpx headers? you're most likely getting `hpx::execution` transitively via something that's not `hpx/execution.hpp`
akheir has joined #ste||ar
<gonidelis[m]>
ms[m]: hpx/algorithm hpx/hpx_main and hpx/iostream
<ms[m]>
gonidelis[m]: yeah, you'll get it at least through the algorithm header, potentially through the others as well
<gonidelis[m]>
that's my hpx headers
<gonidelis[m]>
ok... so then when import <execution> shouldn't I also have the std::execution part?
<hkaiser>
gonidelis[m]: is that for the task bench stuff?
<gonidelis[m]>
even if it's wrong to do so
<hkaiser>
gonidelis[m]: you'll get std::par only in c++17 mode
<gonidelis[m]>
hkaiser: it's for the performance analysis. not task bench specific. just trying to run some parallel algos and compare them with std
<hkaiser>
gonidelis[m]: in this case you need separate executables
<hkaiser>
one for std, one for hpx
<gonidelis[m]>
hkaiser: oh ok...
<gonidelis[m]>
right on
<gonidelis[m]>
hkaiser: am I allowed to use `hpx::ranges::find_if` in the `sequential_remove_if` base implementation?
<hkaiser>
gonidelis[m]: ahh, I expected that question
<gonidelis[m]>
here it comes then ;p
<hkaiser>
gonidelis[m]: so why would you want to use the parallel algorithm for a sequential execution?
<gonidelis[m]>
hkaiser: oh! and how do we cover the case of the user not passing a projection?
<hkaiser>
this is handled on the API level
<gonidelis[m]>
hkaiser: positive
<mdiers[m]>
hkaiser: You are so incredibly fast 😀
<mdiers[m]>
I have taken the changes directly into the installation and started a test. Now I have to wait, because otherwise it took between 10 minutes and 3 hours until the crash. Tomorrow I will report.
<mdiers[m]>
Thank you very much for the incredibly fast help.
<hkaiser>
mdiers[m]: thanks!
<hkaiser>
'm not 100% sure this will fix your issue
<gonidelis[m]>
what do they mean "exposition-only iterator-sentinel-pair" ?
bita has joined #ste||ar
<hkaiser>
gonidelis[m]: it means that the implementation should expose the concept of an iterator/sentinel pair and not necessarily in the same way as described
<gonidelis[m]>
hkaiser: so it gets more flexible?
<gonidelis[m]>
`*first++ = std::move(*i);`
<gonidelis[m]>
what's the purpose of first++ in the left side of the assignment operator
<gonidelis[m]>
is it possible to just split into two lines like:
<gonidelis[m]>
`*first = std::move(*i);`
<gonidelis[m]>
`*first++`
<gonidelis[m]>
?
<gonidelis[m]>
I get that the left operand can't be an rvalue and I suppose it's an rvalue because it's pointer direference
<gonidelis[m]>
dereference*
<gonidelis[m]>
k-ballo: ^^
akheir has quit [Quit: Leaving]
<hkaiser>
gonidelis[m]: you can split it for sure: *first = ...; ++first;
<hkaiser>
but why would you?
<gonidelis[m]>
Yy I thought it would help
<gonidelis[m]>
I get an error
<gonidelis[m]>
"Left operand required to be an lvalue"
<gonidelis[m]>
I don't get it
<gonidelis[m]>
hkaiser it's copy paste from cpp ref