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/
<gonidelis[m]> K-ballo: why is that happening?
<gonidelis[m]> it's like the concept is more powerful than the type specialization
parsa has quit [Client Quit]
<K-ballo> those are not specializations, those are overloads
<K-ballo> is 3 a sentinel for it?
<K-ballo> that logic looks bogus btw
<gonidelis[m]> 2 is
<K-ballo> consider precedence
<K-ballo> (is_sentinel && is_input) || is_output
<gonidelis[m]> or is stronger
parsa has joined #ste||ar
<K-ballo> yes, in logic disjunction (or) is + and conjunction (and) is *
<gonidelis[m]> and || is *
<gonidelis[m]> ?
<K-ballo> || is or, disjuntction
<K-ballo> || is + and && is *
<gonidelis[m]> shit
parsa has quit [Client Quit]
<gonidelis[m]> w8 no
<gonidelis[m]> so || is stornger
<K-ballo> yes
<K-ballo> (is_sentinel && is_input) || is_output
<K-ballo> unless by stronger you mean the opposite?
<gonidelis[m]> stronger means it comes before &&
<K-ballo> you mean binds tighter? no
<gonidelis[m]> compiler first does the ||s and then the &&s
<K-ballo> is_sentinel * is_input + is_output
<gonidelis[m]> you were right and I hate it
<K-ballo> better just use parens when mixing || and &&, so people don't even have to think about it
<gonidelis[m]> yy hartmut told me that
<gonidelis[m]> I thought I was brave
<K-ballo> pity
<gonidelis[m]> lol
parsa has joined #ste||ar
parsa has quit [Client Quit]
<K-ballo> in any case, 3 isn't an output iterator, so shouldn't affect the case at hand
<gonidelis[m]> it worked nevetheless
parsa has joined #ste||ar
<gonidelis[m]> hkaiser: you could take a look at `ranges::next` if you want
<gonidelis[m]> K-ballo: there is a 92% possibility that you will hate my hybrid version
nanmiao has joined #ste||ar
<K-ballo> definitely
<K-ballo> is there no is_iterator trait in HPX?
<gonidelis[m]> yes there is
<gonidelis[m]> code readability motivation
<gonidelis[m]> i guess
<gonidelis[m]> but if that's your only comment that means I did well
<K-ballo> nah, there's no point in me looking at an implementation like that
<K-ballo> was just curious about all these `is_input<> || is_output<>` longwinded ways of checking for the iterator concept
<hkaiser> gonidelis[m]: I think you can avoid going over the sequence twice for the next(it, bound, n) case
<hkaiser> this would be especially important for !is_random_iterator<Iter>
<gonidelis[m]> hkaiser ... hmm
<gonidelis[m]> So even though there is an if split the compiler still goes through twice??
<hkaiser> well, _you_ go over it twice, once with distance and once with advance
<gonidelis[m]> shit....
<gonidelis[m]> you are right
<gonidelis[m]> ahhhh
<gonidelis[m]> what's the workaround?
<gonidelis[m]> i am thinking too structured-wise
<hkaiser> look at how advance_to_sentinel is implemented
<gonidelis[m]> Ok :)
<K-ballo> take a step back, and consider the core that these family of functions share
<hkaiser> nod
<hkaiser> feel free to restructure/rename existing functions
<srinivasyadav227> hkaiser: could you share the for_loop()
<srinivasyadav227> hkaiser: why cant we define is_vectorpack_execution_policy only when HAVE_HPX_DATAPAR is defined?, this should seperate normal algorithms better
<srinivasyadav227> hkaiser: what would you recommend me to work on now?
<srinivasyadav227> and i went through this http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0350r4.pdf this looks promising for std::simd, but currently only works for gcc
K-ballo has quit [Quit: K-ballo]
<hkaiser> srinivasyadav227: see https://github.com/STEllAR-GROUP/hpx/pull/5247, that should fix the performance
<hkaiser> srinivasyadav227: wrt the is_vector_pack_policy trait: yes, this is something we should try to achieve
<hkaiser> srinivasyadav227: note, #5247 may not compile for datapar as I didn't implement the new loop variants for it
<srinivasyadav227> hkaiser: shall i implement the changes for datapar?
<srinivasyadav227> and i would try separating normal algorithms from is_vector_policy
nanmiao has quit [Quit: Connection closed]
<hkaiser> ok, cool
<hkaiser> that would be nice
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jejune has quit [Quit: "What are you trying to say? That I can dodge bullets?" "No Neo, what I'm trying to say, is that when you are ready.....you won't have to"]
parsa has joined #ste||ar
parsa has quit [Client Quit]
hkaiser has quit [Quit: bye]
parsa has joined #ste||ar
<srinivasyadav227> :-)
linus2 has quit [Ping timeout: 265 seconds]
bita_ has joined #ste||ar
bita_ has quit [Ping timeout: 264 seconds]
balaje has joined #ste||ar
balaje has quit [Client Quit]
Ri2Raj has joined #ste||ar
<Ri2Raj> # In the HPX source directory
<Ri2Raj> mkdir build && cd build
<Ri2Raj> cmake -DCMAKE_INSTALL_PREFIX=/install/path ..
<Ri2Raj> make install
<srinivasyadav227> yes, that should build and install
<Ri2Raj> So does this means that I have to build hpx inside the folder cloned via git
<srinivasyadav227> depends on where you are doing mkdir build && cd build
<Ri2Raj> But it's mendtioned # In the HPX source directory
<srinivasyadav227> if you are doing inside cloned git repo, then yes, build will happen in cloned repo, and installation will hapen to -DCMAKE_INSTALL_PREFIX=/install/path
<Ri2Raj> And inside the hpx dowloaded folder there's a folder named src so should i build it there
<srinivasyadav227> no
<srinivasyadav227> after you cloned repo
<srinivasyadav227> cd to that repo
<Ri2Raj> so specifically only in the hpx folder
<srinivasyadav227> and do that commands
<srinivasyadav227> yes, you can do that
<Ri2Raj> where should i give the install path so that things don't go messy
<Ri2Raj> I mean recommended
Ri2Raj has quit [Quit: Connection closed]
peltonp1 has joined #ste||ar
jehelset has joined #ste||ar
<srinivasyadav227> @freenode_Ri2Raj:matrix.org create a folder with name hpx in a directory which you can easily access, i would prefer creating hpx folder in /usr/local and set install path as /usr/local/hpx
<zao> I had a long messsage typed out on the other machine waiting for them to return, I forget that some use Matrix :D
<zao> srinivasyadav227: I don't think they'll see your message, as they're on IRC and probably won't check logs.
<zao> srinivasyadav227: Personally, I prefer to keep all my development work outside of anywhere which requires superuser access.
<zao> And if I have to install something system-wide, a subdirectory of /opt is a good place as there's a fair bit of assumptions about what should go where in /usr/local
<zao> The less you intermingle your stuff with system things (even though local is somewhat free-for-all on some OSes), the better :)
<srinivasyadav227> zao: yes, actually /opt could be a better place ;-)
<zao> Best is of course your home directory or project storage, as multiuser machines exist :)
<zao> Fun fact, we had to uninstall “sudo” on our HPC clusters as the audit logs were full of users trying to break everything by following online advice.
<srinivasyadav227> zao: true!
<peltonp1> what is the correct cmake flag to set to get the coroutine support for hpx?
<peltonp1> HPX_WITH_COROUTINE_COUNTERS?
<peltonp1> or is it enough to just set the HPX_WITH_CXX2A ?
shubham has joined #ste||ar
hkaiser has joined #ste||ar
<gonidelis[m]> hkaiser: k-ballo I thought of using the type dispatching technique, but I am not sure. A sentinel value is not a sized sentinel while a distance-integer is?
<hkaiser> gonidelis[m]: not sure what you're talking about
<gonidelis[m]> about removing the if statement
<gonidelis[m]> according to advance_to_sentinel
<hkaiser> ok
<gonidelis[m]> I have an if(distance < n) which I think I should convert to just a type dispatch
<hkaiser> hmmm, not sure
<gonidelis[m]> hm..
<hkaiser> gonidelis[m]: I think you need to specialize on random_access_iterator and sized_sentinel_for
<hkaiser> if both is tru you can use the code you have (distance and advance will be O(1)
<hkaiser> otherwise you write a special version with one loop that stops either at bound or at N
<hkaiser> gonidelis[m]: same as for advance_to_sentinel
hkaiser has quit [Quit: bye]
shubham has quit [Quit: Connection closed for inactivity]
nanmiao has joined #ste||ar
hkaiser has joined #ste||ar
diehlpk_work has joined #ste||ar
<diehlpk_work> Why do we have nvcc this tool is a crime against the word compiler
<zao> Sounds about right.
<hkaiser> ms[m]: yt?
<diehlpk_work> ms[m], Is it really necessary to compile all code with nvcc if we use kokkos and CUDA?
<ms[m]> diehlpk_work: no, not necessary, but requires some build system changes (whatever depends on kokkos should be in a separate target that links privately to Kokkos::kokkos)
<ms[m]> hkaiser here
<diehlpk_work> ms[m], Ok, thanks that will help for octotiger
<k-ballo[m]> gonidelis a distance is not (in general) a sentinel
<diehlpk_work> libquadmath and nvcc is not a nice combination
<hkaiser> ms[m]: nvm, figured it out
<srinivasyadav227> hkaiser: hey, i went through the changes for foreach_performace branch, and made only constexpr changes for datapar locally, but didnt push because i have seen most of checks were failing?, shall i wait for fixes before pushing to datapar branch?
<srinivasyadav227> and what i have understood is we have done loop unrolling to improve the performace right?, with chunk size 4?
<gonidelis[m]> <k-ballo[m] "gonidelis a distance is not (in "> is it the only case of a sized sentinel though ??? if not, what's the other? k-ballo
<k-ballo[m]> a distance is not a sized sentinel, it's not even a sentinel
<gonidelis[m]> what is difference_type<Iter> n then?
<k-ballo[m]> some (likely integer) type that can represent the distance between two iterators
<gonidelis[m]> but it's not a sentinel?
<k-ballo[m]> no, not by being a difderence type
<k-ballo[m]> (there could in princilr be a type that served both as a difference and a sentinel, but it'd be on the odd side)
<gonidelis[m]> a sentinel is either an end iterator, a sentinel value or a distance value
<gonidelis[m]> is that statement wrong ? k-ballo
<k-ballo[m]> a sentinel is a sentinel
<k-ballo[m]> something that can be compared to an iteratoe
<gonidelis[m]> so that statement is correct
<zao> Compared to determine if you're at the end, not compare in general?
<gonidelis[m]> what's the end?
<zao> My impression (haven't read papers) is that traditionally you have ranges of two values of an iterator type, which you may compare to determine if you've reached the end of the range.
<zao> Sentinels generalize this to a pair of values, one of Iterator type and one of Sentinel type, which again may be compared but unlike earlier do not have to be the same type.
<gonidelis[m]> i think your discription is precise and correct
<zao> As I understand it, the sentinel type must still be a type for which a != like comparison with an iterator determines if the end of the range has been reached.
<zao> Kind of the same type of generalization that was made for std::less<> and ordered containers to make it possible to compare things like std::string and std::string_view in lookups.
<zao> If an iterator type is quite heavy in state or size, it's a bit of a waste to have to use the same type both as the start and end of a range. If it can be stripped down to the bare necessities needed to indicate end-ness, it can be a much lighter type.
<k-ballo[m]> compared in general
K-ballo has joined #ste||ar
<jpinto[m]> Hello. Is it possible to implement a performance counter that reads the value of a component's data member?
hkaiser has quit [Quit: bye]
nanmiao has quit [Quit: Connection closed]
hkaiser has joined #ste||ar
nanmiao has joined #ste||ar
<gonidelis[m]> hkaiser: shouldn't Sent templ. arg go first here?
<hkaiser> uhh, probably ;-)
<gonidelis[m]> I am afraid if I flip them the universe will explode
<hkaiser> good catch!
<hkaiser> let it explode, then
<gonidelis[m]> indeed. who cares
nanmiao has quit [Quit: Connection closed]
bita_ has joined #ste||ar
nanmiao has joined #ste||ar
bita_ has quit [Ping timeout: 264 seconds]
nanmiao has quit [Quit: Connection closed]
<gonidelis[m]> Don't concepts render useless type dispatching and specialization overloading?
<hkaiser> gonidelis[m]: it's another way of selecting overloads
<hkaiser> fancy way of doing sfinae
<gonidelis[m]> nod
<gonidelis[m]> hkaiser: I suspect that implementing ranges::next as a standalone functionality is not a good strategy. Do you recommend implementing ranges::advance first and then just jump on its wagon to do the job
<gonidelis[m]> ?\
<hkaiser> advance can be implemented on top of next: advance(it, n) { it = next(it, n); }
<gonidelis[m]> ok now i am confused
<gonidelis[m]> #possible implementation
<gonidelis[m]> they suggest implementing them the other way around
<gonidelis[m]> they are the same thing at the end of the day (just the one uses a copy while the other does not)
<gonidelis[m]> but since next used the copy seems more cogent to me to impl next on top of advance
<hkaiser> either way
<gonidelis[m]> ahh
<K-ballo> constexpr if "renders useless" type dispatching, not concepts
<gonidelis[m]> ok
<K-ballo> advance is the primitive, it's distance can be negative
<gonidelis[m]> primitive?
<K-ballo> the one all the other overloads can be implemented on top of
<K-ballo> the others being all overloads of next and prev
<gonidelis[m]> oh ok
<gonidelis[m]> i will leave prevfor some other time i will go with advance for now
<gonidelis[m]> just to get next done
<K-ballo> they are all the same one thing
<K-ballo> once you get advance in place (do it from scratch, don't relay on other std or hpx bits), you will probably have a clear picture of the whole family
<gonidelis[m]> shouldn't i implement them separately though
<gonidelis[m]> ?
<gonidelis[m]> or do you expect me to have one base impl and then just form the facilities based on that
<K-ballo> next/prev are just facades over advance, little to no gain in implementing them separately
<gonidelis[m]> what do you mean separately?
<K-ballo> at a separate time, at a different pr
<K-ballo> all they do is forward to advance
<gonidelis[m]> yeah you are right actually... i think i can do all three
<gonidelis[m]> do you want to add the tests ?
<K-ballo> no, you add them
<gonidelis[m]> well you got your answer then
jehelset has quit [Ping timeout: 260 seconds]
<gonidelis[m]> what do you think about this implementation?
<gonidelis[m]> it sure is verbose
<gonidelis[m]> and I have a doubt about my lvalue/rvalue refs handling
parsa has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
<gonidelis[m]> I take an lvalue ref and then I pass it as an rvalue, not sure if I should be passing it around as an lvalueref
<gonidelis[m]> hkaiser: K-ballo ^^
<hkaiser> why would you do that?
<gonidelis[m]> i certainly need the lvalue in order to mutate the iterator
<hkaiser> yes
<gonidelis[m]> std::forward is not needed, right?
<hkaiser> no
<gonidelis[m]> std move?
<hkaiser> neither
<hkaiser> also typename hpx::traits::is_random_access_iterator<Iter>::type{} is the same as hpx::traits::is_random_access_iterator<Iter>{}
<hkaiser> well, in this context
<gonidelis[m]> oh ok...
<gonidelis[m]> ...
parsa has joined #ste||ar
<gonidelis[m]> hkaiser: do you think i should just add the sentinel cases? how do you wanna handle this?
<gonidelis[m]> i could either create a whole new ranges::advance or add to that one
<hkaiser> you could also move the code here to a new file and consolidate everything there
<gonidelis[m]> do we wanna support both ranges::advance and std::advance ?
<gonidelis[m]> i think the former is wider and encapsulated the latter
<hkaiser> what do you think?
<gonidelis[m]> encapsulates*
<hkaiser> we should have only facilities we need
<gonidelis[m]> I don't know what the users want (they may don't even care about that actually)
<K-ballo> you said something about adding these for standard conformance of interfaces or whatnot
<gonidelis[m]> so it's just for us... there is no point in creating a front ranges::<predicate> API then
<hkaiser> we could do that, but I don't think we should expose a full ranges library
<gonidelis[m]> what augustin said ^^
<gonidelis[m]> big overheads
<gonidelis[m]> i get it
<K-ballo> overheads?
<gonidelis[m]> lots of programming work for little gains for the users
<gonidelis[m]> its us who use this stuff mainly
<gonidelis[m]> users use algorithms, mainly
<hkaiser> we wouldn't need it if we could rely on them always being available in the std library
<gonidelis[m]> i thought we were "antagonizing" the stdlib
<gonidelis[m]> i thought we were "antagonizing" the stdlib ^^
<K-ballo> if it's not for interfaces, then I'd imagine hpx already have all the bits and pieces it needs, no?
<hkaiser> I'd rather use things if available