aserio 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/
Matombo has quit [Remote host closed the connection]
Rodario1 has quit [Ping timeout: 240 seconds]
Matombo has joined #ste||ar
Matombo has quit [Remote host closed the connection]
Matombo has joined #ste||ar
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 260 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 248 seconds]
hkaiser has joined #ste||ar
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 260 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 240 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 240 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 248 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 240 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 264 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 240 seconds]
parsa has joined #ste||ar
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 248 seconds]
diehlpk has joined #ste||ar
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 248 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 240 seconds]
mcopik has joined #ste||ar
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 240 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 240 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 240 seconds]
Rodario has joined #ste||ar
mcopik has quit [Ping timeout: 252 seconds]
Rodario1 has quit [Ping timeout: 248 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 255 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 252 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 248 seconds]
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 252 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 255 seconds]
mcopik has joined #ste||ar
EverYoung has joined #ste||ar
Rodario has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
<jbjnr>
anyone in?
<jbjnr>
i have a question ...
Rodario1 has quit [Ping timeout: 240 seconds]
<zao>
I'm here, but sans answers :)
<jbjnr>
yeah, it's a philosophical hpx question ...
Rodario has quit [Ping timeout: 248 seconds]
Rodario has joined #ste||ar
<hkaiser>
jbjnr: here
<diehlpk>
here
<diehlpk>
I like philosophical questions
<diehlpk>
jbjnr, Waiting for your question
Rodario1 has joined #ste||ar
<jbjnr>
for the numa allocator, we need to pass a nodeset to hwloc - to tell it which numa domains we wish to bind our memory to. That's ok. Currently we have the concept of a target - and target can give us a list of numa nodes. that's fine too. but I want to get the numa nodes used by my pool only, not all of them. So I should use hpx::compute::host::target::numa_nodes(pool name or id) - or would...
<jbjnr>
...it be better to just go to the resource partitioner and get the nodes from there. my instinct is to use the RP as it knows the pools and the cores/domains used - but the target abstraction could be extended to pools. Who wants to discuss this?
Rodario has quit [Ping timeout: 248 seconds]
<jbjnr>
do we extend target to include pols - or do we extent RP to include targets?
<jbjnr>
^pools
<jbjnr>
hpx::compute::host::target::pool::
<hkaiser>
a target could represent a pool, yes
<hkaiser>
conceptually a target is representing a 'place' where things run, so why not a pool
<jbjnr>
so we could call hpx::compute::host::get_target(pool_name)
<jbjnr>
etc etc
<hkaiser>
right
<jbjnr>
good. that's nice
<hkaiser>
jbjnr: the only problem I see is that we construct not only executors from a target but also allocators
<hkaiser>
we would have to find a way to build an allocator from a pool
<jbjnr>
that's what I'm doing now
<jbjnr>
I need an allocator for the pool
<hkaiser>
nod
<hkaiser>
if you think that's possible - go for it
<jbjnr>
but the bitmap of numa domains needs to come from somewhere and the RP knows. Extending targets to be pools, should work nicely
<hkaiser>
fits nicely into the rest of it and does not require anybody to fiddle with hwloc or a wrapper thereof
<jbjnr>
(actually, the pool knows and the RP by extension)
<jbjnr>
or vice versa
<hkaiser>
the rp 'own' the resources, pools are just allowed to access them
<jbjnr>
(somhow we need to consolidate the rp and the targets code - I saw the issue about making the stream benchmark work with RP and I'm thinking about it)
<hkaiser>
yes
<jbjnr>
^^yes
<hkaiser>
targets are an abstraction allowing to represent a 'place' - to be used for constructing executors and allocators
<hkaiser>
they down own anything
<jbjnr>
ok
<hkaiser>
otoh
<jbjnr>
target will be windw into pool
<hkaiser>
aren't pools just executors?
<jbjnr>
not quite - they own stuff
<hkaiser>
they don't
<hkaiser>
what do they own?
<jbjnr>
cores/threads
<hkaiser>
no
<hkaiser>
they are allowed to use certain cores
<hkaiser>
the rp 'owns' them
<jbjnr>
fair enough
<hkaiser>
but ok, let's not conflate pools with executors
<jbjnr>
in RP, maybe we should rename pools to tagets, to avoid having multiple ways of thinking about it
<hkaiser>
then those would have to represent allocators as well
<hkaiser>
a target is a set of resources to be used
<hkaiser>
pus + memory
<hkaiser>
pools represent pus only
<jbjnr>
<cough>
<hkaiser>
you disagree
<hkaiser>
?
<jbjnr>
well. I want to use a pool that 'owns' a numa domain to give me a numa mask so that I can tell hwloc to give me memory from that memory controller
<jbjnr>
so in this sens the pool can 'use' memmory if not own it
<hkaiser>
the pool knows what its running on, yah
<hkaiser>
anyways, just add a get_target(pool_name)
<jbjnr>
so I need a numa allocator that takes a pool description to give me the right numa nodes
<jbjnr>
I think we can just think of a pool as being a special kind of target and all will work out
<jbjnr>
yes^
<hkaiser>
the pool should be able to give you the same hierarchy of numa/cores/pus as the rp
<jbjnr>
exactly
<hkaiser>
didn't you say that having that hierarchy is the penultimate way of representing things?
<jbjnr>
we should be able to move the custom_pool_exector to be a target exector
<jbjnr>
executor^
<hkaiser>
k
<hkaiser>
fine by me
<jbjnr>
ok. I work on this
<hkaiser>
cool
<jbjnr>
the target executors that work on nume domains should be removed and replaced with pools really
<hkaiser>
fine by me
<hkaiser>
was a quick-hack anyways
<jbjnr>
it shows
<jbjnr>
:)
<hkaiser>
jbjnr: tell heller - it's his invention
Rodario has joined #ste||ar
Rodario1 has quit [Ping timeout: 255 seconds]
Rodario1 has joined #ste||ar
Rodario has quit [Ping timeout: 240 seconds]
Rodario1 has quit [Quit: Leaving.]
EverYoung has joined #ste||ar
parsa has quit [Quit: *yawn*]
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]