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
<jbjnr__>
code cleanup?
EverYoung has quit [Ping timeout: 276 seconds]
EverYoun_ has quit [Ping timeout: 276 seconds]
EverYoung has joined #ste||ar
EverYou__ has joined #ste||ar
EverYoung has quit [Read error: Connection reset by peer]
EverYou__ has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
Anushi1998 has quit [Remote host closed the connection]
Anushi1998 has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
Anushi1998 has quit [Remote host closed the connection]
Anushi1998 has joined #ste||ar
Anushi1998 has quit [Remote host closed the connection]
Anushi1998 has joined #ste||ar
Anushi1998 has quit [Remote host closed the connection]
Anushi1998 has joined #ste||ar
EverYoun_ has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
K-ballo has quit [Quit: K-ballo]
eschnett has joined #ste||ar
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
hkaiser has quit [Client Quit]
eschnett has quit [Quit: eschnett]
parsa has joined #ste||ar
nanashi55 has quit [Ping timeout: 256 seconds]
parsa has quit [Quit: Zzzzzzzzzzzz]
nanashi55 has joined #ste||ar
Nikunj_ has joined #ste||ar
<github>
[hpx] victor-ludorum opened pull request #3193: Updating Runtime.cpp by adding correct description of Performance counters during register (master...Update_runtime.cpp) https://git.io/vAVVb
david_pf_ has joined #ste||ar
david_pf_ has quit [Ping timeout: 265 seconds]
david_pf_ has joined #ste||ar
<github>
[hpx] cogle opened pull request #3194: parallel::{fill|fill_n} updated for Ranges TS. (master...fill_ranges_update) https://git.io/vAV6U
Smasher has joined #ste||ar
Anushi1998 has quit [Read error: Connection reset by peer]
Anushi1998 has joined #ste||ar
anushi has joined #ste||ar
Anushi1998 has quit [Read error: Connection reset by peer]
hari_ has joined #ste||ar
anushi has quit [Ping timeout: 276 seconds]
hari_ has quit [Quit: Page closed]
anushi has joined #ste||ar
<github>
[hpx] biddisco created fixing_3195 (+1 new commit): https://git.io/vAVHc
<github>
hpx/fixing_3195 d2540c3 John Biddiscombe: Remove an extra async apply forwarding that is overloaded already
<github>
[hpx] biddisco opened pull request #3196: Remove an extra async apply forwarding that is overloaded already (master...fixing_3195) https://git.io/vAVHl
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 264 seconds]
nanashi64 is now known as nanashi55
anushi has quit [Ping timeout: 276 seconds]
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
anushi has joined #ste||ar
anushi has quit [Read error: Connection reset by peer]
anushi has joined #ste||ar
Nikunj_ has quit [Ping timeout: 260 seconds]
anushi has quit [Read error: Connection reset by peer]
anushi has joined #ste||ar
anushi has quit [Ping timeout: 256 seconds]
anushi has joined #ste||ar
david_pf_ has quit [Quit: david_pf_]
anushi has quit [Read error: Connection reset by peer]
anushi has joined #ste||ar
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
K-ballo has joined #ste||ar
Anushi1998 has joined #ste||ar
anushi has quit [Remote host closed the connection]
Anushi1998 has quit [Read error: Connection reset by peer]
<Nikunj>
The third one is overriding initial environment functions with our own functions which setup the hpx and then compiling without any startfile (i.e. g++ -nostartfiles -o foo bar.cpp)
<Nikunj>
Also, from all the examples I see, I couldn't find a search example. So I could implement binary search example (in quickstart directory) using the desired runtime replacement.
<hkaiser>
nikunj: what do yo mean by global object 'followed by' overriding the env functions?
<Nikunj>
by that I mean that we discussed about global objects the other day, I found a similar way that simply overrides the initial environment functions like _start()
<hkaiser>
ok
<hkaiser>
the global object is nice in principle, but prone to initialization sequence problems
<hkaiser>
so it most likely would require changes to other parts of hpx
<hkaiser>
(utill:function is most probably one of those spots that need attention)
<hkaiser>
whereas initializing hpx explicitly after all other global constructors have run would avoid the issue
<hkaiser>
otoh, overriding the env functions is not portable
<Nikunj>
I see. But I feel that it is currently the best. The other way out is to define an initialize.hpp which initializes the initial environment functions to run hpx_main
<hkaiser>
nikunj: the problem is not the implementation, the problem is to find the best way to invoke it
<Nikunj>
@hkaiser: For that we can either work on custom hooks (complex but the best way) or initialize the environment functions and disable those implemented by gcc
<Nikunj>
I do find the latter as a good way as it simplifies things and requires the least amount of changes in the code base itself. This way compiling code will also be only a bit different since we need to compile with nostartfiles
<hkaiser>
nikunj: what about clang? msvc?
<Nikunj>
I'm still working on finding ways to implement the same in clang and mscv.
<Nikunj>
Since the project in itself is quite big, I felt that I should first focus implementing the same with gcc while looking up for efficient ways to implement the same for clang and mscv
<Nikunj>
@hkaiser: What do you think about initializing and registering hpx threads and hpx_main through the initial environment functions?
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi64 is now known as nanashi55
<hkaiser>
nikunj: if it works - why not
<Nikunj>
@hkaiser: Should I try implementing an example with that approach (just to check how functional can it be)?
<hkaiser>
nikunj: sure, trying thing sout is always a good idea
<Nikunj>
Ok, then I'll start working on an example which implements through overriding the initial variables. Also from what I've found out every compiler initially runs a set of functions (_start() in case of g++) which set up the linking and entry point. So if we could implement it in gcc then we can surely implement it in clang and msvc.
<hkaiser>
k
<Nikunj>
Also, about that that PR. circle seems to have issue finding c++ command which means that a compiler has to be added to circle if we wish to do the hello.sh way. What should I do (the build log is given above)?
<hkaiser>
nikunj: but the rest of the builds pass, so there is a compiler available, no?
<hkaiser>
nikunj: I'd suggest that you download the docker image and try it locally before experimenting with circleci, that's much more efficient than to have ot wait for it to cycle
<Nikunj>
@hkaiser: That's what bugging me from the morning. The issue seems to be confined to hello.sh file only
<hkaiser>
k
<hkaiser>
nikunj: heller_ might be able to help, he set up the circleci docker image
<Nikunj>
cmake runs perfectly fine without any issue but the make command returns with an error that c++ command is not found.
<hkaiser>
k
<Nikunj>
@hkaiser: Ok, in that case I'll take help from @heller_ to set up the docker locally.
<Nikunj>
That should be a wrap up I guess. I'll start working on implementing and experimenting with examples :)
<Nikunj>
@hkaiser: Thank you for the help
<hkaiser>
most welcome
<jbjnr__>
hkaiser: ok, the pool executor is a problem after all it seems
<jbjnr__>
or at least the launched_process test died and caused all the others to time out
<hkaiser>
jbjnr__: I agree that something has to be done to avoid going through the executors twice
<jbjnr__>
but that extra call costs me %%
<jbjnr__>
ok. See your comment
<hkaiser>
understand
<jbjnr__>
I've forgotten all I knew about the customization stuff unfortunately
<hkaiser>
I'd like to help - not sure how much time I can invest however, the things on my desk a piling up to the ceiling, currently
<hkaiser>
are*
<jbjnr__>
I'll do it, but any hints you can give are welcome
<hkaiser>
ok
<jbjnr__>
I will look at the async execute you suggested in the pr link
<hkaiser>
not sure if that's the right spot
<jbjnr__>
I;ll start on my backtrasce and look everywhere related
<hkaiser>
nod, good thinking
<jbjnr__>
(that's pretty much how all debugging in hpx is done for me :( )
<hkaiser>
jbjnr__: is there another way?
<jbjnr__>
a brain in a jar with 'total knowledge' would help
<hkaiser>
lol
<jbjnr__>
(I usually ask you as my proxy for that)
<jbjnr__>
the brain is there, but not the jar!
<hkaiser>
jbjnr__: keep in mind there are currently two independent implementations of the customization points
<jbjnr__>
ok, tell me more
<jbjnr__>
I will remember it eventually
<hkaiser>
one for the 'old' thread-executors (i.e. pool_executor) and one for the newer default executors (i.e. parallel_executor
<jbjnr__>
(I did know this stuff quite well some time ago)
<jbjnr__>
so it's time to upgrade the old ones then
<hkaiser>
the implementation sare in executors/execution.hpp and executors/thread_execution.hpp
<jbjnr__>
does this also explain why scheduled_thread_executor derives from a differnt base type
victor_ludorum has quit [Quit: Page closed]
<hkaiser>
shrug, that's the whole point of having customization points - allowing for custom scheduling APIs to be easily adapted
<jbjnr__>
(which is also annoying)
<hkaiser>
yah, those are the thread-executors, they all are derived from the scheduled_thread_executor type
<jbjnr__>
had to disappaer for a minute - thanks hkaiser for the info. will play with it now
diehlpk has joined #ste||ar
Nikunj has quit [Quit: Page closed]
eschnett has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
eschnett has quit [Quit: eschnett]
<jbjnr__>
hkaiser: I think the behaviuor is correct and it's just my specializations of the guided_pool_exxecutor that need attention
<hkaiser>
jbjnr__: ok
<jbjnr__>
the two calls via cuatomization point are from the guided_pool wrapper (1) and then the actual inner executor (2) so my speed loss is just a bad implementation of pool executor underneat compared to default executor (I think)
<hkaiser>
jbjnr__: would a specialization of the customization points for your executor help short-cutting things?
<jbjnr__>
that's what I'm looking into now - the customization point stuff is where you made lots of changes, so I need to experiment a bit
<jbjnr__>
I have it under control (sort of)
<hkaiser>
look at the thred_execution.hpp to see how to specialize things for custom executors
<github>
[hpx] hkaiser force-pushed fixing_3182 from 6fac8f1 to 9f8694e: https://git.io/vAaOj
<github>
hpx/fixing_3182 9f8694e Hartmut Kaiser: Fixing return type calculation for bulk_then_execute....
<diehlpk>
hkaiser, 3 answers are missing, but if you have time you can have a look on my answers for the interview about gsoc
parsa has joined #ste||ar
<hkaiser>
diehlpk: will do, when do you need this?