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/
jgolinowski has quit [Ping timeout: 258 seconds]
jgolinowski has joined #ste||ar
K-ballo has quit [Ping timeout: 246 seconds]
jgolinowski has quit [Ping timeout: 246 seconds]
nikunj has joined #ste||ar
jgolinowski has joined #ste||ar
K-ballo has joined #ste||ar
K-ballo1 has joined #ste||ar
quaz0r has quit [Ping timeout: 245 seconds]
K-ballo has quit [Ping timeout: 258 seconds]
K-ballo1 is now known as K-ballo
quaz0r has joined #ste||ar
nikunj has quit [Quit: Leaving]
K-ballo has quit [Quit: K-ballo]
<simbergm>
diehlpk_work: ah, shame, hope he feels better soon!
<simbergm>
jgolinowski: awesome!
<simbergm>
waits in suspense to see if it's jbjnr
<simbergm>
it's not :)
<simbergm>
jgolinowski: thanks for taking care of that, hope he gets it running
<simbergm>
that person also opened an issue for hpx itself, he seems to be wanting to run it on arm
<simbergm>
but our exception handling must still be somewhat broken if that's the output one gets for not having started the runtime
<jgolinowski>
simbergm, yeah I was thinking that (about the error message)
jgolinowski has quit [Quit: Leaving]
jbjnr has joined #ste||ar
<jbjnr>
simbergm: yt?
<simbergm>
jbjnr: here
<jbjnr>
option 1 - do nothing (fine by me), opt 2 - make numa allocator a cmake option (too many options already), opt 3 waste a lot of time trying to find out why it fails on certain machines then go with opt 1 or 2 anyway. opt 4 can we disable it easily for some platforms some other way???
<jbjnr>
opt 4 seems hard since we don't know why it fails.
<jbjnr>
so tat leave opt 1 or 2. I'm leaning towards opt 2
<jbjnr>
we add a HPX_WITH_EXPERIMENTAL_FEATURES (or similar) and put all the slightly avant-garde stuff under control of that
<jbjnr>
simbergm: ^^
<simbergm>
jbjnr: I think I agree with your options
<simbergm>
1 would be fine by me if we get the dashboard green
<simbergm>
I like the flag for experimental features
<simbergm>
it seems like ali is sick at the moment so we'd have to wait to see if we can change something on rostam
<jbjnr>
It does raise the problem of when we move something out of experimental into main. if it's turned off on dashboards by default, we'll never really know when it's safe to move to main
<simbergm>
with 4 we'd just have to make sure we still test those
<simbergm>
exactly that, we can't have them experimental and then not test them, that'll just break without us noticing
<simbergm>
I'd make the flags per feature though, not one global flag
<simbergm>
possibly an additional global flag so that we can turn all experimental features on easily for testing
<simbergm>
it would be a nice way of rolling things out without giving all the
<simbergm>
guarantees about not breaking the api etc while something is still experimental
jbjnr_ has joined #ste||ar
jbjnr has quit [Ping timeout: 252 seconds]
<jbjnr_>
simbergm: the problem is that if we add an experimental feature flag, then we have to test i, then our dashboards are not green, so why bother - we can have non green dashboards by doing nothing
<jbjnr_>
who's talking in the meeting today.I was preparing and doing course all week, so if you have something interesting you want to talk about, you do it.
<simbergm>
jbjnr_: I can do it even though I don't necessarily have something interesting
<simbergm>
good point about the flag, it doesn't help in making the dashboard green
<simbergm>
let's ask ali what he can do
<simbergm>
I'm also pretty okay with releasing the allocator as it is (even though the dashboard isn't entirely green) because it seems to still do something sane
<simbergm>
i.e. it doesn't segfault or crash in some other way
<simbergm>
it still gives a chunk of memory, just not quite where you want it
<jbjnr_>
what we really need is a green dashboard, which means not running the test on the dashboard - is it work running the test on the dashboard, but exclucing it from the red/green status?
<jbjnr_>
is it worth^
<simbergm>
no
<simbergm>
let's see if we can disable hugepages first
<simbergm>
if we can't do that we'll need to change the test
<jbjnr_>
I can make the test return pass if no segfaults happen, but then it isn't a very interesting test
<jbjnr_>
it was cleverly designed to actually test the memory binding.
<jbjnr_>
so it's doing it's job
<jbjnr_>
I wonder if I balse up the test somehow
K-ballo has joined #ste||ar
aserio has joined #ste||ar
jaafar_ has joined #ste||ar
jaafar has joined #ste||ar
jaafar_ has quit [Ping timeout: 252 seconds]
nikunj has joined #ste||ar
aserio has quit [Ping timeout: 264 seconds]
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
aserio has joined #ste||ar
quaz0r has quit [Ping timeout: 252 seconds]
diehlpk has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
quaz0r has joined #ste||ar
aserio has joined #ste||ar
<aserio>
jbjnr_: Will you be joining the meeting?
<aserio>
diehlpk, diehlpk_work: ^^
<diehlpk>
I will be late
<diehlpk>
Can make it at 11;20
<diehlpk>
aserio, Other meeting running late
hkaiser has joined #ste||ar
<diehlpk>
aserio will be there in 10min
diehlpk has quit [Ping timeout: 250 seconds]
hkaiser has quit [Quit: bye]
aserio has quit [Ping timeout: 248 seconds]
hkaiser has joined #ste||ar
aserio has joined #ste||ar
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 248 seconds]
aserio1 is now known as aserio
hkaiser has quit [Ping timeout: 248 seconds]
aserio has quit [Ping timeout: 248 seconds]
aserio has joined #ste||ar
aserio has quit [Client Quit]
hkaiser has joined #ste||ar
nikunj has quit [Remote host closed the connection]
jaafar has quit [Ping timeout: 252 seconds]
rtohid has quit [Quit: Konversation terminated!]
nikunj has joined #ste||ar
jaafar has joined #ste||ar
jbjnr_ has quit [Read error: Connection reset by peer]