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/
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
EverYoun_ has quit [Ping timeout: 252 seconds]
zbyerly_ has quit [Ping timeout: 248 seconds]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
parsa has quit [Quit: Zzzzzzzzzzzz]
zbyerly_ has joined #ste||ar
mcopik has quit [Ping timeout: 248 seconds]
Vir has quit [Ping timeout: 240 seconds]
Vir has joined #ste||ar
EverYoun_ has quit [Ping timeout: 240 seconds]
parsa has joined #ste||ar
hkaiser has quit [Quit: bye]
Vir has quit [Ping timeout: 240 seconds]
Vir has joined #ste||ar
aserio has joined #ste||ar
aserio has quit [Quit: aserio]
aserio has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
aserio has quit [Client Quit]
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
parsa has quit [Client Quit]
zbyerly_ has quit [Ping timeout: 260 seconds]
bikineev has joined #ste||ar
jaafar has quit [Ping timeout: 246 seconds]
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
eschnett has quit [Quit: eschnett]
Matombo has joined #ste||ar
bikineev has quit [Remote host closed the connection]
ajaivgeorge has quit [Quit: ajaivgeorge]
ajaivgeorge has joined #ste||ar
david_pfander has joined #ste||ar
david_pfander has quit [Remote host closed the connection]
<jbjnr> diehlpk_work: final GSoC evaluation submitted
Matombo has quit [Remote host closed the connection]
david_pfander has joined #ste||ar
<heller> jbjnr: how bad would you think it is when we'd require clang for our cuda stuff?
<jbjnr> standard clang - or special build/branch?
<jbjnr> I would say that if we provide a CMake check that prints out a warning that says something like "cuda compute support requires a minimum clang version x.y' etc, then it's ok. Certainly I would not like to see the cuda stuff littered with #ifdefs for different nvcc versions etc etc
<jbjnr> heller: ^
<heller> yes
<heller> standard clang
<heller> dropping nvcc support
<jbjnr> then ok
<heller> would that work on daint?
<heller> I am currently hitting a wall with nvcc not being able to compile certain things
<jbjnr> hmm. I thought there was a clang module on daint, but now I can't find one
<jbjnr> I will build clang 4 on daint today if you like
<heller> I can do it as well
<heller> just wanted to check if you'd generally object to such endavour
<jbjnr> you then, since you're testing - unless you want me to d it
<heller> and how this might affect the hackathon work
<jbjnr> if we have clang on daint, then all will be fine, but we must test this week
<heller> sure thing
<jbjnr> heller: as a general rule, I'm not in favour of supporting old compilers, langauge fgeatures, etc and would rather force people to upgrade than pollute code with workarounds. If a user absolutely NEEDS feature X that requires an older something, then they should be willing to support the old features that other want to remove. It's why we are doing open source in the first place really. To...
<jbjnr> ...promote and improve the features we want and help out.
<jbjnr> (if I need feature x, and everyone else wants to upgrade and drop it, then I ought to implement that feature and make everyone else happy)
<heller> I agree
<heller> could the RP merge, in general have lead to a performance regression?
<jbjnr> not that I'm aware of, but I've noticed today that something is not right in the thread masks. I'm not sure when it got broken. I'll keep you posted. meeting in a mo.
mcopik has joined #ste||ar
Matombo has joined #ste||ar
Matombo has quit [Ping timeout: 264 seconds]
<github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://git.io/v5la0
<github> hpx/gh-pages 3a8ea52 StellarBot: Updating docs
Matombo has joined #ste||ar
bikineev has joined #ste||ar
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
<heller> so I can't dynamically create new thread pools after the runtime has been started?
bikineev has quit [Ping timeout: 248 seconds]
K-ballo has joined #ste||ar
bikineev has joined #ste||ar
bikineev_ has joined #ste||ar
bikineev has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
<jbjnr> heller: not yet, that's a feature that's planned. hkaiser might have started on it
<hkaiser> on what?
<jbjnr> hellerso I can't dynamically create new thread pools after the runtime has been started?
<jbjnr> ^^^
<hkaiser> not at this point
<hkaiser> I doubt there are any use cases for this which couldn't be solved otherwise
<heller> hkaiser: my use case is that the application is started with the hpx_main emulation
<heller> I guess I would just register a specific startup function?
<hkaiser> hmm, need to think about this
<hkaiser> good point
<hkaiser> startup functions right now are run after the runtime has been started, but before hpx_main
<heller> essentially what I want is one pool per NUMA domain
<hkaiser> sure
<heller> ok, that's too late then
<hkaiser> create a global object and set up the RP in its constructor
<heller> hmm
<heller> that doesn't give me access to the command line options
<hkaiser> heller: just for now until we find a proper solution that is
<hkaiser> you seem to need it now
<heller> I can live without it for the time being
<hkaiser> ok
<jbjnr> heller: why can't yuo just use int main instead of hpx_main?
<hkaiser> heller: Shoshana was planning to add command line options for this
<heller> jbjnr: I'll investigate this
<jbjnr> one pool per numa is a doddle if you do
<heller> figured as much
<heller> it looks like the attached executors behave strangely at the moment, but I need to investigate this a little closer
<hkaiser> heller: I have not looked at the executors at all
<hkaiser> everything is possible there
<heller> this is another use case
<jbjnr> what do you mean by strangely?
<heller> I am seeing threads being scheduled on a different numa domain, even though it shouldn't
<hkaiser> heller: no that's not a use case - if you know you need the executor with a special pool, just create it at startup
<jbjnr> ooh. That would be a bad thing
<jbjnr> I'm fixing something similar right now. The thread manager init function is messed up
<hkaiser> heller: the attached schedulers hav no notion of the RP
<heller> hkaiser: I disagree. Having the ability to dynamically attach executors to a smaller partition is something we ultimately want
<hkaiser> they probably all use the default pool
<hkaiser> heller: ultimately yes, but not now
<heller> so this is the use case :P
<jbjnr> it shows 0000 instead of 10101010 in the second printout
<hkaiser> so I broke it - write tests in the future...
<jbjnr> I'm looking into it, but stuff like this might screw up other things. The threads themselves appear to be correctly placed, but the pool mask is wrong
bikineev_ has quit [Ping timeout: 246 seconds]
<heller> all in all, we have to do a lot of cleanups
<hkaiser> heller: sure, somebody has to do it
<jbjnr> not blaming you hkaiser - except that I was working on making this all robust and you wanted to merge right away.
<hkaiser> heller: and please write tests for each regression you fix
denis_blank has joined #ste||ar
<heller> it is good that it has been merged
<hkaiser> jbjnr: come on - this was long overdue to be reintegrated - we can fix things now
<jbjnr> ^not blaming yuo!
<heller> otherwise we wouldn't even be aware of failures when using it more complex use cases
<hkaiser> ;)
<jbjnr> or you even
<jbjnr> any decent c++ jobs out there for me btw?
<hkaiser> jbjnr: pleanty
<hkaiser> plenty even
<zao> Actual C++ or the weirdo flavor you template lunatics use? :)
<jbjnr> good. When I need one, I'll ask you hkaiser . zao, the weirdo flavour will be fine
<github> [hpx] hkaiser closed pull request #2833: Implement parallel::merge. (master...tg_merge) https://git.io/v7dsQ
bikineev has joined #ste||ar
<heller> hkaiser: I really feel uncomfortable with merges when buildbot is so unstable
<hkaiser> heller: sure - you just merged 3 of them the other day
<jbjnr> lol
<heller> yes. I tried to make it more stable before doing the merges. the results weren't good
<heller> and actually, one merge and 3 commits directly to master :P
pree has joined #ste||ar
ajaivgeorge has quit [Quit: ajaivgeorge]
pree has quit [Ping timeout: 240 seconds]
pree has joined #ste||ar
zbyerly_ has joined #ste||ar
<diehlpk_work> jbjnr, Thanks for doing the evaluation
eschnett has joined #ste||ar
<jbjnr> it was easy because taeguk[m] was a great student :)
<diehlpk_work> Yeah, all of them contributed creat stuff
<K-ballo> oh, gsoc is over now?
pree has quit [Quit: AaBbCc]
<diehlpk_work> Yes
<diehlpk_work> Tuesday was last day
<hkaiser> heller: btw, did you get CUDA under control now? any progress?
<heller> hkaiser: no progress yet :/
bikineev has quit [Ping timeout: 255 seconds]
<github> [hpx] Naios opened pull request #2877: Require `std::array` by default (master...std_array) https://git.io/v58vR
<diehlpk_work> hkaiser, Did you have time to add the references to the paper?
<diehlpk_work> I like to write tomorrow my sections
<hkaiser> diehlpk_work: was planning to do this today
<diehlpk_work> Thanks, fits perfect to my schedule
<hkaiser> heller: we'll need that for theboostcamp :/
<heller> hkaiser: I know. I am working hard.
<jbjnr> what contribution do you want from me for the paper? I'm happy to write, but I need a section to work on and a "story" that we want to tell
<hkaiser> heller: thanks
K-ballo has quit [Ping timeout: 248 seconds]
K-ballo has joined #ste||ar
<hkaiser> K-ballo: the reason for still looking for boost_atomic...lib is just the lockfree queue, right?
<K-ballo> yes
<hkaiser> ok
<hkaiser> is that because tagged_ptr is not trivially constructible?
<hkaiser> K-ballo: ^^
<K-ballo> uhm
<K-ballo> that was the last build which attempted to patch the lockfree queue
<hkaiser> ok, so it's not trivially copyable
<K-ballo> note `boost::lockfree::deque_node` is an HPX type, not a boost one
<K-ballo> that got me confused for a while
aserio has joined #ste||ar
<K-ballo> IIUC a deque node holds like 6 or 8 pointers in it, and somehow has lockfree atomic assignment
<K-ballo> couldn't follow it
<hkaiser> yah
<hkaiser> K-ballo: that stuff is used in the ABP scheduler only
<hkaiser> K-ballo: we're going to clean up the schedulers soon, so this can go and we can get rid of boost atomic alltogether
<jbjnr> hkaiser: got a moment? if you have can you run "bin/simple_resource_partitioner --hpx:threads=1 --hpx:bind=balanced" and tell me if you get an exception about a future having no shared state please?
<hkaiser> jbjnr: sec
<jbjnr> and for a bonus point. tell me why it does that
<jbjnr> (if it does)
<hkaiser> :)
<hkaiser> will take a sec, need to build things
<jbjnr> ok. nvm
<jbjnr> I assumed you have a build already setup
<hkaiser> jbjnr, heller: OB call in 10 minutes
<hkaiser> just be patient ;)
<jbjnr> who's going to the mentor's summit this year?
<hkaiser> jbjnr: yah, seeing the same problem
<jbjnr> ok, thanks.
<hkaiser> jbjnr: let me work on the bonus point ;)
<hkaiser> it's future_4 (line 144)
<hkaiser> yah, broken example
<hkaiser> you don'tinitialize future_4 but still call .get() on it
<zao> {what}: this future has no valid shared state: HPX(no_state)
<zao> (I could repro too, but seems like you're faster than my puny 4-core to build :D)
<hkaiser> zao: have it fixed here already
<jbjnr> hkaiser: sorry. I didn't even look at the example itself yet - it must have gotten broken somewhere. Sorry to waste your time
<github> [hpx] hkaiser pushed 1 new commit to master: https://git.io/v58IV
<github> hpx/master d374d7c Hartmut Kaiser: Fixing example if run on one thread
<hkaiser> jbjnr: ^^
<jbjnr> thanks
<jbjnr> pushing to master. lovely. Let's hope the it police aren't watching
<jbjnr> ^git police
<hkaiser> shhhh
<hkaiser> it's a 'cosmetic' change ;)
<jbjnr> yup
<aserio> jbjnr, heller, david_pfander, wash[m]: Meeing time
<jbjnr> no microphone today - I'll have to listen only
<hkaiser> clang is looking for -latomic and can't find it
patg has joined #ste||ar
<hkaiser> K-ballo: nvm, seems like to be a rostam problem
<K-ballo> it is?
<hkaiser> it says: /usr/bin/ld: cannot find /usr/lib64/libatomic.so.1.0.0, which means that libatomic.so is there, but is a broken link
<K-ballo> libc++'s eric told me to add -latomic whenever including their <atomic> (but that it will only be actually needed for non lockfree specializations)
* K-ballo hasn't been paying attention to buildbot anymore, too much noise
<hkaiser> yah
denis_blank has quit [Quit: denis_blank]
hkaiser has quit [Quit: bye]
pree has joined #ste||ar
zbyerly_ has quit [Ping timeout: 260 seconds]
<aserio> wash[m]: you there?
mbremer has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
pree has joined #ste||ar
jaafar has joined #ste||ar
pree has quit [Ping timeout: 246 seconds]
pree has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
bikineev has joined #ste||ar
EverYoung has joined #ste||ar
bikineev has quit [Ping timeout: 255 seconds]
<aserio> K-ballo: yt? I have a C++ question
<K-ballo> aserio: here
<aserio> Hey, if I have a fuction foo that I want to overload like this:
<aserio> template<typename T, typename Ts ...ts> foo(T t, Ts ...ts){...}
<aserio> and then I have an overload foo(int b, Ts ...ts){..}
<aserio> will the compiler reliably choose the second if I pass an int?
Matombo has quit [Ping timeout: 248 seconds]
<aserio> or is this a case where I have to do template specialization
<K-ballo> exactly as written, it will prefer the one with `int`
hkaiser has joined #ste||ar
<K-ballo> (for arguments of type exactly `int`)
<aserio> right, no conversion
<aserio> so template specialization would be prefered?
<K-ballo> that's not a template specialization
<K-ballo> those have different rules
<aserio> Meaning this is not a case for template specialization?
<K-ballo> I feel uneasy about all the abstract aspects here, let me say that generally speaking the compiler prefers exact matches, and when exact matches result in a tie it prefers the more specialized one
<aserio> Thanks :)
<aserio> That makes sense
bikineev has joined #ste||ar
david_pfander has quit [Ping timeout: 240 seconds]
Matombo has joined #ste||ar
EverYoung has quit [Ping timeout: 252 seconds]
EverYoung has joined #ste||ar
<heller> aserio: is LSU open again?
<aserio> heller: yep
<aserio> It was just for the day
<heller> Good
bikineev has quit [Ping timeout: 240 seconds]
<heller> So no Arche needed?
<heller> Do you know if ali is making progress?
<jbjnr> heller: did you discover anything interesting re: dodgy executros with custom pools?
<aserio> Arche?
<aserio> heller: Ali will come in late today
<heller> If you see him, could you ask him to install libatomic on the nodes?
<aserio> he should be here soon
<aserio> ok
<heller> The thing that Noah built?
<aserio> oh and Arc
<jbjnr> Ark
<aserio> that ^^
bikineev has joined #ste||ar
EverYoun_ has joined #ste||ar
<github> [hpx] biddisco created fix_rp_again (+1 new commit): https://git.io/v58o1
<github> hpx/fix_rp_again 23d9710 John Biddiscombe: Fix incorrect pool usage masks setup in RP/thread manager
EverYoung has quit [Ping timeout: 240 seconds]
EverYoun_ has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<github> [hpx] biddisco opened pull request #2878: Fix incorrect pool usage masks setup in RP/thread manager (master...fix_rp_again) https://git.io/v58Kw
bikineev has quit [Remote host closed the connection]
akheir has joined #ste||ar
aserio has quit [Ping timeout: 246 seconds]
aserio has joined #ste||ar
hkaiser has quit [Ping timeout: 240 seconds]
bikineev has joined #ste||ar
<mcopik> has anyone got an idea how to resolve a conflict when headers from two libraries declare the same function in the global namespace?
<mcopik> both provide definitions for certain LAPACK functions
<mcopik> except, of course, removing definitions from one header. not including them is not an option, they are included automatically by each library whenever you try to use anything
aserio has quit [Ping timeout: 246 seconds]
akheir has quit [Remote host closed the connection]
aserio has joined #ste||ar
eschnett has quit [Quit: eschnett]
aserio has quit [Ping timeout: 255 seconds]
eschnett has joined #ste||ar
parsa has joined #ste||ar
<heller> mcopik: is it a c library?
<mcopik> heller: C++. LAPACK functions are defined with extern "C"
<heller> In any case, the only real option is to provide a header which wraps one of the functions putting it into some namep
<heller> Namespace
<heller> namespace foo { bar (); } would be the foo header
<heller> foo::bar would then call ::bar in it's own separate tu
pree has quit [Ping timeout: 246 seconds]
<heller> Gets complicated if you need some types from that library
<mcopik> heller: but this modification has to be performed inside the library, right?
aserio has joined #ste||ar
<heller> No, that's something you can do as third party
<heller> You can wrap anything and hide everything
<zao> (except macros \o/)
<zao> And it also hoses system headers.
zbyerly_ has joined #ste||ar
aserio has quit [Quit: aserio]
Matombo has quit [Remote host closed the connection]
parsa has quit [Quit: Zzzzzzzzzzzz]
zbyerly_ has quit [Ping timeout: 260 seconds]
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
<mcopik> heller: right, I see. wrapping the whole library by putting the relevant include inside the namespace
hkaiser has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
EverYoun_ has quit [Ping timeout: 252 seconds]
parsa has quit [Quit: Zzzzzzzzzzzz]
hkaiser_ has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar