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/ | GSoC2018: https://wp.me/p4pxJf-k1
<github>
[hpx] hkaiser closed pull request #3384: This hopefully fixes two tests that occasionally fail (master...fixing_tests) https://git.io/fNsqt
<Guest68551>
[hpx] hkaiser closed pull request #3383: Making sure thread local storage is enable for hpxMP (master...hpxmp_thread_local_storage) https://git.io/fNOy9
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
nikunj has joined #ste||ar
nikunj has quit [Client Quit]
parsa[[w]] has joined #ste||ar
parsa[w] has quit [Ping timeout: 265 seconds]
nanashi55 has quit [Ping timeout: 256 seconds]
nanashi55 has joined #ste||ar
quaz0r has quit [Ping timeout: 244 seconds]
quaz0r has joined #ste||ar
diehlpk_work_ has joined #ste||ar
parsa[[w]] has quit [*.net *.split]
diehlpk_work has quit [*.net *.split]
bibek has quit [*.net *.split]
jbjnr_ has joined #ste||ar
<github>
[hpx] biddisco created gsoc_fflib (+1 new commit): https://git.io/fNGZa
<github>
hpx/gsoc_fflib c3b78ba John Biddiscombe: Add function to get default parcelport from parcelhandler
parsa[[w]] has joined #ste||ar
bibek has joined #ste||ar
nanashi55 has quit [Ping timeout: 248 seconds]
jaafar has quit [Quit: Konversation terminated!]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 268 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 244 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 264 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 244 seconds]
nanashi55 has joined #ste||ar
david_pfander has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
heller__ has joined #ste||ar
heller_ has quit [Read error: Connection reset by peer]
<github>
hpx/gsoc_fflib 25e4661 John Biddiscombe: Turn off trace messages for clarity
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 248 seconds]
nanashi55 has joined #ste||ar
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 276 seconds]
nanashi64 is now known as nanashi55
nanashi55 has quit [Ping timeout: 260 seconds]
nanashi55 has joined #ste||ar
jbjnr_ has quit [Ping timeout: 265 seconds]
jbjnr_ has joined #ste||ar
nanashi55 has quit [Ping timeout: 260 seconds]
nanashi55 has joined #ste||ar
nanashi55 has quit [Ping timeout: 276 seconds]
nikunj has joined #ste||ar
nanashi55 has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 268 seconds]
nanashi64 is now known as nanashi55
<nikunj>
hkaiser, yt?
<hkaiser>
here
<nikunj>
hkaiser, I changed the PR accordingly
<nikunj>
Also, do you think I can test the error message somehow?
<nikunj>
So that I could add a test for it as well
<hkaiser>
nikunj: thanks, I'll have a look
<hkaiser>
need to think about this
<nikunj>
hkaiser, I'll think as well.
<nikunj>
hkaiser, In the meantime I'll look into the prospects of adding our own implementation of mainCRTStartup and the init function I talked about.
<hkaiser>
ok, cool
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 268 seconds]
nanashi64 is now known as nanashi55
jakub_golinowski has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj97 has joined #ste||ar
nikunj has quit [Ping timeout: 276 seconds]
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi64 is now known as nanashi55
hkaiser has quit [Quit: bye]
eschnett has joined #ste||ar
aserio has joined #ste||ar
hkaiser has joined #ste||ar
<nikunj97>
hkaiser, yt?
aserio has quit [Ping timeout: 245 seconds]
aserio has joined #ste||ar
nikunj97 has quit [Ping timeout: 245 seconds]
eschnett has quit [Quit: eschnett]
aserio has quit [Ping timeout: 276 seconds]
aserio has joined #ste||ar
galabc has joined #ste||ar
jaafar has joined #ste||ar
jaafar has quit [Remote host closed the connection]
jaafar has joined #ste||ar
jakub_golinowski has quit [Quit: Ex-Chat]
jakub_golinowski has joined #ste||ar
nikunj has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
aserio has quit [Ping timeout: 244 seconds]
diehlpk has joined #ste||ar
diehlpk has quit [Remote host closed the connection]
jbjnr_ has quit [Quit: WeeChat 2.1]
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 276 seconds]
quaz0r has quit [Ping timeout: 240 seconds]
<nikunj>
hkaiser, when you say " I'd say either add it everywhere or just for the definition." you mean adding it everywhere (like it was before) or adding only to the weak symbol in hpx_init, right?
<hkaiser>
nikunj: yes, I'd prefer the latter, but it's up to you
<heller__>
nikunj: so, can I use your stuff even without including hpx_main.hpp?
<nikunj>
heller__, no
<nikunj>
hkaiser, I had added a new commit which adds it to definition only.
<nikunj>
heller__, basically if you include hpx_main.hpp and then call hpx_init then instead of getting the regular error message of hpx::init can't initialize you'll get a more verbose message saying that hpx is already initialized from main
<hkaiser>
k
<nikunj>
heller__, Along with that you will get a note asking you to remove instances of hpx_main from source files if the user wishes to use hpx::init function to initiate the hpx system
<nikunj>
heller__, making my code run without including hpx_main can also be made possible but that would call for an alternate approach where we will need a flag in add_hpx_executable which would decide the linking of libhpx_wrap.a
<nikunj>
hkaiser and I discussed over it and came to the conclusion that we do not want to add any overheads on the part of user. Therefore I used weak symbol linking to get work done at runtime by linking libhpx_wrap.a with every executable and determining the function stack depending upon a shadow variable in hpx_main
<nikunj>
so hpx_main is necessary for the correct working of my implementation. This way, for the user things will remain exactly as it used to be.
nikunj has quit [Quit: Leaving]
<heller__>
Hmm, wouldn't it make sense to have hpx::init working even in the presence of the main wrapper?
eschnett has joined #ste||ar
<heller__>
So the use case I'm thinking about: you have a library which uses hpx as an implementation detail. That is, no hpx header should leak to the user code. Here I'd like the hpx backend to work without changing the user code of said library (no additional includes etc). And the end game would then be, that if a user code, in addition, uses hpx_init, it just keeps on working
<heller__>
Not that this has to be solved within gsoc.. but we should at least consider it
nikunj has joined #ste||ar
<heller__>
nikunj:
<nikunj>
heller__, here
<heller__>
Hmm, wouldn't it make sense to have hpx::init working even in the presence of the main wrapper?
<heller__>
heller__ So the use case I'm thinking about: you have a library which uses hpx as an implementation detail. That is, no hpx header should leak to the user code. Here I'd like the hpx backend to work without changing the user code of said library (no additional includes etc). And the end game would then be, that if a user code, in addition, uses hpx_init, it just keeps on working
<heller__>
heller__ Not that this has to be solved within gsoc.. but we should at least consider it
<heller__>
The concrete use case I'm thinking about is the work done by jakub_golinowski
<heller__>
The hpx backend for opencv
<nikunj>
heller__, so you want things to work out in a way where we could initialize hpx runtime twice (once from main, next if user adds hpx::init) and things work normally?
aserio has joined #ste||ar
akheir has joined #ste||ar
<jakub_golinowski>
heller__, nikunj: If I understand heller__ correctly he means that: (1) there is no need to do #include hpx_main.hpp in the user application for the runtime to be automatically launched as it is now in case of hpx_main.hpp inclusion. (2) However, in case the use uses hpx_init construct in his code the automatic runtime start is abandoned and the code works as it would work now without hpx_main.hpp inclusion.
<heller__>
nikunj: right
<heller__>
jakub_golinowski: correct
<heller__>
In the second case, you could just enqueue hpx_main (or whatever is passed)
<heller__>
This would also be beneficial for hpxmp
<nikunj>
heller__, I think that can be done
<heller__>
Cool!
<nikunj>
heller__, but I do not think I will be able to make it robust in the current time frame. I do think that something like this can be done.
<heller__>
Sure
<nikunj>
heller__, just to make sure. The user can only invoke hpx::init once, right?
<heller__>
The hard thing, probably, will be the interaction with hpx:: finalize
<heller__>
Currently: once it returned, you can call it again. It blocks until the application finishes
<nikunj>
heller__, one easier way that I look at is to probably wrap one of the init functions and check whether the current hpx system is running. In case it is running then we can proceed to finalize it and re-initiate the hpx runtime system
<nikunj>
that is one implementation I can think of at the top of my mind
<heller__>
Nested hpx::init calls is not handled right now, iirc
<heller__>
Na, that's not good
<heller__>
Initializing hpx is expensive
<nikunj>
I see
<nikunj>
Then we will have to somehow reinitiate everything without initializing the complete hpx runtime
<heller__>
I had a user once that used /usr/bin/time for benchmarking... He was never happy
<heller__>
Why? Once it's initialized, just go ahead
<heller__>
Count the number of initializations, once that drops to zero, finalize
<heller__>
Each call to init increments, each call to finalize decrements
<heller__>
Aka reference counting the number of init calls with the number of finalize calls
<nikunj>
heller__, I see so we this way we can allow for multiple inits as well
<nikunj>
and take care of finalizing everything in the backend
<heller__>
Yup
<heller__>
Some care has to be taken for startup and shutdown functions
<heller__>
That is, have them stick to the right level
<nikunj>
heller__, jakub_golinowski: if we were to abandon the code for automatic runtime start with hpx_main. We could do something similar by ignoring the call to init as well.
<nikunj>
hpx init^^
<nikunj>
Things would still work normally
<nikunj>
but that would discard any initializations pertaining to init so I don't think it will be a nice idea
<nikunj>
heller__, it sounds like a nice integration. I will think how I can implement it. I'll have to take a deeper look at core hpx initializations to understand how we can achieve such behavior effectively.
quaz0r has joined #ste||ar
jbjnr_ has joined #ste||ar
<hkaiser>
K-ballo: yt?
<K-ballo>
here
<hkaiser>
K-ballo: the format customization point relies on function overload
<K-ballo>
ADL, yes
<hkaiser>
this is a bit annoying as all possible overloads need to be defined ahead of time
<K-ballo>
uh?
<K-ballo>
no, it uses the same ADL mechanism operator<< uses
<hkaiser>
K-ballo: we're seeing that the CP dispatches to the wrong function
<K-ballo>
might be a bug
<hkaiser>
(at least with clang, MS does the expected thing - not sure if it's the right thing, though)
<K-ballo>
the CP isn't actually the one that dispatches
<hkaiser>
what would you suggest?
<K-ballo>
I'd suggest a minimal test case, but showing me the code might be enough
<jbjnr_>
hkaiser: just an update. Compiled GCC toolchain on powerpc and most of the failing tests now pass. All the partitionvector stuff is still rubbish, but the toekn cancellation doesn't seem to be causing trouble.
<jbjnr_>
must be something strange that clang is doing
<K-ballo>
(side observation) that code is messing with hpx::util, it shouldn't
<K-ballo>
which call(s) end up dispatching to the wrong function?
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 240 seconds]
aserio1 is now known as aserio
galabc has quit [Quit: Leaving]
<K-ballo>
ah, that's why clang complains and msvc eats it, lack of 2 phase name lookup
<K-ballo>
void format_value(std::ostream& os, boost::string_ref spec, phylanx::execution_tree::primitive_argument_type const& value) should be in phylanx::execution_tree, for ADL to find it
quaz0r has quit [Ping timeout: 255 seconds]
hkaiser has quit [Read error: Connection reset by peer]
akheir has quit [Remote host closed the connection]
parsa[[[w]]] has joined #ste||ar
akheir has joined #ste||ar
parsa[[w]] has quit [Ping timeout: 276 seconds]
<K-ballo>
..hello?
parsa[[[w]]] is now known as parsa[w]
<zao>
beep boop
<K-ballo>
received
<parsa[w]>
ehlo
aserio has quit [Quit: aserio]
aserio has joined #ste||ar
aserio1 has joined #ste||ar
quaz0r has joined #ste||ar
aserio has quit [Ping timeout: 255 seconds]
aserio1 is now known as aserio
nikunj has quit [Quit: goodnight]
nanashi55 has quit [Ping timeout: 248 seconds]
nanashi55 has joined #ste||ar
jakub_golinowski has quit [Quit: Ex-Chat]
jbjnr_ has quit [Ping timeout: 240 seconds]
aserio has quit [Ping timeout: 240 seconds]
akheir has quit [Quit: Leaving]
hkaiser has joined #ste||ar
<hkaiser>
K-ballo: makes sense, thanks
nanashi55 has quit [Ping timeout: 245 seconds]
nanashi55 has joined #ste||ar
<github>
[hpx] hkaiser created small_vector_dataflow (+1 new commit): https://git.io/fNZdH
<github>
hpx/small_vector_dataflow bdfc6f3 Hartmut Kaiser: Adding support for boost::container::small_vector to dataflow
<github>
[hpx] hkaiser opened pull request #3386: Adding support for boost::container::small_vector to dataflow (master...small_vector_dataflow) https://git.io/fNZdh