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/
<hkaiser>
K-ballo: you tell me, I'm not aware of any problems with atomic on our platforms
<hkaiser>
we've kept it for older versions of gcc, iirc
<K-ballo>
up to 4.6, apparently
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<hkaiser>
K-ballo: yah
mcopik has quit [Ping timeout: 260 seconds]
eschnett has quit [Ping timeout: 240 seconds]
<K-ballo>
now I remember why I didn't do this earlier, there's some bad atomic usages in the codebase
<hkaiser>
K-ballo: are there?
<hkaiser>
uhh
<K-ballo>
one boost::atomic<scheduled_executor> default_executor_instance;
<hkaiser>
ahh, non-trivial type
<K-ballo>
and another one in external/lockfree that looks fixable
eschnett has joined #ste||ar
<hkaiser>
that scheduler one can be replaced by a spinlock and a non-atomic
<K-ballo>
what kind of spinlock? util::?
<hkaiser>
lcos::local::spinlock, works for any type of thread
<hkaiser>
I think we can remove the util::spinlock, it's not used anywhere anymore
<github>
[hpx] K-ballo opened pull request #2763: Bump minimal Boost version to 1.55.0 (master...boost-bump) https://git.io/vQbiK
<hkaiser>
heller: you'd have to either migrate the whole pool or add an additional mapping layer which defeats the whole purpose
eschnett has joined #ste||ar
<heller>
I don't see that
<heller>
for migratable objects, we already have the additional mapping layer, no?
<heller>
hkaiser: the only real difference between managed and unmanaged components is the allocation, no?
<heller>
where do you see the additional mapping layer?
zbyerly_ has quit [Ping timeout: 276 seconds]
pree has quit [Ping timeout: 268 seconds]
pree has joined #ste||ar
<heller>
hkaiser: do I miss something?
<hkaiser>
heller: we pool managed components for the gids to be guaranteed to be consecutive --> no AGAS interaction is needed for all except the first component instance in a pool
<heller>
no AGAS interaction when those are constructed, right?
<hkaiser>
yes
pree has quit [Ping timeout: 248 seconds]
<heller>
I am thinking that we would never need network turnarounds for assigning GIDs
<hkaiser>
that's true
<heller>
wouldn't the pair of locality + locally unique ID be enough?
<hkaiser>
for what?
<heller>
creating GIDs
<heller>
assigning GIDs to LVAs
<hkaiser>
that's what we do for (simple) components
<hkaiser>
we want to get rid of managed components anyways
<heller>
yes
<hkaiser>
just see this patch as an intermediate step ;)
patg has joined #ste||ar
<heller>
so we're basically on the same page, good ;)
denis_blank has quit [Quit: denis_blank]
<hkaiser>
heller: however, even if you generate the gid locally, it still needs to be registered with agas for others to be able to resolve it
<hkaiser>
so agas interaction is needed for every instance of a unmanaged component
<heller>
true
<heller>
on a side note: did you notice how we are overloading the term "unmanaged"?
<hkaiser>
what do you mean?
<hkaiser>
components vs id_type?
<heller>
yes
pree has joined #ste||ar
<hkaiser>
well, formerly we called the 'unmanaged' components 'simple'
<hkaiser>
you didn't like that ;)
<heller>
I never said I didn't like it. What I do not like is that we have both, managed and (simple) components
<hkaiser>
k
<hkaiser>
anyways, gtg
<hkaiser>
ttyl
hkaiser has quit [Quit: bye]
pree has quit [Read error: Connection reset by peer]
bikineev has quit [Ping timeout: 240 seconds]
bikineev has joined #ste||ar
akheir has joined #ste||ar
hkaiser has joined #ste||ar
patg has quit [Quit: This computer has gone to sleep]
mars0000 has joined #ste||ar
mars0000 has quit [Client Quit]
elfring has joined #ste||ar
eschnett has quit [Ping timeout: 240 seconds]
eschnett has joined #ste||ar
aserio has joined #ste||ar
<heller>
aserio: 152!
bikineev has quit [Ping timeout: 260 seconds]
<aserio>
heller: sounds like you've had a productive day!
<heller>
almost ;)
mbremer has joined #ste||ar
EverYoung has joined #ste||ar
bikineev has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
vamatya has joined #ste||ar
mcopik has quit [Ping timeout: 255 seconds]
pree has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
pree has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
pree has joined #ste||ar
Matombo has joined #ste||ar
david_pfander has quit [Ping timeout: 276 seconds]
aserio has quit [Ping timeout: 246 seconds]
denis_blank has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
thundergroudon[m has quit [*.net *.split]
denis_blank has quit [Quit: denis_blank]
taeguk[m] has quit [Ping timeout: 255 seconds]
bibek_desktop has quit [Ping timeout: 258 seconds]
bibek_desktop has joined #ste||ar
thundergroudon[m has joined #ste||ar
taeguk[m] has joined #ste||ar
elfring has quit [Quit: Konversation terminated!]
bibek_desktop has quit [Ping timeout: 246 seconds]
bibek_desktop has joined #ste||ar
vamatya has quit [Ping timeout: 240 seconds]
<mbremer>
Hi, (to anyone :) ) is it possible to obtain the a rolling-average for the thread's idle rates counter? I see the idle-rates counter and the statistics/rolling_average, but don't know how / if you can combine these.
mcopik has joined #ste||ar
<hkaiser>
mbremer: yes
<hkaiser>
well
<hkaiser>
the idle-rate counter itself is an average
<mbremer>
Oh sure, I'm more interested in the time aspect of it.
<hkaiser>
what you could do is to reset the counter on each query and use that for a rolling average
<hkaiser>
something like /statistics{/threads{locality#0/total}/idle-rate}/rolling_average@200,1000,1
ajaivgeorge has joined #ste||ar
<hkaiser>
sample idle-rate every 200 ms, average over 1000 ms (5 samples), and reset the underlying counter on each sample
<thundergroudon[m>
this is running ps -ef from my user
<hkaiser>
thundergroudon[m: please talk to akheir
pree has quit [Ping timeout: 276 seconds]
Matombo has quit [Remote host closed the connection]
aserio1 has joined #ste||ar
mars0000 has joined #ste||ar
aserio has quit [Ping timeout: 276 seconds]
aserio1 is now known as aserio
pree has joined #ste||ar
RostamLog has joined #ste||ar
akheir has joined #ste||ar
bikineev has joined #ste||ar
vamatya has quit [Ping timeout: 268 seconds]
akheir has quit [Remote host closed the connection]
akheir has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
<zbyerly_>
is anyone else getting these suddenly:
<zbyerly_>
include/hpx/util/jenkins_hash.hpp:196:17: note: in expansion of macro ‘HPX_FALLTHROUGH’
<zbyerly_>
warnings
EverYoung has joined #ste||ar
<zao>
zbyerly_: Hi and welcome to GCC 7.1?
<zao>
Well, what is the actual warning you see?
<zao>
We've recently added support for [[fallthrough]] via a compile test, which ought to work on roughly the same compilers that start nagging about case fallthrough.
<hkaiser>
zbyerly_: what do you mean by 'suddenly?
<hkaiser>
top of master from today?
Matombo has joined #ste||ar
<zbyerly_>
hkaiser, i don't think i've pulled today but in the last 2 or 3 days, but it's also new code
<zbyerly_>
I was just wondering if it was something I should worry about
<zao>
Still not sure what you're actually seeing, and on what toolchain and TU.
<K-ballo>
so how does one properly link atomic from cmake?
<mcopik>
zbyerly_: which compiler, which version?
<zbyerly_>
gcc 6.3.0
<zbyerly_>
boost 1.63
<mcopik>
zbyerly_: and what warning exactly?
testing123456322 has joined #ste||ar
<zao>
Does that test get run properly and work properly if building explicitly with 14?
<mcopik>
shouldn't it be return hpx::util::report_errors()?
<mcopik>
now tests always pass, even if all test macros return a fail
zbyerly_ has quit [Ping timeout: 246 seconds]
<mcopik>
there are many more tests which always return 0. what am I missing here? do we have multiple tests fooling ctest that everything is running fine even when it isn't?
<mcopik>
hkaiser: ^
mars0000 has quit [Quit: mars0000]
Matombo has quit [Remote host closed the connection]
bikineev has quit [Remote host closed the connection]