hkaiser changed the topic of #ste||ar to: The topic is '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/
<Yorlik>
Is hwloc still required to build HPX 1.4.0?
<Yorlik>
NVM . Docs still say yes....
<heller>
Yorlik: welcome back!
<Yorlik>
Heyo!
<heller>
Yorlik: yes, hwloc is a required dependency
<Yorlik>
I gues sthere still is a plan to get rid of it?
<simbergm>
Yorlik: we made it compulsory a few releases back because without it you end up with bad performance in most use cases
<simbergm>
is it a big pain for you?
<Yorlik>
no. I just built the latest. just wondering sionce it was told at some pont.
<Yorlik>
Just updating to boost 1.72 and hwloc 2.1.0
<Yorlik>
and hpx 1.4
<Yorlik>
I'm just wondering how they are building the windows version of hwloc - if they are using the msvc project in /contrib/windows or another method. We use the contrib project, but it's marked as experimental. So - my question also is fueled by a wish to have a "clean and official" way to build hwloc on windows.
<Yorlik>
We try to build all our dependencies ourselves. Even boost.
<Yorlik>
And not using vcpkg.
<zao>
I always just download the binaries from the official site.
<heller>
Yorlik: getting rid of hwloc was actually never planned. It was optional at some point, but we decided to make it compulsory
<zao>
Earlier papers might talk more about the partitioning I guess.
<heller>
Yeah, it's an octree which is rebalanced using a z-curve
<heller>
That is, every nth iteration, the leafs are refined, and during that refine step, we use a z-curve to iterate over the nodes, and fill up the localities node by node such that every locality has the same number of nodes
<heller>
The z-curve provides the mapping (x,y,z) -> index. And then it's trivial. The same can be done with a quadtree
<heller>
Yorlik: ^^
<Yorlik>
I was playing with the idea of using a hilbert curve, but the disadvantrage is, that every node then onbly has 2 neighbouzrs and we might get cascading effects
<Yorlik>
It's like the flipside of the coin
<Yorlik>
And we need to minimize moving around tiles
<heller>
Hilbert curve is just as nice
<heller>
And very similar
<Yorlik>
Hilbert actually has some very nice properties.
<Yorlik>
It minimizes borders
<heller>
The neighborhood relationship is orthogonal though
<Yorlik>
And every border is cross node chatter
<Yorlik>
I still wonder if we could use a decentralized system.
<heller>
Yes, but you can still have 4-8 neighbors, depending on your stencil
<Yorlik>
But probably it's not easy to avoid irregular shapes/rectangle composites
<heller>
You only need to provide the mapping (interpolation) to get to the right tile
<Yorlik>
?
<heller>
A Hilbert or z-curve is just a means to linearilize your tiles.
<Yorlik>
I know
<Yorlik>
But when the load in a node gopes up I can only push it to the left ir right
<Yorlik>
That might cause a cascade under high load - butr maybe its not a problem if you spawn new nodes soon enough
<Yorlik>
And have a very tolerant hysteresis of the system for spawning and despawning nodes.
<heller>
No, you divide your tile in four and regrid ;)
<heller>
It's easier when you are not dealing with real time problems :p
<Yorlik>
Dividing in four might break the hilbert/z-curve
<Yorlik>
Quadtree and binary partitioning might be better. Butr to minimize cross machine chatter you wann have cleanb island of high load
<Yorlik>
Cutting through the middle of a high load area wopuzld increase cross node chatter quite a bit
<heller>
So, in octotiger, the regridding/laod balancing is a global operation stopping the world
<Yorlik>
We would do this shadowed
<Yorlik>
So copy-sync-move players
<heller>
Sure
<heller>
Well, you need a trade of when computation time trumps the potential communication
<Yorlik>
Some sort of region growth from maxima might work as well as spac filling curvs
<Yorlik>
Its an interesting problem - I might end up writing a simulator in Javascript for it
<Yorlik>
Like a webpage
<Yorlik>
Some sliders and options.
<heller>
This requires that a tile in itself has a fairly high resolution such that there players on a border participate in the communication effort
<Yorlik>
Tiles will be like a screen size of a player, so ~20-100 virtual meters
<Yorlik>
visble tiles from another node will be mirrored
<heller>
Sure
<heller>
If all players in a tile participate in the communication, I'd assume that there's no sweet spot to split
<Yorlik>
We are trying to design everything to be latency tolerant - still ofc. we want to minimize cross tile chatter as mucvh as possible
<Yorlik>
Ideally I think we'd have islands around hot spots
<Yorlik>
Some sort of growth algorithm starting at maxima
<heller>
Sure, make up a model
<Yorlik>
I'll have to write a simulator for this, indeed.