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/
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
jehelset has quit [Remote host closed the connection]
diehlpk_work has quit [Ping timeout: 250 seconds]
<rachitt_shah[m]> <gsodaspirant "Hello, Is the 2021 GSOD position"> You need to fill this form for GSoD
<gnikunj[m]> ms: yt?
<gnikunj[m]> never mind. I think I've got it.
<ms[m]> gnikunj: anything worth mentioning even if you got it?
<gnikunj[m]> ms: I wanted to know more about when kokkos parallel dispatch is asynchronous and when it's not. Second, if kokkos::fence is a glabal barrier on all execution spaces. Found about instance.fence() method to circumvent that.
<ms[m]> gnikunj: ok, yep, that's indeed what you want
<ms[m]> I think all scans and reductions are synchronous if the reduction/scan output is not a view, but otherwise they can be asynchronous (obviously they don't have to be)
<gnikunj[m]> got it!
<gonidelis[m]> ms[m]: about the directories thing again.
<gonidelis[m]> when i create the `include/hpx/iterator_support/tests` path under `libs/core/iterator_support/tests/`
<gonidelis[m]> Does providing just a CMakeLists.txt on the bottom `/tests` dir will be sufficient?
<ms[m]> there probably already is one? and what do you mean by sufficient? an empty file is not sufficient, no, you'll still need to create the target inside that cmakelists.txt
<gonidelis[m]> ms[m]: there is not include directory under `libs/core/iter_support/tests/`
<gonidelis[m]> no^^
<gonidelis[m]> by "sufficient", I meant if othe CMakeLists should be added in between
<ms[m]> but there is a cmakelists.txt in libs/core/iterator_support/tests, right?
<ms[m]> that is sufficient
<ms[m]> (if a target is created in there)
<ms[m]> the cmakelists.txt is processed if someone calls add_subdirectory on the directory where that cmakelists.txt is located, which we do for the tests directory (there are probably some exceptions, but generally we do that)
<gonidelis[m]> ohhh okk!!! thank you. I am still figuring out the CMake machinery
jaafar has quit [Ping timeout: 250 seconds]
<gonidelis[m]> What's HPX header tests?
<gonidelis[m]> i am referring to the `HPX_WITH_TESTS_HEADERS` option
<gonidelis[m]> <ms[m] "there probably already is one? a"> you mean inside that one ? https://github.com/STEllAR-GROUP/hpx/blob/master/libs/core/iterator_support/tests/CMakeLists.txt
questz has joined #ste||ar
questz has quit [Client Quit]
<ms[m]> gonidelis[m]: yep, inside that one
<gonidelis[m]> ms[m]: that's pretty much what i did
<gonidelis[m]> but i reckon i am missing a CMakeLists somewhere in that green tree
<ms[m]> header tests check that headers don't depend on some other file including headers that that particular header requires
<gonidelis[m]> hm ok
<ms[m]> gonidelis[m]: that sounds like you tried it but it doesn't work?
<gonidelis[m]> yes
<gonidelis[m]> but i just saw your message that i should actually create a target in that file
<gonidelis[m]> while I only added the subdir
<gonidelis[m]> but then again
<gonidelis[m]> it's just a header and there is already a pseudo_target creation in there
<ms[m]> do you understand what the target that you would create is for/supposed to do?
<gonidelis[m]> ahh no. i do not, because i cannot figure out how we create a target from a single header
<gonidelis[m]> I get the case where i would just link the header in a cmake-for to each and every test-target
<gonidelis[m]> but a header-target... that I cannot comprehend
<ms[m]> gonidelis[m]: do you know about interface targets?
<gonidelis[m]> ms[m]: kind of
<gonidelis[m]> when i googled i only found interface libraries
<ms[m]> uh, yeah, interface libraries/targets
<gonidelis[m]> which afaiu is a library target which does not have source files?
<ms[m]> add_library(INTERFACE ...), whatever they're officially called
<gonidelis[m]> where source files = .cpp
<gonidelis[m]> so it's exactly what I was asking for? A target created by headers?
<ms[m]> yep, it doesn't need to be compiled, but it still provides interface compile options, definitions, include directories
<gonidelis[m]> oh! so in the cmakelists i sent above, i just add a `add_library(iter_sent_lib INTERFACE) \ target_include_directories(iter_sent_lib INTERFACE include/)`
<ms[m]> yep, exactly (modulo the target name)
<gonidelis[m]> modulo?
<ms[m]> except for
<gonidelis[m]> oh ok... you mean a more proper one
<ms[m]> I'd add test somewhere in the name, to make it clear that it exposes headers meant for tests, not for the main libraries/modules
<gonidelis[m]> yy ok
<gonidelis[m]> although it's in the `if(HPX_WITH_TESTS)
<gonidelis[m]> if(HPX_WITH_TESTS_UNIT)
<gonidelis[m]> ` thing
<ms[m]> probably best to put it just inside if(HPX_WITH_TESTS), not the unit tests part
<ms[m]> might be used byr regression tests/benchmarks as well?
<gonidelis[m]> crystal clear
<gonidelis[m]> shouldn't i link it too?
<ms[m]> gonidelis[m]: yes
<gonidelis[m]> not in the same CMake I guess
<gonidelis[m]> `target_link_libraries` on the tests cmake is an option but i think you are suggesting something higher-level-ish here
<ms[m]> you would do target_link_libraries(test_that_needs_iter_sent_header PRIVATE iter_sent_test_target)
<ms[m]> the add_hpx_test function also has a DEPENDENCIES keyword, which can take the iter_sent_test_target
<gonidelis[m]> aahhhh thanks so much mikael. good indication that someone needs to sharpen their cmake skills
K-ballo has joined #ste||ar
jehelset has joined #ste||ar
hkaiser has joined #ste||ar
diehlpk_work has joined #ste||ar
hkaiser has quit [Ping timeout: 245 seconds]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 252 seconds]
K-ballo1 is now known as K-ballo
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
<gnikunj[m]> ms: what do I do when I start getting segmentation fault due to failure of calling Kokkos::Cuda::finalize()? The code literally ran yesterday!
<K-ballo> we must have entered a new moon phase today
<gnikunj[m]> K-ballo: that explains it, yes!
<K-ballo> we actually did
<gnikunj[m]> lol
<gnikunj[m]> now I'm reconsidering your statement :P
<gnikunj[m]> ms: (I'm still using the same cluster node that I use for any performance benchmark on hpx-kokkos-resilience stuff. Also, the code runs on my laptop)
hkaiser has joined #ste||ar
<ms[m]> gnikunj: you check where the segfault is coming from (not just kokkos::finalize, but literally what line of code), and check that you're not maybe calling kokkos::finalize too early maybe (i.e. before all kokkos work is done)? without more details it's hard to give more advice
<ms[m]> or you've recompiled something/changed your environment and it's linking to the wrong libraries (unlikely though, since kokkos is typically statically linked)
<gnikunj[m]> I'm currently reinstalling everything to check if it has to do anything. I'm surprised that the codes ran until last I did performance benchmarking. The only change that I have right now is the addition of another benchmark and no change whatsoever in the existing code. Yet, none of the benchmark gets to completion now :/
<gnikunj[m]> all of them throwing the same Kokkos::Cuda::finalize() seg fault with no line info
<ms[m]> you'll need to run them in a debugger (with the benchmarks in debug mode)
<gnikunj[m]> aah, right. I'm on Release right now.
<gnikunj[m]> btw, did you check on Kokkos::Parallel_for? I remember you saying something about it using more hpx threads than necessary
<gnikunj[m]> ok, reinstalling doesn't work. Installing debug to know more on this.
nanmiao has quit [Quit: Connection closed]
<ms[m]> gnikunj: no, sorry, didn't check yet
<srinivasyadav227> can anyone help me with this? suppose if i want to check for a c++ feature like this https://github.com/STEllAR-GROUP/hpx/blob/master/cmake/tests/cxx20_std_execution_policies.cpp, then for example, if this test successfully compiles with GCC 10.1.. then if I am building hpx with c++14, then does it make use this feature as it compiled succesfully? or it can be only be used when building hpx with c++20 (i.e
<srinivasyadav227> HPX_WITH_CXX20)
<gnikunj[m]> ms: np
<gnikunj[m]> srinivasyadav227: it is checked only when you compile with C++20
<srinivasyadav227> gnikunj: okay, thanks :)
<ms[m]> srinivasyadav227: it's always checked
<gnikunj[m]> ms: why would you want to check always?
<gnikunj[m]> aah, you mean you'll fail the test in cmake?
<srinivasyadav227> sorry i didnt mean checking...its checks always..but can it be only used with same standard?
<srinivasyadav227> to be more clear, if any `cxx20_some_feature.cpp` test passes then that feature can be used with `HPX_WITH_CXX17` and `HPX_WITH_CXX14` or only with `HPX_WITH_CXX20`?
<K-ballo> the tets itself should not even run for cxx17/14
<srinivasyadav227> currently they are running
<K-ballo> that's a bug
<srinivasyadav227> with all the tests? 🥴
<K-ballo> with some config macro, more likely
<srinivasyadav227> okay
<K-ballo> looks intentional
<K-ballo> we used to have bad abi issues because of doing that
<srinivasyadav227> how does the test even gets compiled?,, how can some higher (or newer) standard's feature with lower standard compiler option like -std=c++VERSION?
<K-ballo> compilers provide newer features as conforming extensions in older standards all the time
<K-ballo> libraries sometimes even backport changes to older standards too, notably libc++'s std::string_view always available
<K-ballo> srinivasyadav227: as to your original question, if the feature test passes then you can use the feature
<K-ballo> if using the feature then leads to trouble, the test may be incomplete, or bogus, or running when it shouldn't, but in any case not your problem
<srinivasyadav227> K-ballo: ok thanks a lot! its bit clear now, but this is surprising and new for me anyways :)
<srinivasyadav227> but, i am using this new feature https://github.com/STEllAR-GROUP/hpx/blob/d41b84d6d4fb0129fb181cbabfc573f77b8dd88f/cmake/tests/cxx20_std_lambda_capture.cpp, then it should throw warning/error here https://cdash.cscs.ch/buildSummary.php?buildid=158668 right? when building with c++14/17 like this https://godbolt.org/z/sEWP937z5
nanmiao has joined #ste||ar
<K-ballo> it won't be an error if you guard it by the feature test
<K-ballo> it may be a warning, depending on whether feature tests disable warnings or not
<K-ballo> if the feature test decides warnings are fine, then warnings are fine
<K-ballo> the idea of a feature test is to run a minimal snippet representing actual real project usage, to determine whether it is fine or not
<srinivasyadav227> no, i mean, if that feature is passes the test, it is used at couple of places in hpx code, so when building with c++14/17 it should throw an error
<K-ballo> ?
<K-ballo> if the feature test passes, and the use is guarded by the feature test macro, it won't error out
<K-ballo> (if it does error out the feature test itself is horribly broken)
<K-ballo> the feature test, btw, is horribly broken
<K-ballo> (but not in a way that would lead to errors)
<srinivasyadav227> <K-ballo "if the feature test passes, and "> oh..i get it now :), can you share the code btw how it does
<K-ballo> what code is that?
<srinivasyadav227> oh..i get it now :), can you share the code how it does*
<K-ballo> which code how it does?
<srinivasyadav227> i mean..how the use is guarded by the feature test macro
<K-ballo> #if HPX_HAVE_whatever_name_you_gave_the_macro ?
<srinivasyadav227> yes
<K-ballo> so, which name did you give the feature test macro?
<srinivasyadav227> HPX_WITH_CXX20_STD_LAMBDA_CAPTURE
<K-ballo> WITH? should be HAVE
<K-ballo> WITH would be a user-facing knob
<srinivasyadav227> no no...right.. its HAVE only..typo here..
<K-ballo> and also shouldn't mention STD, since it's not library stuff (comes from std::)
<K-ballo> so it would be something like #if HPX_HAVE_CXX20_LAMBDA_CAPTURE
<srinivasyadav227> <K-ballo "so it would be something like #i"> Ok :)
<srinivasyadav227> i will change it
<K-ballo> but alas the macro will always be set, since unless that changed too we don't reject warnings in feature tests, and the feature test code is perfectly valid C++11
<srinivasyadav227> ok
<gonidelis[m]> jedi18: yt?
<jedi18[m]> Yep, hi!
<gonidelis[m]> jedi18: hey.... I kinda lost track of your work during the last couple of weeks
<gonidelis[m]> and since you are working on adapting the algorithms
<gonidelis[m]> do you provide iterator/sentinel tests for the container algorithms?
<gonidelis[m]> using the `iter_sent.hpp` header?
<jedi18[m]> I actually haven't got much done in the last few weeks thanks to my exams
<gonidelis[m]> or you haven;t actually worked on that yet?
<jedi18[m]> Yes I do
<gonidelis[m]> no problem at all
<jedi18[m]> and yeah I used the iter_sent header
<gonidelis[m]> so you 1. dismantle segmented/parallel algos 2. provide ranges overloads 3. make the algorithms accept different begin end iterator?
<jedi18[m]> You're referring to my PRs for the disentangle segmented algorithms or adapting to C++ 20 ones?
<gonidelis[m]> adapting
<jedi18[m]> for the former, just 1 (and 3 for the latest few). It usually already had ranges overloads
<jedi18[m]> oh well for adapting, all
<jedi18[m]> But I've only adapted min, max, minmax so far
<gonidelis[m]> only?
<gonidelis[m]> lol ;p
<gonidelis[m]> that's valuable, believe me
<gonidelis[m]> anyways
<jedi18[m]> Thanks :D, look forward to adapting the rest of them
<jedi18[m]> Assuming I get selected ofc, or well even if I'm not
<gonidelis[m]> thanks for your work! i just wanted to catch up with you in order keep in mind that the `iter_sent` head will be unified and kept in one place isolated (we stop copying the thing around like it's nothing)
<jedi18[m]> Oh ok yeah thanow, I'll keep that in mind
<jedi18[m]> thanks*
<gonidelis[m]> so when you get back to work I will have probably changed the guide that tells "just inclyde 'iter_sent.hpp'"
<gonidelis[m]> include ^^
<gonidelis[m]> ok I will keep you posted on when that may happen ;)
<jedi18[m]> Oh ok, I'll be sure to refer it then. Should I also go back and change the already made PRs too?
<gonidelis[m]> I did it in all of them ;)
<gonidelis[m]> we never push code that does not compile
<gonidelis[m]> (almost never)
<jedi18[m]> Ohh ok thanks
<jedi18[m]> Oh xD
<gonidelis[m]> :D
<jedi18[m]> Anyway I got my vaccine today and feeling a bit feverish (probably due to the side effects), so I'm gonna go sleep. Talk to you soon!
<gonidelis[m]> jedi18: you do that
<gonidelis[m]> bye
<gonidelis[m]> and thanks for being available
<jedi18[m]> Bye!
<gonidelis[m]> hkaiser: ms[m] https://github.com/STEllAR-GROUP/hpx/pull/5225#discussion_r609414537 the header handling commit includes 28 files :)
<jedi18[m]> Thanks for the help!
<gonidelis[m]> just the PR only messes with 22
<hkaiser> gonidelis[m]: is that a problem?
<gonidelis[m]> no
<gonidelis[m]> i was just thinking that the `reverse_adapt` pr would stop being readable
<gonidelis[m]> one might as well start reading the changes and see little adaptation and much header movement here and there
<hkaiser> gonidelis[m]: that's normal
<gonidelis[m]> oh ok
nanmiao has quit [Quit: Connection closed]
bita has joined #ste||ar
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
parsa has joined #ste||ar
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
bita has quit [*.net *.split]
klaus[m] has quit [*.net *.split]
SagarB[m] has quit [*.net *.split]
prahitha[m] has quit [*.net *.split]
pedro_barbosa[m] has quit [*.net *.split]
RosheenNaeem[m] has quit [*.net *.split]
mdiers[m] has quit [*.net *.split]
old_man[m] has quit [*.net *.split]
bita has joined #ste||ar
SagarB[m] has joined #ste||ar
klaus[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
old_man[m] has joined #ste||ar
RosheenNaeem[m] has joined #ste||ar
prahitha[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
sestro[m] has quit [Ping timeout: 246 seconds]
gdaiss[m] has quit [Ping timeout: 245 seconds]
CynthiaPeter[m] has quit [Ping timeout: 245 seconds]
gnikunj[m] has quit [Ping timeout: 245 seconds]
srinivasyadav227 has quit [Ping timeout: 245 seconds]
rori has quit [Ping timeout: 245 seconds]
AbanoubAsaad[m] has quit [Ping timeout: 245 seconds]
k-ballo[m] has quit [Ping timeout: 258 seconds]
gonidelis[m] has quit [Ping timeout: 250 seconds]
ms[m] has quit [Ping timeout: 246 seconds]
SagarB[m] has quit [Ping timeout: 276 seconds]
RosheenNaeem[m] has quit [Ping timeout: 276 seconds]
rachitt_shah[m] has quit [Ping timeout: 245 seconds]
jbjnr has quit [Ping timeout: 248 seconds]
HaimantikaMitra[ has quit [Ping timeout: 248 seconds]
Girlwithandroid[ has quit [Ping timeout: 245 seconds]
bering[m] has quit [Ping timeout: 245 seconds]
dashohoxha[m] has quit [Ping timeout: 258 seconds]
jedi18[m] has quit [Ping timeout: 258 seconds]
prahitha[m] has quit [Ping timeout: 276 seconds]
klaus[m] has quit [Ping timeout: 276 seconds]
pedro_barbosa[m] has quit [Ping timeout: 276 seconds]
mdiers[m] has quit [Ping timeout: 276 seconds]
old_man[m] has quit [Ping timeout: 276 seconds]
rainmaker6[m] has quit [Ping timeout: 248 seconds]
parsa has joined #ste||ar
diehlpk_work has quit [Ping timeout: 258 seconds]
diehlpk_work has joined #ste||ar
RosheenNaeem[m] has joined #ste||ar
SagarB[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
jedi18[m] has joined #ste||ar
rachitt_shah[m] has joined #ste||ar
bita has quit [Ping timeout: 276 seconds]
ms[m] has joined #ste||ar
rori has joined #ste||ar
AbanoubAsaad[m] has joined #ste||ar
dashohoxha[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
CynthiaPeter[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
srinivasyadav227 has joined #ste||ar
sestro[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
AbanoubAsaad[m] has quit [Ping timeout: 276 seconds]
jedi18[m] has quit [Ping timeout: 245 seconds]
sestro[m] has quit [Ping timeout: 245 seconds]
gnikunj[m] has quit [Ping timeout: 245 seconds]
ms[m] has quit [Ping timeout: 245 seconds]
mdiers[m] has quit [Ping timeout: 245 seconds]
k-ballo[m] has quit [Ping timeout: 245 seconds]
rori has quit [Ping timeout: 245 seconds]
rachitt_shah[m] has quit [Ping timeout: 245 seconds]
CynthiaPeter[m] has quit [Ping timeout: 258 seconds]
gonidelis[m] has quit [Ping timeout: 258 seconds]
dashohoxha[m] has quit [Ping timeout: 258 seconds]
RosheenNaeem[m] has quit [Ping timeout: 258 seconds]
SagarB[m] has quit [Ping timeout: 258 seconds]
pedro_barbosa[m] has quit [Ping timeout: 258 seconds]
srinivasyadav227 has quit [Ping timeout: 276 seconds]
HaimantikaMitra[ has joined #ste||ar
jbjnr has joined #ste||ar
gdaiss[m] has joined #ste||ar
Girlwithandroid[ has joined #ste||ar
bering[m] has joined #ste||ar
old_man[m] has joined #ste||ar
prahitha[m] has joined #ste||ar
klaus[m] has joined #ste||ar
rainmaker6[m] has joined #ste||ar
AbanoubAsaad[m] has joined #ste||ar
jedi18[m] has joined #ste||ar
nanmiao has joined #ste||ar
ms[m] has joined #ste||ar
rori has joined #ste||ar
CynthiaPeter[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
dashohoxha[m] has joined #ste||ar
RosheenNaeem[m] has joined #ste||ar
SagarB[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
sestro[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
rachitt_shah[m] has joined #ste||ar
srinivasyadav227 has joined #ste||ar
hkaiser has quit [Quit: bye]
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar