08:11 <ms[m]1> gonidelis[m]: sorry for not replying earlier... the most important ones are `-DCMAKE_BUILD_TYPE=Release -DHPX_WITH_MALLOC=tcmalloc/mimalloc/jemalloc`, `CXXFLAGS=-march=native` may also make a small difference

08:47 <gonidelis[m]> oh should mallocs make a significant difference?

12:17 <ms[m]1> gonidelis[m]: big difference!

12:17 <ms[m]1> the system allocator is pretty terrible when it comes to multithreading

12:18 <gonidelis[m]> ah ms[m] thanks

12:18 <gnikunj[m]> I've usually found that jemalloc works the fastest, tcmalloc a close second, and system is significantly slower than these.

12:21 <sestro[m]> Are there any benchmarks that can give me an indication for which workloads the performance of the allocators differs significantly?

12:49 <hkaiser> sestro[m]: any application should do, allocators are fundamental

12:54 <sestro[m]> Okay, I am using the system allocator right now as I use HPX in a shared library hoping not using jemalloc would not hurt too much.

12:56 <hkaiser> sestro[m]: depends on the platform, on linux you might see significant speedup

13:02 <srinivasyadav227> hkaiser: there is a merge conflict on #5235, its not allowing me to make changes, so should i solve the merge conflict with another commit and push? and you told you have some comments regarding #5254, please tell if any further changes are required for #5235

13:03 <hkaiser> srinivasyadav227: best is to rebase onto master while resolving the conflicts

13:03 <hkaiser> and then force-push to your branch

13:03 <sestro[m]> hkaiser: At some point I tried using a different one but this ended in some horrible conflict between different allocators in different shared libraries/python modules. I probably did something stupid and should explore that again.

13:04 <srinivasyadav227> hkaiser: ok i will do that

14:11 <srinivasyadav227> hkaiser: Thanks for pushing ;-), i would use rebase from next time, i was not familiar with that, i only knew git merge

14:16 <srinivasyadav227> srinivasyadav227: regarding GSoC project "Add vectorization to par_unseq", i have a doubt, i should implement all theses four right? (unsequenced_policy, unsequenced_task_policy, parallel_unsequenced_policy, parallel_unsequenced_task_policy)

14:23 <hkaiser> srinivasyadav227: they are all the same, essentially

14:29 <srinivasyadav227> hkaiser: oh ok, for those policies we need to write unsequenced_exector.hpp and parallel_unsequenced_executor.hpp? something similar to (https://github.com/STEllAR-GROUP/hpx/blob/master/libs/parallelism/executors/include/hpx/executors/parallel_executor.hpp)

14:32 <srinivasyadav227> and for all these we need common vectorization backend to be implemented first right?

14:53 <hkaiser> srinivasyadav227: we already have those

14:54 <hkaiser> srinivasyadav227: here: https://github.com/STEllAR-GROUP/hpx/blob/master/libs/parallelism/executors/include/hpx/executors/execution_policy.hpp#L1305-L1451

14:55 <hkaiser> they do not support async execution yet, but that's orthogonal

14:58 <srinivasyadav227> oh wait, i am confused, what are the expected deliverables for "Add vectorization to par_unseq"

14:59 <diehlpk_work> ms[m]1, Do you need help to finalize the GSoD propsoal?

15:00 <ms[m]1> diehlpk_work: yeah, if you had a good idea for the budget section I'd appreciate your help

15:01 <hkaiser> srinivasyadav227: support more algorithms

15:01 <diehlpk_work> ms[m]1, https://www.payscale.com/research/US/Job=Technical_Writer/Salary

15:02 <diehlpk_work> I would use the base salary there and derive the pay per hour

15:02 <diehlpk_work> And would multiply this value with the hours the technical writer will work for us

15:04 <diehlpk_work> So using the average from the above webpage yields 29.26 per hour

15:05 <diehlpk_work> Do you have time to participate during the six months of the program (April-November 2021)? Project sizes vary, but range from a commitment of 5-30 hours per week during the program.

15:06 <diehlpk_work> So I would just define how much work per week we want to see

15:08 <diehlpk_work> Using this approach the example amount reflects 14 hours per week

15:08 <diehlpk_work> ms[m]1, Let me know what you think?

15:10 <srinivasyadav227> hkaiser: oh, that means I need not implement par_unseq policy again, we already have it, i should use the existing par_unseq policy and support it for parallel alogirthms?, and currently no hpx parallel algorithm supports par_unseq

15:19 <hkaiser> yes

15:19 <hkaiser> srinivasyadav227: that is correct

15:25 <srinivasyadav227> hkaiser: ok thanks, i think i need to spend much time on proposal and work on PRs little less till April 13, then again i would focus on PRs, is that fine?

15:33 <jedi18[m]> @freenode_hkaiser:matrix.org same here, my exams are starting next week so I probably won't get time to work on any more PRs till they're over (on the bright side, this means no exams during the gsoc period)

15:39 <hkaiser> srinivasyadav227, jedi18[m]: sure, please take your time

15:42 <srinivasyadav227> hkaiser: thank you ;-)

