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/
K-ballo has quit [Quit: K-ballo]
quaz0r has quit [Ping timeout: 258 seconds]
hkaiser has quit [Quit: bye]
quaz0r has joined #ste||ar
jaafar_ has quit [Ping timeout: 258 seconds]
david_pfander has joined #ste||ar
Amy1 has quit [Ping timeout: 264 seconds]
<jbjnr>
simbergm: what would be my chances of getting fixes to shared-priority-scheduler into master in time for next release?
<simbergm>
jbjnr: low if you don't finish the numa PR first ;) high if it passes tests this week (it doesn't really touch anything outside your scheduler, right?)
<jbjnr>
I just pushed the numa-allocator PR btw.
<simbergm>
nice, thanks! :)
<simbergm>
I don't think your scheduler changes will be very risky so should be ok to merge as long as it's reasonably clean
<jbjnr>
simbergm: only 41 files modified. Should be trivial.
<jbjnr>
actually a few less. I've got some other stuff emrged into that branch hat I'll get rid of
<simbergm>
jbjnr: yep, sounds ok
<jbjnr>
lol
<simbergm>
lol? because 41 files modified is not really trivial?
<simbergm>
jbjnr: see comment on #3802 about the test "missing"
<jbjnr>
wtf?
<jbjnr>
oh I see. This is the first 'topology' test there were none before and now we need a new config
<jbjnr>
PITFA
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<simbergm>
lol
<hkaiser>
simbergm: would you object to merging the get_ptr patch?
<simbergm>
hkaiser: no, go ahead
<hkaiser>
done, thanks
<simbergm>
jbjnr: you need to add tests.unit.topology in two places at the end of the config file as well
<jbjnr>
it was vi that messed up the indentation. Useless.
<simbergm>
or, do you think that the serialization implementation of tuple(_impl) could be decoupled from the class?
<hkaiser>
simbergm: both are questions for K-ballo
<simbergm>
ok, thanks
<simbergm>
I'll see what he has to say
<hkaiser>
simbergm: I'm not sure what part of the exceptions get sent over the wire (i.e. needs serialization)
<hkaiser>
if the coe you linked is not serialized it could use std::tuple instead, I guess
<simbergm>
I suspected something like that
<simbergm>
K-ballo: if and when you have time ^
<hkaiser>
simbergm: should serialization be independent of everything else?
<hkaiser>
*shouldn't*
<hkaiser>
each class can provide its own serialization functionality as part of its module
<simbergm>
well, yes, the third option would be to remove the dependency on exception from the serialization helper functionality (it does a HPX_THROW_EXCEPTION(serialization_error) in some cases)
<simbergm>
this would probably be the best option
<hkaiser>
simbergm: just throw std::runtime_error() directly
<simbergm>
but that would need some sort of replacement so that it can be caught if needed
<simbergm>
fair enough, if you don't think it's necessary to distinguish it there I'll go for that
<hkaiser>
we can catch this further out
<simbergm>
*not necessary
<simbergm>
nice, thanks hkaiser, I'll see where this goes
<hkaiser>
simbergm: thanks
<simbergm>
hkaiser: any hope of getting the boost small vector regression fixed for the release? does it look bad? :/
<hkaiser>
uhh, need to look - have not had any time for this yet
<hkaiser>
thanks for the reminder
<simbergm>
ok, no problem
<simbergm>
thanks for having a look
<hkaiser>
simbergm: I might have a quick fix for the release, but the whole async unwrap needs to be reworked slightly to use a trait for the container type unwrapped
<simbergm>
ok
<simbergm>
just saw we got accepted for gsod btw!
<simbergm>
diehlpk_work, parsa
<jbjnr>
simbergm: what is the "boost small vector regression"
<simbergm>
jbjnr: they changed some default template parameters in 1.70 which breaks one or two tests that use small vector
<jbjnr>
I see.
<simbergm>
hkaiser: I suppose we can always explicitly set the allocator to the old default?
<K-ballo>
simbergm: the one in exception_info doesn't need to be tuple, could be leafs.. I think heller's refactoring included that change
<K-ballo>
tuple serialization should be unintrusive, I was probably trying to keep things simple for myself
<simbergm>
K-ballo: ok, thanks, good to know that we have options
<simbergm>
I'll start with number three, but we can potentially do all three in the end
<simbergm>
K-ballo: btw, "could be leafs" means what exactly? std::tuple would also work?
<K-ballo>
std::tuple would probably also work, that'd be easier
<heller>
diehlpk_work: good job!
<heller>
hkaiser: I guess we should restart our calls next week
<K-ballo>
simbergm: leafs, having exception_info inherit from each of the attribute types, in a way similar to (our) tuple implementation
<simbergm>
K-ballo: ok, gotcha
<jbjnr>
diehlpk_work: parsa well done with gsod
<jbjnr>
^ simbergm too
<jbjnr>
if we get volunteers who want to create docs, can I ask for parcelport docs? I can write material if a minion does the cleaning up and formatting for inclusion
hkaiser has quit [Quit: bye]
eschnett has joined #ste||ar
<simbergm>
jbjnr: we're unlikely to get "minions", i.e. they're not students and we'll get at most two but most likely one or zero
<simbergm>
they're "technical writers", which I think means that they're supposed to be better writers than programmers
<jbjnr>
thanks
<simbergm>
so they should be able to help with structuring our documentation better, writing tutorials, but anything that requires knowing a lot of implementation details about hpx is probably not project for them
<jbjnr>
best if I leve you guys to it I think. The PP is so far undocumented and would require a lot of contribution from myself or heller
<simbergm>
+ we should focus on the most important parts for users
<simbergm>
the parcelport isn't terribly useful for users who don't know how to write programs with hpx
<simbergm>
parcelports
hkaiser has joined #ste||ar
<jbjnr>
correct. I wanted it to document it for whoever works on it next, but it isn't a useful thingfor most end users.
<parsa>
hkaiser: thank you!
<parsa>
simbergm: great!
<jbjnr>
Nooooooooo~
<jbjnr>
sodding numa-allocator test is faling on some crappy machine on circleci
<jbjnr>
is it a virtual machine or something. How can I duplicate it.
<jbjnr>
Docker container or something?
<jbjnr>
note to self - must make params smaller for test. too much output
<simbergm>
jbjnr: yep
<simbergm>
if you need to you can ssh into it
<simbergm>
(have to restart with ssh enabled)
<jbjnr>
simbergm: restart what? I'm not user I know what you're saying
<jbjnr>
s/user/sure
<simbergm>
you have to restart the build (or the "step" actually)
<simbergm>
top right, arrow next to rebuild, and then "rerun job with ssh"
<simbergm>
if you need it for debugging, that is
<jbjnr>
ok. what sort of machine/OS is it running on. The output is ---- instead of 0000 which tells me a kernel call to query numa didn't succeed, so whatever machine it is, I need to chage the response. Default to zero is fine, but I'd like to understand better
<jbjnr>
thanks though. Didn't know this was a thing
eschnett has quit [Quit: eschnett]
<diehlpk_work>
simbergm, Do you have time to write one initial blog post about GSoD?
<simbergm>
diehlpk_work: yeah, I think I can do it this week
<K-ballo>
have we ever heard of a user named Thomas Markovich?
<diehlpk_work>
simbergm, CCT will tweet about it and add something on our web page
eschnett has joined #ste||ar
aserio has joined #ste||ar
arokux has joined #ste||ar
<arokux>
Hi guys, I'm interested in improving HPX library. My primary motivation is to learn more about parallel programming. Is it possible that some of you points me to a first task and reviews my implemenatation? Thank you
<K-ballo>
maybe check with hkaiser here first that nobody is already working on it (and failed to grab it)
<K-ballo>
you could get started on building hpx in the meantime, it is not exactly trivial
<arokux>
K-ballo: ok
<aserio>
diehlpk_work: I will take the baton for the IWOMP paper
eschnett has joined #ste||ar
jpenuchot has joined #ste||ar
<diehlpk_work>
aserio, Nice, be aware that we need to talk to hkaiser about the conclusion. We need to add more details why we performed bad for large amounts of tasks
aserio has quit [Ping timeout: 276 seconds]
<hkaiser>
arokux: that ticket is still up for grabs