09:52 <jbjnr> I have made some changes to the GSoC page here. https://github.com/STEllAR-GROUP/hpx/wiki/HPX-Google-Summer-of-Code-(GSoC)-2020 however, I've forgotten what we discussed last week and I think we agreed to combine the parallel algorithms tasks into one bigger project?

12:06 <simbergm> jbjnr: don't remember exactly either, but I guess it could be one project as long we make it clear that a student isn't expected to complete all three projects that we have there now

13:55 <jbjnr> Yorlik: FYI the PR here https://github.com/STEllAR-GROUP/hpx/pull/4306 could be used to solve your initialization of things on a once per thread/core basis. The test included in the PR shows how to use bound tasks to assign to a given core and it does a round robin test of the functionality. Note that this only works with the shared-priority scheduler - see the init part of the test.

13:58 <Yorlik> Thanks jbjnr - I'll look into it.

14:10 <Yorlik> jbjnr: Looking through the discussion inb this PR this seems like an API redesign task to me, in terms of Scott Meyers "Make APIs easy to use and hard to misuse".

14:10 <Yorlik> That rule also for me is the reason why I prefer hard errors over hard to debug runtime oddities.

14:11 <K-ballo> I see you've learned all the catchy phrases by now

14:11 <Yorlik> Honestly - my decades of experience in life tell me, that when bad things happen it usually is because simple things are neglected and not the complicated things get out of hand.

14:12 <jbjnr> Yorlik: we have to do quite a lot of refactoring anyway to keep up with the latest executors proposal.

14:12 <Yorlik> So - yes - I like simple catchy phrases for a reason.

14:12 <Yorlik> You mean from the CPP guys?

14:13 <K-ballo> who are the CPP guys?

14:13 <jbjnr> not us apparently

14:13 <Yorlik> The stnadards committe and people submitting proposals there

14:13 <jbjnr> yes. those ones.

14:13 <K-ballo> so like jbjnr and hkaiser and me?

14:13 <Yorlik> Or is it an internal hpx proposal?

14:13 <jbjnr> no the cpp one

14:14 <Yorlik> IC. Thats one thing I really like about hpx: staying close to the standard.

14:14 <jbjnr> our current API is based off an older revision o the proposal

14:14 <Yorlik> IC.

15:23 <diehlpk_work> hkaiser, https://ieeexplore.ieee.org/abstract/document/8950704

15:24 <diehlpk_work> https://ieeexplore.ieee.org/document/8956479

15:24 <diehlpk_work> The links to the SC 19 workshop proceedings papers

15:36 <hkaiser> diehlpk_work: thanks, I have updated the publications sites

16:53 <heller2> jbjnr: i already started on it...

16:53 <heller2> But it's quite intense to implement

21:35 <primef> Oh I didn't know about that, good you told me! So do I have to take further actions, such as refactor my application or use different APIs or is it enough to set the MPI_PARCELPORT build flag?

21:35 <primef> simbergm

21:38 <simbergm> primef: no, application code stays the same

21:38 <simbergm> I think if you have the mpi parcelport enabled it'll take precedence over the tcp one

21:38 <simbergm> if not you might need to pass `--hpx:ini=hpx.parcel.mpi.enable=1` to the application

21:40 <primef> Alright, thank you! I will for sure try that. How do I make sure MPI is used over TCP? Is there some function I can call to check? Otherwise, I will use `--hpx:ini=hpx.parcel.mpi.enable=1` directly to be sure

21:43 <simbergm> primef: don't remember (I'm not a very active user of the parcelports...), if you're still around tomorrow I'll look it up

21:43 <simbergm> hkaiser would definitely know

21:47 <primef> alright, thank you so much! Yes, I guess I will be here. I put the channel on auto-join, so when my computer is on I'm online :-D. So just mention me and I will be there!

21:48 <primef> Another question to which you may have an answer: is it correct that jemalloc is one of the most performant allocators around?

21:49 <simbergm> good, hope to see you around here

21:49 <simbergm> yeah, jemalloc is pretty good, but so are the others

21:49 <simbergm> it performs roughly the same as tcmalloc in most cases

21:50 <simbergm> mimalloc is a new one which seems even faster in some limited tests, but in the end you'll have to try them out and see what works best for your application

21:51 <simbergm> note that it's most likely not something you need to be testing in the beginning, this is when you can't think of other ways to speed up your application ;)

21:51 <heller2> primef: the MPI parcelport should be automatically chosen once you run your program with mpirun

21:51 <heller2> without it, the TCP one is chosen

21:51 <simbergm> ah right, thanks heller

21:52 <primef> simbergm: sounds good, thanks! then I'll ignore it for the moment and stick with jemalloc.

21:52 <simbergm> primef: yep, that's a good choice

21:53 <primef> heller2: So you mean, just set the build flag HPX_WITH_PARCELPORT_MPI and it is enabled?

21:53 <heller2> correct

21:53 <simbergm> note that if you're on linux you can also set HPX_WITH_MALLOC=system and LD_PRELOAD another allocator when you actually need it

21:54 <primef> heller2: perfect, thanks!

21:55 <primef> simbergm: I like it. Only disadvantage I see, is that it is less transparent to other people, what allocator I use. As I develop in a group that might cause some chaos.

21:56 <simbergm> yeah, in that case it's probably better to make the choice upfront

22:15 <heller2> ms: how many responses did you get already?

22:20 <simbergm> heller 10 when I last checked earlier today

22:20 <heller2> cool, not bad

22:20 <simbergm> I can share the results already with you'd like (it's a Google sheet...)

22:21 <simbergm> Yeah, quite happy with it

22:24 <heller2> yes, please

22:37 <hkaiser> yes please do share it

22:55 <hkaiser> simbergm: ^^

23:22 <primef> hkaiser: hi, regarding #3646, once I implement a fix should I build, commit, push and let the automatic tests do the work? Or should I test them myself? If this is the case, are there any default test cases?

23:49 <hkaiser> primef: well you can do both

23:49 <hkaiser> PRs are tested by the testing infrastructure, but I'd make sure that it does what it should before creating the PR locally

23:50 <hkaiser> but I never run the full test suite locally, only the relevant parts

23:51 <hkaiser> primef: also, there is already a PR that implemented #3646 for two algorithms, but that one fails the testing - so it might be a good start to figure out what's wrong with it

23:52 <hkaiser> primef: (#3829)

23:55 <hkaiser> primef1: not sure if you saw my responses above