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/
hkaiser has quit [Quit: bye]
diehlpk_work has quit [Remote host closed the connection]
peltonp1 has joined #ste||ar
<peltonp1>
is there a way to call hpx::future::get() twice such that blocking happens only on the first call?
<peltonp1>
Im writing stencil code and for a two-dimensional domain I have boundary data comming from left,right,up and down neighbouring localities
<peltonp1>
the solution of the 'up' boundary depends on left, up and right boundaries whereas the solution of 'left' boundary depends on up, left and down boundaries
<peltonp1>
therefore I'm looking for some elegant way to collect all incoming data into a vector of futures which I would then index and call the proper get from the future depending on whether the data has already been communicated or not. The non-communicated get should be non-blocking.
<peltonp1>
how would you approach this problem?
<ms[m]>
peltonp1: a (subset) of future::wait and shared_future may help you
<ms[m]>
shared_future lets you get the value multiple times but only gives you const references to the value
<ms[m]>
I guess I could add future::valid to the list as well (if you're fine with getting the data once and the next get possibly not giving you a value)
<peltonp1>
I think the shared future is the way to go here as the data is actually _shared_ by multiple boundaries
<peltonp1>
thanks a lot
rachitt_shah[m] has quit [Ping timeout: 245 seconds]
klaus[m] has quit [Ping timeout: 245 seconds]
sestro[m] has quit [Ping timeout: 245 seconds]
pedro_barbosa[m] has quit [Ping timeout: 245 seconds]
rachitt_shah[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
sestro[m] has joined #ste||ar
klaus[m] has joined #ste||ar
k-ballo[m] has quit [Quit: Idle for 30+ days]
<gonidelis[m]>
ms[m]: gnikunj[m] 1-4 grading means 1 is the best and 4 is the worst?
<ms[m]>
gonidelis[m]: it's just a ranking, so yes
<gonidelis[m]>
i thought it was grading
<gonidelis[m]>
nice
k-ballo[m] has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser>
gonidelis[m]: yt
<gonidelis[m]>
yes
<gonidelis[m]>
hkaiser: ^^
<hkaiser>
see pm , pls
Coldblackice has joined #ste||ar
Coldblackice has quit [Read error: Connection reset by peer]
Coldblackice has joined #ste||ar
Coldblackice has quit [Read error: Connection reset by peer]
<hkaiser>
ms[m]: I like #5329!
<hkaiser>
very nice
<ms[m]>
hkaiser: good :D it's more or less my interpretation of what we discussed with lee on the mailing list, I take it you see it roughly the same then?
<hkaiser>
yes - this is beautifully simple and yet powerful
<ms[m]>
hkaiser: no, it doesn't, which is why something like that would need to be added
<hkaiser>
nod
<hkaiser>
but we could use WARNINGS_AS_ERRORS at the interface for our add_hpx_config_test()
<ms[m]>
srinivasyadav227: at least based on K-ballo's earlier comment about not all config tests compiling with -Werror it should be an option so that not all config tests have -Werror
<srinivasyadav227>
ms: yes, ok, i will try it
<ms[m]>
hkaiser: yeah, that's what I was thinking of as well
<ms[m]>
you could of course see what happens if you try to add -Werror to all the config tests
<srinivasyadav227>
hkaiser: cool :) , thanks a lot
<K-ballo>
if having -Werror for all config tests is viable, all the better
<hkaiser>
K-ballo: yes
<hkaiser>
ms[m]: you mentioned a discussion on some mailing list, which one was that?
nanmiao has joined #ste||ar
<ms[m]>
hkaiser: isocpp-parallel; it's the discussion that followed from the message that I first sent to you, auriane, and john
<hkaiser>
ms[m]: ok
<ms[m]>
somewhat disappointed in the turnout, but at least I got some answers
<hkaiser>
nod, the executors thrust has run out of steam
<ms[m]>
hkaiser: thanks for starting 5332; I'll need some time to go through it properly
<hkaiser>
ms[m]: sure
<hkaiser>
ms[m]: yah, #5332 is not ready yet, it doesn't properly work yet - but any ideas would be appreciated
nanmiao has quit [Quit: Connection closed]
<srinivasyadav227>
hkaiser: aah..finally i got :), `-Werror` or `${additional_cmake_flags}` should be added to`"-DCOMPILE_DEFINITIONS=${CONFIG_TEST_COMPILE_DEFINITIONS}` so replacing it to `"-DCOMPILE_DEFINITIONS=${CONFIG_TEST_COMPILE_DEFINITIONS} ${additional_cmake_flags}"` worked
<hkaiser>
srinivasyadav227: good!
<K-ballo>
not compile definitions, flags
<K-ballo>
is COMPILE_DEFINITIONS even a well-known cmake variable? or is it context specific?
<K-ballo>
add_definitions is for definitions, -D flags, using it for other things only works because compilers just merge them with flags
<K-ballo>
> COMPILE_DEFINITIONS <defs>...: Specify -Ddefinition arguments to pass to add_definitions() in the generated test project.
<K-ballo>
although looking at the AddConfigTest code, it's not even passing that parameter, just setting a randomly named cmake variable
<srinivasyadav227>
is try_compile(..., CMAKE_FLAG "-DCOMPILE_DEFINITIONS=${CONFIG_TEST_COMPILE_DEFINITIONS}" )different from try_compile(..., COMPILE_DEFINITIONS) ?
<K-ballo>
yes
<K-ballo>
try_compile must be transforming the real COMPILE_DEFINITIONS argument into a -DCOMP.. flag internally, for things to actually be working
<K-ballo>
indeed, that's what's its doing, the generated source has `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMPILE_DEFINITIONS}")`, which is why all this works
<srinivasyadav227>
oh k,,,then is it correct?
<K-ballo>
no, it just accidentally works
<srinivasyadav227>
oh ok,,then its a bug with cmake?
<K-ballo>
three wrongs don't make a right :P
<K-ballo>
no, with our use of it
<K-ballo>
we are relying on internal implementation details
<K-ballo>
doesn't try_compile just pick the value in scope for CMAKE_CXX_FLAGS ?
<srinivasyadav227>
oh ok.. ;), do you any other solution for this?
<srinivasyadav227>
i tried passing "-DCMAKE_CXX_FLAGS=-Werror" to CMAKE_FLAG , but didnt not work
<K-ballo>
try set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror") right before try_compile
<srinivasyadav227>
ok, one min
<K-ballo>
CMAKE_CXX_FLAGS is not supposed to be set via -D, it's just yet another thing that happens to work most of the time because everything ends up being mixed together internally
<srinivasyadav227>
<K-ballo "try set(CMAKE_CXX_FLAGS "${CMAKE"> this worked! ;)
<K-ballo>
fix the bad COMPILE_DEFINITION passing while you are at it
<srinivasyadav227>
<K-ballo "fix the bad COMPILE_DEFINITION p"> i didnt get this!, can you elaborate it please :)
<K-ballo>
COMPILE_DEFINITIONS is an argument of try_compile
<K-ballo>
the code isn't setting it, but instead passing -DCOMPILE_DEFITIONS=... to the CMAKE_FLAGS argument
<K-ballo>
something is not quite right with those calls
<K-ballo>
nevermind, LINK_LIBRARIES has two forms, nasty
<srinivasyadav227>
just adding set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror") right before try_compile worked, i didnt touch any CMAKE_FLAG with this change and it worked,, so is this change sufficient and correct?
<K-ballo>
that change will have that try_compile call use -Werror flag for cxx targets
<K-ballo>
and any other calls in scope after it
<K-ballo>
probably not sufficient, I'd imagine you'd want the same for try_run
<K-ballo>
plus both try_run and try_compile "-DCOMPILE_DEFINITIONS..." are bogus, and need to be corrected
<srinivasyadav227>
ok, whats the right way to pass -Werror to specific targets only?
<K-ballo>
no such thing
<K-ballo>
what do you mean by "targets"?
<K-ballo>
try_run/try_compile build a distinct cmake project on the side
<srinivasyadav227>
try_run/try_compile
<K-ballo>
those aren't targets
<K-ballo>
in the basic source mode, try_run/try_compile will create a new cmake project with just the one target
<K-ballo>
so using -Werror for all its targets or for a specific target only would not make any difference
<srinivasyadav227>
ok, wait,,,i am confused a lot now, sorry :), would adding `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror")` right before both try_run and try_compile a right solution?
<K-ballo>
probably
<srinivasyadav227>
in summary there are two problems 1. if i need to pass -Werror then adding `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror")` before try_run and try_compile solves the issue. 2. existing COMPILE_DEFINITION needs fix?
<srinivasyadav227>
is this understanding correct?
<K-ballo>
yes
<srinivasyadav227>
ok, for the second problem, instead of `CMAKE_FLAG DCOMPILE_DEFINITIONS=${CONFIG_TEST_COMPILE_DEFINITIONS}` it should be passed like an argument to try_compile as `try compile(... COMPILE_DEFINITIONS ${COMPILE_DEFINITIONS} ...)` ?
<srinivasyadav227>
ok now both are solutions are correct ;) ?
<srinivasyadav227>
i mean solutions to both problems
<K-ballo>
should be.. try it out
<srinivasyadav227>
ok
peltonp1 has quit [Quit: Lost terminal]
jehelset has joined #ste||ar
jaafar has quit [Ping timeout: 245 seconds]
jehelset has quit [Remote host closed the connection]
<K-ballo>
hkaiser: why are there 3 tag invoke implementations?
<hkaiser>
K-ballo: one is the straight tag_invoke
<hkaiser>
K-ballo: one has a built-in fallback (tag_fallback_invoke)
<hkaiser>
K-ballo: and one does 3 levels of dispatch
<K-ballo>
... but why??
<hkaiser>
why not ;-)
<hkaiser>
seriously - this helps disambiguating overloads
<hkaiser>
for instance
<hkaiser>
having a base-implementation using tag_fallback, adding overloads for that CPO is easy and does not require changes to the base implementation if the new overload uses tag_invoke
<hkaiser>
otherwise the base implementaton might need to SFINAE out the overload
<K-ballo>
I don't understand... plain tag_invoke as proposed had built-in fallback support
<hkaiser>
does it?
<K-ballo>
that's the whole point
<K-ballo>
user can customize the customization point
<hkaiser>
ok, then I miss something
<K-ballo>
if the user doesn't customize, the base can provide a defualt or reject
<K-ballo>
the goal of tag_invoke is to enable user customization
<hkaiser>
indeed
<hkaiser>
I might miss the forest for the trees here
<hkaiser>
can you show me what you mean?
<K-ballo>
why would you want a third level (or second if we ignore fallback)?
<K-ballo>
btw the base void tag_invoke(); is a poison pill, ought to be =delete;d (and required for gcc/clang too)
<K-ballo>
it prevents ordinary lookup
<hkaiser>
ok
<hkaiser>
well, I don't think this prevents ordinary lookup, and it works for gcc without it
<K-ballo>
it doesn't prevent ordinary lookup, but it's the only tag_invoke overload that is supposed to be in scope anyways and it is deleted so if chosen will make overload resolution fail
<K-ballo>
it prevents the compiler from going up and looking into other tag_invoke overloads visible to ordinary lookup
<hkaiser>
ok
<K-ballo>
without it, compiler would ocassionaly mis-dispatch a call that ought to have been rejected
<hkaiser>
ok, the the changes I have in 5332 currently are not correct - will revisit
<K-ballo>
that makes the only viable overloads the actual customizations (via adl) and the fallback (via class namespace)
<hkaiser>
so specializations are supposed to be in a different namespace? always?
<K-ballo>
not necessarily a different namespace, just an ADL namespace
<K-ballo>
the tag_invoke itself is in a separate namespace, so nothing else should be in there anyhow
<hkaiser>
so why did we run into ambiguities when doing that?
<K-ballo>
I'm not familiar with that context
<hkaiser>
ok, let me try to craft an example
<K-ballo>
the underling dispatch mechanism is essentially the same from eric's cpo paper
<K-ballo>
fwiw lacking a poison pill could have lead to ambiguities
<K-ballo>
I guess since the dispatch call always has at least 1 argument (the tag itself), void tag_invoke(); without delete is enough as it won't be viable
<K-ballo>
something like void tag_invoke(...) = delete; may produce better error messages, needs experimentation
<hkaiser>
hmm, I can't reproduce the ambiguities, need more time