09:56 <Yorlik> Is it possible to build HPX with clang (clang-cl) on Windows?

10:01 <Yorlik> My last attempt exploded. Trying cl now ..

10:02 <Yorlik> Like clang asked for -c16 feature requirement - so I assume compiler specifics haven't been abstracted away - or?

10:08 <Yorlik> Seems cl is working nicely .... poor clang been sacked :(

10:10 <Yorlik> Though it makes we wonder a little - CMake allows so much abstracting away compiler specifics - is it really that hard/impossible so support multiple compilers? Or is it just on Windows like this?

10:12 <zao> Alternative compilers on Windows are a mess, as is all the tool chains with VS

10:12 <zao> Clang’s VS story is better than the mingw mess

10:12 <zao> Where a lot of deployments of mingw are ancient and 32-bit half-measures

10:13 <zao> For cmake a lot of times you just need to populate the end a’la vcvarsall.bat

10:13 <zao> *env

10:14 <zao> Haven’t tried building HPX on Windows for a while

10:14 <zao> And of course, silly software that assumes Windows==MSVC

10:14 <zao> *eyes HPX*

10:22 <Yorlik> I wished your CMake setup would just abstract it all away - the potential is there.

10:22 <Yorlik> There should really be only rare cases wher you really need a feature from a certain toolchain others cannot provide

10:24 <Yorlik> I personally believe cl + clang-cl on windows and gcc + clang/++ on *ix should really be supported by any crossplatform software. But that's just my personal pipe dream. We are going for LLVM, because we want to use the analysis tools provided there.

10:25 <Yorlik> It's simply too good to miss it.

10:26 <Yorlik> So - am I assuming correctly that clang will not build HPX on Linux?

10:36 <Yorlik> Hmm - the docs say Clang is supported - I think I need to dig deeper why it didn't work here

10:37 <Yorlik> Using version 7 should be ok ..

10:39 <zao> Should work well

10:39 <zao> A lot of projects test for the wrong thing for a system or compiler

10:40 <zao> Had a ton of that with Pathscale’s compiler which was clang front end with own backend, so no LLVM IR.

10:41 <zao> HPX tries to be good, patches welcome ;)

10:41 <zao> Be happy you’re not in BSDs like me ;)

10:42 <Yorlik> I'm using clang on windows inside a cmake project for VS

10:42 <Yorlik> I guess I'll figure it out.

10:43 <Yorlik> BTW- I fondly remember running Solaris and FreeBSD systems. Nothing against non-Linux *ix systems ... :)

10:43 <zao> Note that VS’s cmake is a weird fork that may diverge quite a lot from upstream CMake

10:43 <Yorlik> The weird thing was, that clkang-ck asked for a -c16 option

10:44 <zao> I would reckon that most people (read: me) use the proper one.

10:44 <zao> Odd

10:44 <Yorlik> I wonder if I just hit a limit in compatibility here.

10:44 <Yorlik> I can try to run with my Cmake 3.13 from the dev console

10:45 <zao> I’m out traveling so can’t test anything from here :(

10:45 <Yorlik> I don't understand why MS can't just support CMake above a certain version

10:45 <Yorlik> Sure - I'll dig.

10:46 <Yorlik> Argh - the different boost lib namings ....

10:47 <Yorlik> I wished everyone would just export targets

10:47 <Yorlik> No I have to rename or recompile oll the boost libs ..

12:10 <nikunj> Hey guys, we have OS course this semester and we've been given a project to add a scheduler policy to linux kernel (basically as a background scheduler). would adding the hpx thread scheduling policy be helpful?

12:12 <nikunj> or maybe something similar to it

12:34 <zao> Make a policy that silently favors my processes ;)

12:34 <nikunj> XD

12:35 <nikunj> zao, can't do. Won't be fair XD

12:36 <zao> Maybe look at if the scheduler deals with NUMA correctly or if there’s something there to be improved

12:37 <nikunj> zao, yes I'm looking into the code of cfs for any optimization possibilities

12:38 <nikunj> I'll look into NUMA based ones. That should make my project unique

12:41 <zao> I would guess that it may try to keep processes on the same core or hyperthread group

12:42 <zao> All I can come up with are joke schedulers :)

12:42 <nikunj> zao, xD

12:43 <nikunj> I'll look into NUMA aware schedulers to optimize parallel computations

12:44 <zao> Considering that hwloc has some bonding and cpusets there may already be some mechanisms. Or there is none and cpusets are needed

12:45 <zao> *binding

18:19 <K-ballo> apparently that massive debug size we just shed comes from the use of bind+lambda in the split gid continuation, multiplied by the combination of actions and arguments

18:26 <K-ballo> we had like a thousand instantiations

18:27 <K-ballo> 1156

18:37 <hkaiser> wow

18:43 <K-ballo> any other candidate us of bind+lambda ?

19:13 <hkaiser> shrug

19:14 <hkaiser> we have started to use lambdas not so far back, perhaps for the last 2 years

19:22 <K-ballo> the problem were the binders, those are rather expensive, and since the lambda yields a different type per instantiation that resulted in lots and lots of different bind instantiations