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/ | GSoD: https://developers.google.com/season-of-docs/
hkaiser has quit [Quit: bye]
Amy1 has quit [Ping timeout: 252 seconds]
Amy1 has joined #ste||ar
<jbjnr_> Yorlik: you need not worry about me deleting code. HPX contains a lot of undocumented experimental hacks that people try, get working and then leave unmaintained. At some point this code needs to be consolidated into the coherent 'strategy' and API that makes sense and fits better to the long term goal of a standards complaint system that is easy to use and powerful enough to allow the power user to fine tune and maximize performance
<jbjnr_> Your use case overlaps with other requirements that we have and makes a good test case for creating something simple enough that you can use it, and exposes a part of something deeper we've been working on for some time
<Yorlik> That mixing in of experiments makes it ofc sortof more difficult for end users. The more we need documentation in terms of what is supported / considered part of te stable API and what not.
<Yorlik> Experimental features should remain undocumented or better marked as experimental, subject for possible removal.
<jbjnr_> yes. I'd like to move some of the experimental features into the main api. Then you can document them for me :)
<jbjnr_> (joke)
<Yorlik> I try to document what I use. That's the most efficient and useful way how I can give sth. back, I believe. And yes - In general i hate documenting too. I just do it out of necissity and because my memory is a mesh full of holes. :)
<Yorlik> Spent the whole night researching spatial indexing and partitioning. I realized I need to implement this soonish. Thinking about R-Trees, Hilbert Curves or any other efficient clustering algorithm.
<Yorlik> After all space coordinates will dictate which Component lives on which locality.
<Yorlik> Hilbert Curves I think might be interesting for load balancing since they map 2D space (Could be easily extended to 3D) to 1D space.
<Yorlik> Not sure how performant the calculations are though.
<jbjnr_> if you have a lot of objects that move around, you will probably find using a tree with buckets easier that using a space filling curve (SFC) index directly. You can create buckets and use the SFC index to address them, but a quad/oct tree might be easier to manage.
<jbjnr_> You could even reuse the oct-tree from octotiger!
<jbjnr_> bbiab
<Yorlik> We were thinking about using tiles of about 16*16 meter as a lowest level unit
<Yorlik> So making a map of 160*160 km would be like 10.000*10.000 tiles. Data to translate xy coordinates into hilbert index would be like 1.6 GB when cached 100%. I know it sounds crazy .... Just plaing with ideas. Translating between hilbert and xy coordinates would be just a table lookup. And load balancing between localities could be done along the Hilbert curve.
<Yorlik> So - a bucket would be 16*16 m - most of them empty ofc.
<Yorlik> Not sure what would be best for crowded areas - which are always the big problem.
<Yorlik> Inactive parts of the map (no players) could be saved on disk, so probably MUCH less than 1.6 GB for that crazy index
<Yorlik> And the size I projected is also insane.
<Yorlik> Still - 1.6 BG is a lot , but not THAT m,uch
<Yorlik> And that would be for the entire cluster
<Yorlik> However - time to get some sleep ...
* Yorlik heads out
<jbjnr_> (Yorlik: you do not need a lookup table to convert coords to hilbert space or vice versa - its a function that converts coords)
<Yorlik> How fast is it?
<Yorlik> The implementation I saw had a scary loop in it
<jbjnr_> I have not looked at the calculation, but probably a function of the recursion depth - so log2(scale)
<jbjnr_> (guessing)
<Yorlik> I need to cinsidr the options - probably I'll just start something simple and use it to develop the API.
<Yorlik> However - need to flee the machine and sleep - totally sleep griefed.
* Yorlik flees the grid ..
rori has joined #ste||ar
<zao> Yorlik: Sounds like the work I did on reversing a toy crypto algorithm. At one point I had a complete lookup table for 32-bit `(x * x) mod n`.
<zao> Let's just say that it wasn't exactly worth it :D
<simbergm> jbjnr_: just merged #4025
<simbergm> thanks for reviewing
hkaiser has joined #ste||ar
<hkaiser> K-ballo: yt?
<K-ballo> hkaiser: here
<hkaiser> K-ballo: remember when you replaced boost::shared_ptr?
<K-ballo> yes
<hkaiser> you left it in place in the plugin stuff
<K-ballo> yes
<hkaiser> was that because std::shared_ptr does not always support deleters?
<K-ballo> I opened an LWG issue for that, std::shared_ptr<FunctionType> is required to work but some implementations don't want to (msvc)
<hkaiser> they do now
<hkaiser> ok, so we could add a feature test
<hkaiser> I would like to remove it there as well
<K-ballo> sure, if it works
<K-ballo> else it can be rewritten with a wrapper, but it is non trivial
<K-ballo> and the plugin code is not particularly nice to work with
<hkaiser> yah, I know
Yorlik has quit [Ping timeout: 245 seconds]
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
hkaiser has joined #ste||ar
diehlpk has joined #ste||ar
aserio has quit [Ping timeout: 276 seconds]
aserio has joined #ste||ar
aserio has quit [Ping timeout: 276 seconds]
diehlpk has quit [Ping timeout: 276 seconds]
Yorlik has joined #ste||ar
rori has quit [Quit: bye]
aserio has joined #ste||ar
<nikunj> hkaiser: yt?
<hkaiser> hey nikunj
<nikunj> hkaiser: I was filling the reproducibility thingy and I have a few questions
<hkaiser> ok
<nikunj> firstly, is this fine for experiment summary: We ran artificial work loads and 1d stencil based benchmarks on a single haswell node of NERSC's Cori supercomputer with Boost version 1.70.0, binutils version 2.32, google perf tools version 2.7 and HPX version 1.3.0. Both Boost and HPX were built using gcc 8.3.
<hkaiser> nod
<nikunj> alright
<hkaiser> the bash script you have to run will output that information, I believe
<nikunj> next, do you use my scripts in the pull request?
<nikunj> the one you created for hpx
<hkaiser> I don't use them, I just copied them
<nikunj> so we do have the scripts there right?
<nikunj> also should I create another repository with scripts and all the data that I retrieved?
<hkaiser> this link will change once we merge things, though
<nikunj> we can use that for links
<hkaiser> nikunj: might be a good idea if we created that
<nikunj> I think the same. It will reduce the amount of work for me as well.
<hkaiser> I'll create a repor hpxr_data
<nikunj> sounds good
<nikunj> do I have access to the repo?
<nikunj> I'll push to master directly then
<hkaiser> ok
<hkaiser> nikunj: do you have the latex template for the appendix?
<hkaiser> or how do you create it?
<nikunj> hkaiser: we use the online form and fill it
<nikunj> it is not asking me for any templates of any sort
<nikunj> a few questions regarding reproducibility followed by links
<hkaiser> ahh ok
<hkaiser> how is this then associated with the paper?
<nikunj> It asks for the title of the paper and it's author
<nikunj> that's how it links the appendix to the paper
<hkaiser> k
<nikunj> it was also asking for abstract so I used the abstract from the full paper we had in the repo
<nikunj> and then it uploads our paper as well
<nikunj> finally it asks for the artifacts. I will check all as author-created maintained in public repository under an OSI-approved license and provide the link of that repo
<nikunj> that will have both the scripts and the results we achieved
<nikunj> lol it was just a normal form not meant for submission
<nikunj> didn't read that bit at the top
<nikunj> hkaiser: I don't see any reproducibility appendix thingy anywhere in my account. How do I get there?
<hkaiser> nikunj: we could attach it as an appendix to our paper
<hkaiser> do you have a pdf for that?
<nikunj> no I do not
<nikunj> adding appendix would increase the size of the paper, would that still be acceptable?
<hkaiser> could you ask Keita, pls?
<nikunj> alright let me ping him with this
<parsa> nikunj, hkaiser: maybe your workshop doesn't want the appendix if they haven't provided a template or a field in the upload page
<hkaiser> parsa: they told us to submit it anyways
<nikunj> parsa: they didn't provide anything as such in the upload page
<parsa> my old paper from last year used the tex template. here it is in case it helps: https://github.com/STEllAR-GROUP/documents/blob/master/papers/PAW-ATM_SC2018/sections/appendix.reproducibility.tex
<nikunj> hkaiser: I've pinged keita with the issue, let's see what he has to say
<hkaiser> ok, thanks
<nikunj> hkaiser: about porting to c++11, do you have any solution for indexed_sequence?
<hkaiser> it's in hpx/datastructures/detail/pack
<hkaiser> it's in hpx/datastructures/detail/pack.hpp
<nikunj> hkaiser: just received a msg from keita. He will talk to the organize chair and reply
<hkaiser> <root>/libs/datastructures/include/hpx/datastructures/detail/pack.hpp
<hkaiser> index_sequence<...> == pack<...>, and make_ndex_sequence<...> == make_index_pack<...>
<nikunj> alright let me fix it
hkaiser has quit [Quit: bye]
aserio has quit [Ping timeout: 276 seconds]
hkaiser has joined #ste||ar
<Yorlik> hkaiser: yt? If you can afford time I'd be ready to continue on the Macro Documentation. I prepared some stuff to just quickly fill in properties.
aserio has joined #ste||ar
aserio has quit [Quit: aserio]
<hkaiser> Yorlik, I'll have to leave soon, sorry - perhaps a bit later (however then it's probably too late for you)
<Yorlik> I'm around - having a shifted rhytrhm these days.
<Yorlik> Just poke me. :)
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<hkaiser> Yorlik: ok, will do
<Yorlik> Reading "R-Trees: Theory
<Yorlik> and Applications" in the meantime .. :)
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar