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/ | GSoC: https://github.com/STEllAR-GROUP/hpx/wiki/Google-Summer-of-Code-%28GSoC%29-2020
nanmiao11 has joined #ste||ar
akheir has quit [Quit: Leaving]
hkaiser has quit [Quit: bye]
nanmiao11 has quit [Remote host closed the connection]
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
Yorlik has quit [Ping timeout: 264 seconds]
bita_ has quit [Ping timeout: 256 seconds]
karame_ has quit [Remote host closed the connection]
diehlpk__ has quit [Remote host closed the connection]
diehlpk__ has joined #ste||ar
diehlpk__ has quit [Remote host closed the connection]
diehlpk__ has joined #ste||ar
nikunj97 has joined #ste||ar
weilewei has quit [Remote host closed the connection]
hkaiser has joined #ste||ar
nikunj97 has quit [Read error: Connection reset by peer]
nikunj97 has joined #ste||ar
diehlpk__ has quit [Remote host closed the connection]
diehlpk__ has joined #ste||ar
diehlpk__ has quit [Remote host closed the connection]
diehlpk__ has joined #ste||ar
kale[m] has quit [Ping timeout: 272 seconds]
kale[m] has joined #ste||ar
nanmiao11 has joined #ste||ar
diehlpk__ has quit [Ping timeout: 244 seconds]
diehlpk__ has joined #ste||ar
<nikunj97> hkaiser, just looked at the implementation of async. That's a lot of template specialization trickery ;-)
<nikunj97> I think ik how to do something similar for distributed resiliency module
<hkaiser> nikunj97: just one specialization for each use case
<nikunj97> yes. Good thing I can use your specialization directly into my version with a bit of tweaking here and there
<hkaiser> sure
weilewei has joined #ste||ar
karame_ has joined #ste||ar
diehlpk__ has quit [Ping timeout: 256 seconds]
Nikunj__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 258 seconds]
nikunj97 has joined #ste||ar
Nikunj__ has quit [Ping timeout: 244 seconds]
nikunj has quit [Ping timeout: 244 seconds]
nikunj has joined #ste||ar
akheir has joined #ste||ar
diehlpk_work has quit [Remote host closed the connection]
diehlpk_work has joined #ste||ar
Nikunj__ has joined #ste||ar
<gonidelis[m]> K-ballo: I am about to fix the namings (last -> sentinel).
<gonidelis[m]> 1. The first block that need fixing is here https://github.com/gonidelis/hpx/blob/2104ee1d166cb4cc18257ccd074b46232b54c938/libs/algorithms/include/hpx/parallel/algorithms/for_each.hpp#L367 . Do you think that `InIter last` would be better as `Sent sentinel` maybe?
<K-ballo> 1. curious about the inconsistency (why not `Sentinel sentinel` or `Sent sent`) but sure, 2. if those are actually sentinels then sure, consistency
nikunj97 has quit [Ping timeout: 260 seconds]
kale[m] has quit [Ping timeout: 244 seconds]
<gonidelis[m]> 1. OK... will do it this way. Thanks! 2. that's what I am asking (more of a theory question )
<gonidelis[m]> I think that `FwIterE` is not mandatory to be a Forward Iterator as there are other forms of sentinels
<gonidelis[m]> So it could be better if we `FwIterE` -> `Sent`
kale[m] has joined #ste||ar
<K-ballo> as long as it is used as a sentinel and not an iterator, sure
<K-ballo> ideally there would be existing documentation saying so in spec
<gonidelis[m]> Shouldn't this be fixed then/
<gonidelis[m]> ?
<hkaiser> it sure should be fixed
<gonidelis[m]> K-ballo: let me check the spec then
<K-ballo> the spec above says FwdIterE must meet the requirements of a forward iterator, is the spec wrong?
<gonidelis[m]> hkaiser: I will create a separate PR if needed
<gonidelis[m]> K-ballo: link?
<hkaiser> :D
<hkaiser> gonidelis[m]: as I said before, we should rethink the namespaces and different versions of algorithms we expose
<hkaiser> now that c++20 is 'out' we should adapt things
<hkaiser> in the end for_each has at least 3 or 4 different versions: std::for_each, std::ranges::for_each, etc.
<K-ballo> gonidelis[m]: your link, scroll up
<gonidelis[m]> K-ballo: Oh you are talking about the doxygen comments. Ok...
<K-ballo> yeah, that's where the documented spec comes from
<gonidelis[m]> I think that these are obsolete since I made the changes for the begin and end iter to be of different type
<K-ballo> I'm not entirely a fan of multiple versions, if they do all the same thing
<hkaiser> gonidelis[m]: the hpx::for_each will probably be left as is, while hpx::ranges::for_each will have to support sentinels
<hkaiser> but let's discuss
<K-ballo> std::ranges:: doesn't do parallelism, do we have any use for that in hpx?
<gonidelis[m]> hkaiser: hmmm ok.... question: doesn't the adapted `hpx::for_each` support sentinels too?
<hkaiser> well, if we want to be conforming we should change things accordingly
<hkaiser> c++20 wasn't ready yet, so we had to wait for the dust to settle
kale[m] has quit [Ping timeout: 258 seconds]
<gonidelis[m]> K-ballo: sorry, didn't understand the question
<gonidelis[m]> hkaiser: well, has the dust settled yet?
kale[m] has joined #ste||ar
<hkaiser> I hope so ;-)
bita_ has joined #ste||ar
<gonidelis[m]> hkaiser: Where could I check?
<K-ballo> conforming to std::ranges::for_each would mean dropping the execution policy
<gonidelis[m]> but in this spec, `for_each` is like `for_each(ExecutionPolicy&& exec,
<gonidelis[m]> ForwardIterator first, ForwardIterator last,...)`
<gonidelis[m]> K-ballo: Under what section is `std::ranges::for_each` in the spec above?
<nanmiao11> hkaiser are we going to meet at 11:15 or 11:45?
<diehlpk_work> kale[m], What about the information for the blog post?
<diehlpk_work> You are four days overdue
<hkaiser> nanmiao11: 11:30/45 would be fine
<nanmiao11> Okay. will join in 11: 30
<gonidelis[m]> hkaiser: Just created the PR https://github.com/STEllAR-GROUP/hpx/pull/4809/ . We can discuss namings there ;)
<gonidelis[m]> any ideas who is this jenkins-cscs guyt :p ?
<hkaiser> gonidelis[m]: it's a bot
<kale[m]> diehlpk_work: I had told you that I'll write one before friday when you asked me before.
<K-ballo> gonidelis[m]: [alg.foreach]
<hkaiser> nanmiao11: I'm ready whenever you are
<diehlpk_work> kale[m], Ok, I have not seen your response. Note that you are 7 days late if you submit by Friday.
<diehlpk_work> Next time, this will affect your second evaluation
Yorlik has joined #ste||ar
<hkaiser> ms[m]: what should we do about the jenkins comments on new PRs?
<hkaiser> is there a magic incantation to tell jenkins it's ok? or is it just a well-meant heads up?
<gonidelis[m]> hkaiser: What is an spdx tag?
<gonidelis[m]> also feel free to propose further tests that you think I should include
<hkaiser> see also https://spdx.dev/
<ms[m]> hkaiser: it asks that because gonidelis is not on the whitelist, you can give one-off permission to run with a comment "ok to test" or add a user to the whitelist with "add to whitelist" (we can change these triggers as well, and I can add users manually as well)
<hkaiser> ms[m]: cool, where can I read about this?
<ms[m]> for now it won't do anything useful on that branch though because it doesn't have a config
<hkaiser> sure
<gonidelis[m]> ok I think it's fine now... Should I work on some other algo adaptation while I wait for the integration tests? Or is it better to work on the range adaptation ?(although I think that's already done)
<hkaiser> gonidelis[m]: some more tests might be in order...
<gonidelis[m]> hkaiser: ok sure. I could use some recommendation on that though ....
<ms[m]> hkaiser: I think this is pretty much it: https://github.com/jenkinsci/ghprb-plugin
<ms[m]> that's the plugin we're using to trigger builds from pull requests
<hkaiser> thanks
<hkaiser> ms[m]: can we use something similar on rostam?
<ms[m]> yeah, I think that'd be possible
<ms[m]> I've no clue how to install jenkins since it was already available, but I guess it wouldn't be too hard
<ms[m]> getting the configuration would be easy enough at least now that I've done it once
<hkaiser> ms[m]: I'll talk to Alireza about that
<ms[m]> 👍️
<gonidelis[m]> It's my first issue so I might have made mistakes
<gonidelis[m]> Please give it a look
<gonidelis[m]> K-ballo: hkaiser
<hkaiser> gonidelis[m]: will have a look
<hkaiser> gonidelis[m]: looks good, thanks
<gonidelis[m]> ;)
<gonidelis[m]> hkaiser: Just noticed that my test is pretty bad formatted
<hkaiser> it's pretty scarse as well ;-)
<gonidelis[m]> What I am trying to do is for the test to pass if the for_each call compiles fines
<gonidelis[m]> fine^^
<hkaiser> is it a compile only test?
<hkaiser> or is it supposed to actually run and test something?
<gonidelis[m]> yeah... So I am trying to find wether there is some HPX_TEST_* util that checks just wether the thing compiles
<gonidelis[m]> It's just a compile test
<gonidelis[m]> sth like static_assert maybe? But I don't know if that's the way you'd like for things to be tested in hpx
K-ballo has quit [Ping timeout: 246 seconds]
K-ballo has joined #ste||ar
<hkaiser> you could combine that with some actual tests (with different execution policies, perhaps)
<gonidelis[m]> you suggest that I should actually compute sth with for_each and then check wether the result is correct
<gonidelis[m]> right?
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
<gonidelis[m]> https://github.com/STEllAR-GROUP/hpx/pull/4809 Should I worry about those windoes errors?
<gonidelis[m]> hkaiser: I think I created a much clearer test now
<hkaiser> does it work as well if you use par as the execution policy?
<diehlpk_work> K-ballo, Hey
<diehlpk_work> do you have any reference that using templates is not bad and does not have much affect on the run time?
<gonidelis[m]> hkaiser: !!!! you got me.
<gonidelis[m]> :/
<hkaiser> diehlpk_work: templates never have any runtime impact
<diehlpk_work> One of the reviewers complained that I use templates and therefore my code will be slow
<diehlpk_work> hkaiser, I know, but if I have a reference not from me, the reviwer will be more convinced
<hkaiser> diehlpk_work: templates are a compile time feature, thus by definition don't have any runtime impact
<diehlpk_work> Ok, but I think that the reviewer will not accept that
<gonidelis[m]> hkaiser: I totally missed it for some reason (maybe I was caught up in error handling, anyways). Just fixed it. Made both the adaptation and included a test for `par`
<hkaiser> diehlpk_work: what should we write? the reviewer clearly doesn't understand what he/she is talking about, it's like asking us to prove that 2 * 2 == 4
<diehlpk_work> Ok, what about his concerns for virtual function calls?
<hkaiser> the fundamental premise of templates as a language feature is that the generated code is indistinguishable from manually writte code
<hkaiser> moreover, templates themselves are not code, they are recipies to generate code
<hkaiser> diehlpk_work: do we use virtual functions?
<gonidelis[m]> K-ballo: This is an example I found on cpp reference `Sum s = std::for_each(nums.begin(), nums.end(), Sum());` . Does that imply that `for_each` returns the result of Sum instead of the iterator?
<hkaiser> das ist so fundamental das niemand auch nur darueber redet
<gonidelis[m]> The complete code is here https://en.cppreference.com/w/cpp/algorithm/for_each
<hkaiser> gonidelis[m]: no
<hkaiser> sorry for the Germna blurb, wrong windows
<hkaiser> :/
<K-ballo> diehlpk_work: "that's just not how templates work", signed: me
<gonidelis[m]> I am currently taking some Germat tutorials and that's a good chance for practise actually
<gonidelis[m]> ;p
<hkaiser> K-ballo: thanks
<K-ballo> gonidelis[m]: std::for_each returns the function object used with it
<K-ballo> but only non-parallel std::for_each, as the parallel one does many copies
<gonidelis[m]> hpx::for_each returns the iterator. Isn't that different from std::for_each?
<hkaiser> gonidelis[m]: the example references ranges::for_each, I think - std::for_each does not return the function object
<gonidelis[m]> K-ballo: ^^
<K-ballo> ranges::for_each returns both iterator and function, but it is non-parallel
<gonidelis[m]> hmmm ok...
<K-ballo> we have all of void, Fun, and {Fun, Iter}
<K-ballo> Fun makes no sense for parallel anyways, so we can ignore that
<gonidelis[m]> Great :) . I shall wait for feedback on my tests then...
miya3716[m] has joined #ste||ar
<gonidelis[m]> K-ballo: Any ideas on what other tests should I add?
<K-ballo> I haven't seen them yet
<gonidelis[m]> oh ok
<K-ballo> gonidelis[m]: looks fine when combined with the existing tests
<gonidelis[m]> ok, that makes me very happy. I was just wondering wether I should include more sentinel cases
<K-ballo> they are all the same
<gonidelis[m]> ohhh ok... so, no other test cases
mcopik has joined #ste||ar
mcopik has quit [Ping timeout: 258 seconds]
mathegenie[m] has joined #ste||ar
Nikunj__ has quit [Read error: Connection reset by peer]
miya3716[m] has left #ste||ar ["User left"]
kale[m] has quit [Ping timeout: 244 seconds]
kale[m] has joined #ste||ar
wash[m] has quit [Ping timeout: 260 seconds]
zao has quit [Ping timeout: 246 seconds]