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/
vamatya has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
mcopik has quit [Remote host closed the connection]
hkaiser has quit [Read error: Connection reset by peer]
eschnett has joined #ste||ar
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
vamatya has quit [Ping timeout: 240 seconds]
K-ballo has quit [Quit: K-ballo]
parsa has joined #ste||ar
jfbastien_ has quit [Ping timeout: 248 seconds]
thundergroudon[m has quit [Ping timeout: 240 seconds]
parsa has quit [Quit: Zzzzzzzzzzzz]
thundergroudon[m has joined #ste||ar
david_pfander has joined #ste||ar
bikineev has joined #ste||ar
bikineev has quit [Ping timeout: 248 seconds]
bikineev has joined #ste||ar
<github>
[hpx] sithhell created throttle_cores (+2 new commits): https://git.io/v5wnv
<github>
hpx/throttle_cores ed72bb5 Thomas Heller: Merge remote-tracking branch 'origin/fix_rp_again' into throttle_cores
<github>
hpx/throttle_cores 8abb710 Thomas Heller: Fixing RP to enable resource throttling...
<heller>
jbjnr: ^^ just commited my changes
Matombo has joined #ste||ar
bikineev has quit [Remote host closed the connection]
david_pfander has quit [Ping timeout: 246 seconds]
K-ballo has joined #ste||ar
mcopik has quit [Ping timeout: 246 seconds]
mcopik has joined #ste||ar
david_pfander has joined #ste||ar
hkaiser has joined #ste||ar
<jbjnr>
hkaiser: error: no member named 'unwrapped' in namespace 'hpx::util'; did you mean 'unwrapping'?
<jbjnr>
do I want unwrapping?
<hkaiser>
yes
<hkaiser>
jbjnr: unwrapped has been split into unwrap and unwrapping, depending on the use case
<jbjnr>
thanks
eschnett has quit [Quit: eschnett]
pree has joined #ste||ar
pree has quit [Remote host closed the connection]
pree has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
eschnett has joined #ste||ar
parsa has joined #ste||ar
pree has joined #ste||ar
<heller>
is there a way to get the thread pool on which I am running on?
<heller>
hpx::get_worker_thread_num() returns the local thread number, I have two pools, and I need the global one to figure out which numa domain I am running on
<heller>
more precisely, I need a way to figure out on which numa node I am currently on
<heller>
another question: Is the pool location being preserved when I just do something like "hpx::async([](){});"
<heller>
no it is not :/
<heller>
it all ends up on the default_pool
akheir has joined #ste||ar
aserio has joined #ste||ar
patg[[w]] has joined #ste||ar
<patg[[w]]>
aserio: is there a meeting today?
<jbjnr>
heller: if you use async() withoua pool executor, it does on default poolt
<aserio>
patg[[w]]: There is no Operation Bell Meeting today
<jbjnr>
if you want to know which pool you are on at the moment, we should add an api call
<patg[[w]]>
aserio: ok thanks
<jbjnr>
inside the scheduler, we know, but inside the task we do not
<jbjnr>
so we'd need to add get_current_pool to RP and we can use the global thread number to lookup the pool
<jbjnr>
heller: default bool - backwards compatibility. was first major checkin. Probably a decent default would be spawn task on same pool as current task unless otherwise requested.
<heller>
Yes, I agree
<jbjnr>
^yes saner option, easy to fix if we want
<heller>
Already did
<jbjnr>
ok
<heller>
Will have to check the global vs local nonsense once more
<heller>
Overall, I'm pretty happy though
<heller>
One pool per numa domain is giving nice results for me so far
patg[[w]] has joined #ste||ar
david_pfander has quit [Ping timeout: 252 seconds]
zbyerly_ has quit [Ping timeout: 240 seconds]
<jbjnr>
K-ballo: is there a code snippet in hpx somewhere I can reuse that would move a list of variadic args into a tuple, so that I can later use them for async?
parsa has quit [Quit: Zzzzzzzzzzzz]
<K-ballo>
auto tup = make_tuple(...) on one side, for decaying the arguments.. then move(tup) whenever it is used
<K-ballo>
there might be something along those lines in the parallel algorithm implementations
<K-ballo>
the "task" algorithms, the other policies would just forward, not decay
<K-ballo>
jbjnr: do you want to expand the tuple when calling async?
<jbjnr>
K-ballo: thanks. yes, I will need to call func_1(...) and store the args in a vector of tuples, then in func_2, I will need to pass all the tuples though. I might not need to expand them, not sure yet until I work out what I want to do
<jbjnr>
similar to queiing tasks up for later exec
<K-ballo>
deferred_call ?
<jbjnr>
essentially yes
<K-ballo>
why essentially and not exactly?
<jbjnr>
we want to queue N tasks, and then send them to cuda instead of to hpx::async
<jbjnr>
so it's the same mechanism sort of, but instead of N tasks, we need an array of tasks we can spawn in one go (or something like that)
<jbjnr>
haven't really got that far yet, but wanted to work on the mechanism
<jbjnr>
to store the args in a std::array<arg_tuple,N> until later
<jbjnr>
(or siimilar if array is no good)
<jbjnr>
but all args need to be sent to gpu, so an array might be nice
<K-ballo>
so close to array<deferred_call, N> but without storing the function object separately for each element
<jbjnr>
great yes
<K-ballo>
a slightly more general answer, if the arguments are guaranteed to stay alive then the argument tuple pack is whatever forward_as_tuple return, if they don't as is the case for async calls then make_tuple is needed for decaying those arguments
<K-ballo>
when is time to execute the task, on either case, invoke_fused(fun, move(tuple)) is the easiest way
<K-ballo>
invoke_fused explodes the tuple and passes the elements as arguments to a callable
<jbjnr>
wow. nice.
<jbjnr>
ok thanks very much. I will now play for a bit with those ideas
<K-ballo>
deferred_call packages all that up for just one call, so if in doubt go look under its covers
<jbjnr>
yes thanks. In fact for the cuda call, I might just want to pass an array of tuples and not expand them, no real need to use them as args. I will look
<jbjnr>
heller: does cuda support tuples - do I have to use thrust headers for those?
<K-ballo>
hpx::util::tuple is littered with HPX_HOST_DEVICE and even some __CUDACC__ workarounds
jaafar has joined #ste||ar
hkaiser has joined #ste||ar
<diehlpk_work>
hkaiser, I shortend the introduction for the paper. Can you read the introduction and chnage things you like to have changed.
jaafar has quit [Ping timeout: 248 seconds]
parsa has joined #ste||ar
<heller>
jbjnr: yes, tuple is supported
<jbjnr>
variadic ones?
david_pfander has joined #ste||ar
parsa has quit [Quit: *yawn*]
<heller>
jbjnr: sure thing
<heller>
jbjnr: invoke is supported as well
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
bikineev has joined #ste||ar
aserio has quit [Ping timeout: 240 seconds]
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
Matombo has quit [Remote host closed the connection]
<jbjnr>
hkaiser: undefined reference to `hpx_exported_plugins_list_hpx_factory' - any idea what I'm missing. some macro ....
<heller>
jbjnr: debug vs. release build
<jbjnr>
balls. thanks
vamatya has joined #ste||ar
<pree>
Why tasks that are created and executed with the help of executors(service) are run in OS-threads not in HPX-thread. whether this is true only for service executors or for all executors (sequenced& parallel)
<pree>
Thanks
<heller>
only for the service executors
<pree>
Could you kindly explain why ?
Matombo has joined #ste||ar
pree has quit [Remote host closed the connection]
pree has joined #ste||ar
pree_ has joined #ste||ar
<heller>
pree: the service executor is used for blocking network calls. those are not executed on a HPX thread
pree has quit [Ping timeout: 240 seconds]
pree__ has joined #ste||ar
pree_ has quit [Ping timeout: 240 seconds]
hkaiser has quit [Ping timeout: 248 seconds]
pree__ has quit [Ping timeout: 240 seconds]
pree__ has joined #ste||ar
hkaiser has joined #ste||ar
pree__ is now known as pree
<pree>
heller : thanks : )
<github>
[hpx] hkaiser force-pushed fixing_2885 from 7eac243 to 67af823: https://git.io/v5V1P
<github>
hpx/fixing_2885 67af823 Hartmut Kaiser: Adapt broadcast() to non-unwrapping async<Action>...
Matombo has quit [Read error: Connection reset by peer]
Matombo has joined #ste||ar
Matombo has quit [Remote host closed the connection]
hkaiser has quit [Quit: bye]
Matombo has joined #ste||ar
bikineev has quit [Ping timeout: 252 seconds]
aserio has joined #ste||ar
Matombo has quit [Remote host closed the connection]
<heller>
mcopik: no idea there. There are no docs on how marshalling is handled
<hkaiser>
heller: yah, we should move things like octotiger off our circleci account
<hkaiser>
somebody has enabled full Vc tests in the octotiger scripts
<hkaiser>
luckily that times out after 2 hours
<hkaiser>
aserio: yt?
zbyerly_ has quit [Ping timeout: 240 seconds]
<mcopik>
heller: but won't a lack of specialization for e.g. cuda_copyable_pointer_tag_to_host lead to an obviously wrong call to std::copy?
<heller>
Yes
<heller>
What would you suggest?
akheir has quit [Remote host closed the connection]
<hkaiser>
well, for a start disable the Vc tests
<hkaiser>
heller: ^^
<aserio>
hkaiser: yes
<aserio>
sorry
<hkaiser>
aserio: np
<hkaiser>
is Rohid still around?
<aserio>
I can check
<hkaiser>
Rod*
StefanLSU has quit [Quit: StefanLSU]
<aserio>
He is still here
<aserio>
does he have IRC
<aserio>
or should I tell him to check his email?
<mcopik>
heller: would you consider having a static assert or anything similar to disallow the user to use a non trivially copyable type T for compute allocator? I think it's better than a segfault
<mcopik>
I'm asking since I'm genuinely surprised
<hkaiser>
aserio: just tell him to look at his circleci stuff ;)
<aserio>
hkaiser: he said that he thinks he knows what the issue is
<hkaiser>
:D
david_pfander has quit [Ping timeout: 252 seconds]
patg[[w]] has quit [Quit: Leaving]
rod_t has joined #ste||ar
jaafar has quit [Ping timeout: 248 seconds]
StefanLSU has joined #ste||ar
StefanLSU has quit [Client Quit]
EverYoun_ has joined #ste||ar
StefanLSU has joined #ste||ar
EverYoung has quit [Ping timeout: 255 seconds]
StefanLSU has quit [Client Quit]
aserio has quit [Quit: aserio]
rod_t has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rod_t has joined #ste||ar
Matombo has quit [Remote host closed the connection]
rod_t has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mbremer has quit [Quit: Page closed]
EverYoun_ has quit [Remote host closed the connection]
bikineev has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 255 seconds]
parsa has joined #ste||ar
<parsa>
hkaiser: ping
<hkaiser>
parsa: here
<parsa>
hkaiser: can you take a quick look at my paper's abstract and conclusion sections?
<hkaiser>
parsa: in the repo?
<parsa>
yeah
<hkaiser>
will do
<hkaiser>
parsa: doesn't compile for me
<parsa>
i can compile on mac and windows and the pdf is right there in the repo with the code
<hkaiser>
parsa: got your pdf
<hkaiser>
parsa: an abstract should contain 3 parts: problem statement, solution applied, and results
<hkaiser>
your abstract is more of an introduction
<hkaiser>
also, why are the conclusions come before section 4.2 etc.?
<parsa>
what do you mean? the conclusions section is section 6 on page 9
<hkaiser>
not in the pdf you linked
<hkaiser>
ok, nvm, my fault
<hkaiser>
parsa: let's talk tomorrow about the paper
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<parsa>
hkaiser: okay, what time would be convenient?
<hkaiser>
any tim
<hkaiser>
e
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
rod_t has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]