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/
<gnikunj[m]> hkaiser: here is a short snippet of code in HPX that reproduces the same compiler log: https://gist.github.com/NK-Nikunj/4579df4514039979b5ae01d9815395fa
<gnikunj[m]> also, writing executors is really easy!
<hkaiser> gnikunj[m]: ok, thanks!
<gnikunj[m]> hkaiser: I updated the code again just now
<hkaiser> gnikunj[m]: I'll have a look tomorrow
<gnikunj[m]> ohh ok. I'll sleep too then ;)
hkaiser has quit [Quit: bye]
jehelset has joined #ste||ar
<ms[m]> gnikunj: indeed it doesn't, it has parallel for, reduce, and scan (and some tasky stuff)
<ms[m]> that's one of the reasons hpx-kokkos exists
<ms[m]> but the async_execute in kokkos executors is mostly for some sort of completeness, even the bulk_async_execute... they exist mainly for customizing the hpx parallel algorithms
<ms[m]> note how async_execute is implemented in the kokkos executors
<gonidelis[m]> ms[m]: any chance we could reinitiate the build-and-test ? https://github.com/STEllAR-GROUP/hpx/pull/5125
<ms[m]> gonidelis[m]: done, let's see what it says
<gonidelis[m]> ms[m]: thanks!
<ms[m]> also note the deprecation warnings e.g. here: https://cdash.cscs.ch/buildSummary.php?buildid=142680 (not sure if those are ones that need to be changed or ignored)
<gonidelis[m]> ms[m]: i actually was working on them right now
<ms[m]> looks like builds have been starting ok after those failures you saw, so I'm assuming it'll go on just fine; let me know if it doesn't
<gonidelis[m]> at first I thought that these should remain as is. but then I realised that the ranges overloads do support projections so I am moving them to the container tests right now ;)
<gonidelis[m]> ms[m]: sure
<gonidelis[m]> i mean... there is no local parameter defined
<gonidelis[m]> it just "passes the type". Is it because it wants for the lambda expression to be aware of the type in order to use it as a return type?
<ms[m]> gonidelis[m]: do you mean why does it take a parameter as opposed to not taking any parameters?
<gonidelis[m]> ms[m]: yes...
<ms[m]> because that's what a projection is, it transforms one thing into another, but that doesn't mean it has to use the first thing at all
<gonidelis[m]> so it transforms a const-ref to a ref?
<ms[m]> references are unrelated to it
<ms[m]> it could take by value and return by value as well
<gonidelis[m]> but isn't `DataType const&` param a const ref?
<ms[m]> yes... are you talking about projections in general or that particular projection?
<gonidelis[m]> that particular one
<ms[m]> it takes something by const reference and returns a (non-const) reference to something else
<gonidelis[m]> ok thanks. that's what i expected. so the point of not declaring `DataType const& a` as param is because it won't use `a` at all?
<ms[m]> gonidelis[m]: exactly
<gonidelis[m]> someone should tell the standardization guys to rename `remove_copy` to `copy_if_not` ... it sounds like it is just creating more confusion
<gonidelis[m]> K-ballo:
hkaiser has joined #ste||ar
<srinivasyadav227> Scanning dependencies of target template_function_accumulator_component
<srinivasyadav227> [ 65%] Building CXX object examples/accumulators/CMakeFiles/template_function_accumulator_component.dir/template_function_accumulator.cpp.o
<srinivasyadav227> c++: fatal error: Killed signal terminated program cc1plus
<rori> which compiler version
<rori> ?
<ms[m]> and more importantly... how much memory? that looks like what usually happens if you run out of memory
<ms[m]> retry with make (-j1)
<gnikunj[m]> freenode_srinivasyadav227[m] looks like it's triggered because you were out of memory. It is recommended that your build system should have at least 2gb per thread. So if you do make -j6, you should have at least 12gb ram available. If you do a make -j, you should have $(nproc)*2 ram available.
<rori> hkaiser: see pm please :)
<gnikunj[m]> Try doing a simple make and see if that makes it work for you.
<ms[m]> note: make -j is the system-killer (it doesn't actually limit the number of jobs to nproc, it just spawns as much as the dag allows)
<gnikunj[m]> ms didn't know it didn't restrict to nproc.
<ms[m]> ninja without the -j flag does exactly that by default
<ms[m]> I've killed login nodes with make -j and hpx...
<srinivasyadav227> <ms[m] "and more importantly... how much"> yea actually docker container running with 2GB memory..so I should I have at least 4GB right with make -j2?
<srinivasyadav227> now I am doing simple make..so far its working fine 72 % done
<gnikunj[m]> have 4gb and do make -j1
<srinivasyadav227> okay! currently its running simple make (2GB), once done I will change to 4GB and do make -j1
shahrzad has joined #ste||ar
jehelset has quit [Remote host closed the connection]
bita has joined #ste||ar
shahrzad_ has joined #ste||ar
shahrzad has quit [Read error: Connection reset by peer]
<gonidelis[m]> hkaiser: do you think #5125 is ok now?
<hkaiser> gonidelis[m]: need to look again
<gonidelis[m]> ok sure
<gonidelis[m]> np ;)
<hkaiser> gonidelis[m]: feel free to start working on other things already
<gonidelis[m]> hkaiser: i have already done so ;)
<gonidelis[m]> is it me or this test is not called at all?
<gonidelis[m]> hkaiser: ^^
<hkaiser> shrug
<gonidelis[m]> weird
<bita> hkaiser, meeting?
<hkaiser> bita: sorry, can't make it
bita has quit [Ping timeout: 240 seconds]