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/
patg[[w]] has quit [Quit: This computer has gone to sleep]
<github>
[hpx] msimberg closed pull request #3060: Fix compiler problem in MSVC release mode (master...fixing_msvc_linking) https://git.io/vb4tp
david_pfander has joined #ste||ar
<simbergm>
sadly enough it seems as if the suspension changes are not causing thread_pool_executors to fail
<jbjnr>
remind me what we need thread_pool_executors for?
<simbergm>
I don't know, but I'm in favor of removing them
<simbergm>
they're a pain
<simbergm>
I think heller had some conditions before he lets us remove them...
<heller>
I think the conditions are met now
<heller>
since the throttling using the resource partitioner work
<heller>
s
<simbergm>
the added functionality that they have is running on less than pool threads, right? and not having to create a thread pool with the scheduler you want...
<simbergm>
it hangs even 4 months ago btw, didn't feel like going further back...
<heller>
yeah
<heller>
let's just remove it
<simbergm>
more relevant question: thread_pool_base is kind of part of the API, is it then allowed to move out from the detail namespace?
<heller>
it never worked reliably anyways
<heller>
erm
<heller>
yes, I think so
<simbergm>
I ask because it seems like quickbook ignores documentation in detail namespaces
<simbergm>
but maybe I've messed up
<simbergm>
and I want to document suspension
<simbergm>
depends though if the API should be get_pool("pool").suspend() or if there should be some hpx::suspend_pool("pool") function
<simbergm>
there's a lot of stuff in thread_pool_base that's not really meant for users
<heller>
split it up further ;)
<simbergm>
ok, thought so :)
<simbergm>
btw, heller how much have you used the suspension now for the allscale stuff? or not tested yet?
<heller>
it has been tested and seems to work nicely
<simbergm>
ok, good to hear
<simbergm>
you know where to complain if there's something ;)
<heller>
sure
<simbergm>
appveyor timeout is 1h, no?
<simbergm>
looking at 3061 where one VS build seems to have timed out
<simbergm>
jbjnr: did you see enough of jenkins to decide if it's useful for us?
<heller>
simbergm: the problem with appveyor is that it sometimes fails to download the binaries
hkaiser has joined #ste||ar
<simbergm>
heller: don't think it was that this time though, it just didn't have time to finish building everything
<heller>
ok
<simbergm>
is it possible to re-trigger a build from appveyor or is only possible by pushing another commit
<simbergm>
and the timeout needs to be increased if it's always going to take longer
<hkaiser>
simbergm: I can retrigger things
<hkaiser>
simbergm: the timeout on appveyor is fixed - we need to reduce the amount of things we do there
<simbergm>
hkaiser: thank you! do you mean build less or build faster?
<simbergm>
could you re-trigger 3061/3074 in that case?
<hkaiser>
build less
<simbergm>
ok
K-ballo has joined #ste||ar
<hkaiser>
simbergm: I have now re-triggered the builds
<simbergm>
hkaiser: thanks
<hkaiser>
sorry, they don't provide any means of access control...
<hkaiser>
I can't give anybody access to the builds :/
<simbergm>
no apologies needed, sorry I can't do it...
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
<jbjnr>
simbergm: I don't see anything that jenkins can do that we can't do ourselves now. pycicle is just running and I don't need to touch it any more, so branches are tested. heller is using buildbot and as far as I know we are happy, and close to green. Main objective accomplished really (?)
<heller>
I want to switch to pycicle soonish
<simbergm>
yep, agree 100%, was just wondering if there was anything hannes showed after I left that seemed useful
<simbergm>
(+he asked again if we are interested in using it)
<jbjnr>
It has the ability ot select 'option's using a matrix, so you can say, boost-X, compiler-Y and feature-Z and then select between them, but in fact most of the work has to go into our build scripts to handle these options, and adding that switch to pycile will bea days work at most.
<jbjnr>
the difficulty with jenkins if the sheer configuration of it, I'd rather do it with pycicle, and I have total control, of everything.
<jbjnr>
So in short, I am not going to use jenkins now, unless I'm ordered to.
<jbjnr>
Or ...
<simbergm>
yeah, seems reasonable
<jbjnr>
unless someone sets it up and it just works and I have to do nothing at all.
<simbergm>
as long as you're happy accepting bug reports for pycicle ;) but that will stabilize quickly
<simbergm>
ah, well, I will have a look with hannes but just because I'm interested in general
<jbjnr>
it the build scripts that take the work. And getting them running with pycicle should be faster than doing it with Jenkins I think .
* zao
jiggles
<simbergm>
if it seems very straightforward I'll give it a try with hpx, but I think that's unlikely
<zao>
I should look into what build scripts there are in the HPX tree.
<zao>
I just inject my own into the images atm, and that's a bit nasty.
<zao>
Also going to have a bad day when we finally get to drop HPX_WITH_CXX14 as that's hardcode all over my place.
<K-ballo>
drop?
<zao>
As in, not have to force that option when I build.
<zao>
(that time may already have come, for all I know)
<jbjnr>
zao: on my greina build, I ad HPX_WITH_CXX14, on the cray build I add HPX_WITH_CXX17, shouldn't be too much work to make it flexsible
hkaiser has joined #ste||ar
aserio has joined #ste||ar
<simbergm>
heller: for the inplace_merge + libc++ problem, did you mean completely ignoring the test for libc++ version < X? or did you have something more clever in mind?
<heller>
no, that would be my take, yes
<simbergm>
ok, I was first thinking you wanted to do some magic inside hpx... but this makes sense, there's not much else we can do
<jbjnr>
got my first pycicle complaint.
<hkaiser>
jbjnr: should we close the hpx PR now as you have it in a separate repo? - or do we need to change things in HPX for this as well?
<jbjnr>
no.it can be closed
<jbjnr>
done
<hkaiser>
thanks
Smasher has joined #ste||ar
<github>
[hpx] msimberg opened pull request #3078: Don't test inplace_merge with libc++ (master...ignore-inplace_merge-libc++) https://git.io/vbrib