16:03 <ms[m]1> diehlpk_work: yeah, that sounds reasonable

16:04 <ms[m]1> I obviously don't know how much work that project will take but I imagined something like 10-20 hours per week would be reasonable

16:04 <ms[m]1> with 15 hours per week for 12 weeks that's roughly the 5000 that we have there now

16:10 <shubhu_> hello everyone

16:12 <nanmiao> =D =D

17:16 <ms[m]1> hkaiser: fyi: https://cdash.cscs.ch/viewTest.php?onlyfailed&buildid=154042

17:16 <ms[m]1> that's with networking and distributed runtime off I think

17:33 <hkaiser> ms[m]1: uhh

17:33 <hkaiser> is that on master now?

17:34 <hkaiser> it did pass on the PR :/

17:34 <hkaiser> at least I believe it did

17:48 <ms[m]1> hkaiser: looks like it was already there on the PR :/

17:49 <ms[m]1> let me know if I can help there, it might be something I need to change in the way the local runtime is started

17:52 <hkaiser> ms[m]1: could be

17:53 <hkaiser> the PR mainly changed the command line handling and the post plugin load repeated command line processing

17:53 <hkaiser> I wouldn't expect that to be different for the local case

17:53 <hkaiser> ms[m]1: I'd appreciate if you had to time to look

17:55 <ms[m]1> it's most likely not a good thing that that's handled in runtime_support_server...

17:58 <hkaiser> ms[m]1: could be

17:58 <hkaiser> we can disable the test for the local case for now

18:01 <ms[m]1> it's definitely the reason, but can we leave it for now, I'd like to have a look

18:01 <ms[m]1> if we disable it I'll never look at it

18:01 <ms[m]1> if I don't do it by the end of next week we can disable it

18:01 <hkaiser> sure

18:01 <hkaiser> ok

18:02 <hkaiser> ms[m]1: I'm working on reviving libcds, once that's done I'll try to look at the problem as well

18:03 <ms[m]1> 👍️

20:37 <bita> hkaiser, about the LowerMatrix, I read the last example here: https://bitbucket.org/blaze-lib/blaze/wiki/Triangular%20Matrices#!the-triangular-property-is-always-enforced in the comment it says"// Throws an exception; lower matrix invariant would be violated!" I think that's the example of how it shouldn't work

20:37 <hkaiser> bita: nod

20:38 <hkaiser> I think LowerMatrix should be used on the right hand side

20:38 <bita> so is there anything I don't get or should we use a for with blaze::band?

20:39 <hkaiser> DynamicMatrix<double> m = LowerMatrix<DynamicMatrix<double>>(src);

20:39 <hkaiser> would that work?

20:39 <bita> I will check it out

20:39 <hkaiser> thanks

20:41 <hkaiser> bita: most likely you need to use LowerMatrix<CustomMatrix<>>, though

20:44 <bita> this throws an exception: https://gist.github.com/taless474/730c5101b6f2fdfb9e5edc75faf54188

20:46 <bita> It only works if src is actually a LowerMatrix

20:47 <hkaiser> hmmm

20:48 <hkaiser> does it throw at runtime?

20:49 <bita> yes, as I don't see it and it wants to abort it "C:\Repos\blaze_app_1\cmake-build-debug\Debug\app1.exe (process 20600) exited with code 3."

20:52 <hkaiser> nod

20:52 <hkaiser> darn

20:52 <hkaiser> let's ask Klaus how to do that

20:53 <hkaiser> ot really sure if band is the appropriate way of extracting a diagonal matrix

20:54 <bita> Thank you. I think I saw his name the other day here. Should we email him or ...?

20:54 <hkaiser> yah, email is best - do you have his email address?

20:55 <bita> yes :+1

23:59 <K-ballo> github says I've only contributed 2 commits to hpx