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/
jaafar has quit [Ping timeout: 240 seconds]
gedaj has quit [Read error: Connection reset by peer]
gedaj has joined #ste||ar
hkaiser has quit [Quit: bye]
patg has quit [Quit: See you later]
gedaj has quit [Quit: Leaving]
gedaj has joined #ste||ar
gedaj has quit [Client Quit]
gedaj has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
<github>
[hpx] hkaiser force-pushed local_new_fallback from 4ff1464 to 6fec0a9: https://git.io/vFI3A
<github>
hpx/local_new_fallback 6fec0a9 Hartmut Kaiser: Fall back to creating local components using local_new...
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 258 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 255 seconds]
EverYoun_ has quit [Client Quit]
<parsa>
hkaiser: when phylanx and any one the test apps are linked with mkl or openblas on windows, they seem to run without doing anything... even hpx doesn't start
<hkaiser>
lol
<hkaiser>
parsa: you need to make sure to link with the single-threaded version of mkl
<parsa>
i assumed sequential is single threaded (only other options are parallel and cluster)
<hkaiser>
nod, correct
<parsa>
well this is awful... i don't even have a clue where to look
<hkaiser>
let's debug this...
jaafar has joined #ste||ar
<github>
[hpx] hkaiser force-pushed local_new_fallback from 432d26d to 13880dd: https://git.io/vFI3A
<github>
hpx/local_new_fallback 13880dd Hartmut Kaiser: Fall back to creating local components using local_new...
<github>
[hpx] hkaiser deleted client_base_registration at 204a1a5: https://git.io/vFLuu
wash has quit [Quit: leaving]
<github>
[hpx] K-ballo created then-fwd-future (+1 new commit): https://git.io/vFLzt
<github>
hpx/then-fwd-future b5a3c9c Agustin K-ballo Berge: Forward future used with .then() to continuation
<K-ballo>
^ did that but I doubt is the right approach, might be better to always pass rvalue futures to the continuation even if it implies extra refcounts for shared future
<github>
hpx/master 0ad76de Hartmut Kaiser: Adding closed tickets to docs
gedaj has quit [Quit: leaving]
gedaj has joined #ste||ar
wash has quit [Quit: leaving]
wash has joined #ste||ar
ct-clmsn has joined #ste||ar
<ct-clmsn>
hkaiser: where did you want the preliminary tree code?
<ct-clmsn>
hkaiser: there isn't much available at the moment, i'm going through the kurt implmentation and filling in missing methods
<hkaiser>
ct-clmsn: anywhere you like
<ct-clmsn>
@hkaiser: completely unrelated question - if ya'll were to provide collectives, would those be provided as algorithms over data structures or something more runtime-level?
mbremer has joined #ste||ar
<hkaiser>
ct-clmsn: we have some of the collectives
<hkaiser>
they are currently control-structures, unrelated to data
<ct-clmsn>
@hkaiser: ah so in parcelport? i saw the allgather in examples
<hkaiser>
those are not related/connected to parcelports
<hkaiser>
but it might be beneficial to tie thm into the parcelports to take advantage of functionalities in the network layer
<hkaiser>
ct-clmsn: btw
<hkaiser>
ct-clmsn: the stack-overflow detection you contributed - it also kicks in for 'real' segfaults
<hkaiser>
would you see a way to distinguish those cases?
<hkaiser>
it's currently producing misleading error messages ...
<ct-clmsn>
@hkaiser: ah they're in the lcos. now that's an interesting issue, will look into it
<hkaiser>
ct-clmsn: yah, lcos - we don't have a full set of collectives, though - we miss allgather, scatter, alltoall, possibly more
<heller>
Hmm, I'm still not sure if the parcelport is really the right place
<hkaiser>
heller: not sure either...
<heller>
But it really depends on which route we want to go
EverYoung has joined #ste||ar
<ct-clmsn>
@hkaiser: cool, that might be something i'll look into when after this matrix stuff is complete - blaze is pretty comprehensive
EverYoung has quit [Remote host closed the connection]
<heller>
I looked into the stuff that John mentioned the other day
EverYoung has joined #ste||ar
<heller>
A library "close to the metal" for collectives for mpi from ethz
<ct-clmsn>
@heller: something like gasnet?
<heller>
There really isn't a lot that takes advantage of any hardware. All software tree based. Which is exactly what we do as well
<ct-clmsn>
@heller: well, maybe not gasnet exactly...
<heller>
Really depends...
<heller>
We have components, which is a far more dynamic thing then a set of network endpoints to talk to
<heller>
People tend to don't like that
<ct-clmsn>
@heller: rgr
<hkaiser>
heller: because that's something nobody else has
<heller>
Because it sounds scary and too much overhead. At the end of the day, it's exactly the same
<hkaiser>
nod
<hkaiser>
people are not used to think it terms of objects
<heller>
Yes
<ct-clmsn>
@hkaiser: so the signal handler that manages coroutine overflows is registered to the process-level segfault signal SIGSEGV will see if there's anyway to mask it
<heller>
So I'm pretty sure it does not belong into the parcelport ;)
<heller>
What we'd need is to define proper communicators or similar
<ct-clmsn>
@heller @hkaiser so lcos
<ct-clmsn>
for collectives?
<heller>
The basename thingy is a nice start there, but not really nice to use our enough
<heller>
ct-clmsn: yes, in my book at least
<heller>
Based on proper communicators we can have all those nice and fancy collectives people want
<heller>
With same or better performance
<hkaiser>
ct-clmsn: you might have to look whether the 'segfault' occurred near the current stack frame
<hkaiser>
nod
<hkaiser>
just don't call then 'communicators' ;)
<ct-clmsn>
@hkaiser: i could look at the address of the context that was created and see if it matches the context that was attached to the signal handler as an arg
<ct-clmsn>
pardon
<ct-clmsn>
@hkaiser: the context that threw the signal handler vs the context registerd in the overflow hndler
<ct-clmsn>
handler
<hkaiser>
ct-clmsn: nod, could work
<heller>
hkaiser: why not communicators? Why allieniate users with a new term?
<hkaiser>
is there a way to 'let it fall through' ?
<hkaiser>
;)
<ct-clmsn>
yep - test the addresses and fall through if they don't match
<hkaiser>
heller: if we want people to understand that it's not mpi we shouldn't use mpi terminology
<hkaiser>
ct-clmsn: perfect
<ct-clmsn>
not sure which address to test...
<ct-clmsn>
lol
<hkaiser>
isn't the signal handler with the address causing the issue?
<hkaiser>
invoked with*
<heller>
I'd look at it to overtake mpi terminology ;)
<hkaiser>
right
<ct-clmsn>
so when SIGSEGV is called, you get a struct that tells you which address broke things
<ct-clmsn>
in the callback
<ct-clmsn>
you can register the callback with some data that gets passed in when the callback is executed
<hkaiser>
ct-clmsn: if that's close to the range of the current stack segment you got yourself a stack-overflow
<ct-clmsn>
i *think* you can compare the registered data with the dynamically provided data
<ct-clmsn>
bingo
<hkaiser>
whatever 'close' means ;)
<ct-clmsn>
yes...
<ct-clmsn>
lol
<ct-clmsn>
how does "close enough" sound?
<hkaiser>
right
<ct-clmsn>
would a macro for the epsilon be ok for now?
mbremer has quit [Ping timeout: 260 seconds]
<heller>
Better than what we have now
<heller>
A segfault on a nullptr for example ;)
<ct-clmsn>
ah right, the simple case
<heller>
Dangling pointers are still interpreted as stack overflows?
<heller>
That's the more interesting case...
diehlpk has joined #ste||ar
<wash>
hkaiser, heller: What do we want to say in the rebuttal? the first reviewer seems to be asking if the framework is applicable to other applications
<hkaiser>
I think we should treat it as a stack-overflow if the offending address is +/- 1k off the current stack frame
<hkaiser>
but a macro for this is certainly fine
<hkaiser>
wash: no idea - any suggestions?
<hkaiser>
I think we have no chance to get accepted, no matter what we say
<heller>
wash: we say yes, and cite the lgd and pgas paper
<hkaiser>
it's a fairly highly competed conference after all
<heller>
We just try to make the reviewers happy
<wash>
@hkaiser We get additional reviewers in the second round
<wash>
Not just the same people ranking us again
<heller>
There are fair points.
<hkaiser>
ok - I'd strongly object to the claim that our results are 'incremental'
<ct-clmsn>
@hkaiser: testing our current sigsegv concept
<wash>
I'm primarily interested in how you would characterize this paper's novel research contribution w.r.t. an ASPLOS setting. I'd also like to understand whether the programming model's support for object migration and automated load balancing came into play in this study. <-
<wash>
that is from reviewer #2
<heller>
So yes, the criticism that the point of the paper was to scale up the application and show that our approach is feasible
<hkaiser>
they have not read the conclusions - that's where the meat is - we might have to make that more prominent
<hkaiser>
we have shown for the first time that a) a tasking system can be used to scale very well and b) that everything can be done using a uniform high-level API
<wash>
actually
<hkaiser>
clcool
<heller>
They unanimously claim we didn't do real science, just made the thing scale and therefore are not a good fit for the conference. Not a lot you can argue with there...
<hkaiser>
ct-clmsn : cool
<wash>
re-reading the original email from ASPLOS, it indicates that not all papers make it to the second round of reviews
<wash>
and it seems we did.
<hkaiser>
heller: right, that's what I meant - whatever we say it will not change the decision - the reviews don't characterize this peper as borderline
<hkaiser>
wash: try it - by all means
<heller>
We should absolutely
<hkaiser>
I'm too angry to be useful
<heller>
Would be stupid but to
<heller>
not*
<heller>
When do they want our answers?
<hkaiser>
today
<wash>
yah
<heller>
Oh, ok
<wash>
Do we make use of migration in octotiger? We do, yes?
<heller>
Why do I always mess up deadlines recently :/
<heller>
We don't
<ct-clmsn>
@hkaiser: doing an hpx compile going afk
<ct-clmsn>
@hkaiser: will look at merging the tree transducer in it's current state into your transducer work
<ct-clmsn>
later tonight
<hkaiser>
ct-clmsn: great, pls ask if something is not clear
<ct-clmsn>
will do
<hkaiser>
ct-clmsn: pls also assume I did it all wrong
<ct-clmsn>
@hkaiser: i'm still learning the kurt implementation and how it relates to the paper so...it'll be a learning experience for everyone!
<wash>
"The framework implementation consists of multiple techniques: future in new C++ parallel model, AGAS for workload balancing, and vectorization supported from Vc library. I’m not sure which
<wash>
techniques are developed specifically by the authors for this work."
<wash>
How do we respond to that?
<wash>
Reviewer #1 is basically asking "is HPX part of this work", I think.
<hkaiser>
it sure wasn't developed exclusively for this work
<wash>
How about "co-designed"?
<hkaiser>
hpx is a general purpose runtime system
<hkaiser>
the application was definitely a driving use case
<hkaiser>
a means of verification of the implemented concepts
<wash>
hkaiser: reviewer #1 seems to be asking whether or not we developed HPX, I think, or whether we just developed the simulation.
<hkaiser>
both
<hkaiser>
what do they know
diehlpk has quit [Ping timeout: 258 seconds]
<ct-clmsn>
@hkaiser: can't find the tree directory in the transform_ast branch
<ct-clmsn>
@hkaiser: (or blob)
<hkaiser>
ct-clmsn: sec
<ct-clmsn>
@hkaiser: wasn't sure if those files were pushed
<hkaiser>
hold on, this one:https://github.com/STEllAR-GROUP/phylanx/blob/transform_ast/src/ast/transform_ast.cpp
<hkaiser>
ct-clmsn: ^^
<ct-clmsn>
@hkaiser: hmm. i'm on transfer_ast branch, and transform_ast.cpp is in ./src/ast/transform_ast.cpp
<hkaiser>
yes
<ct-clmsn>
ah ok
<ct-clmsn>
whew
<ct-clmsn>
phylanx/blob was throwing me off
<hkaiser>
it's what github gives me ;)
<ct-clmsn>
cool is a weighted transducer ok? we can set the weights to 1.0 to make it a non-stochastic transducer
<ct-clmsn>
or would you rather keep it simple to avoid getting things overly complicated
<hkaiser>
sure, whatever is needed - the current code has no weights, though
<ct-clmsn>
np
<ct-clmsn>
will look into it
<hkaiser>
does not allow for different options
<ct-clmsn>
there's some statistics sauce that would need to be added in
<hkaiser>
nod
<hkaiser>
what would that be useful for?
<ct-clmsn>
this approach helps with svz's work
<ct-clmsn>
gives him some weights to work with on the tree
<ct-clmsn>
bbiab
<wash>
I'm sending a draft
<wash>
ct-clmsn: btw, have you heard about our (nvidias) container launch?
<ct-clmsn>
@wash: not yest
<ct-clmsn>
yet
<ct-clmsn>
@wash: what's the story?
<wash>
@ct-clmsn: if y'all still care about containerization, it may be worth checking out. We released a set of docker containers for various ML frameworks+CUDA last week
<wash>
I recall you had to deal with containers of some sort :p
<wash>
@ct-clmsn: https://www.nvidia.com/en-us/gpu-cloud/ <- (the site is kinda high-level, I'm sure we have an easier way for people to just yank the images; it's designed to deploy on either amazon instances, or your own hardware atm)