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
twwright_ has joined #ste||ar
diehlpk has joined #ste||ar
twwright_ has quit [Quit: twwright_]
twwright_ has joined #ste||ar
<hkaiser>
mbremer: here
<hkaiser>
mbremer_: ^^
<mbremer_>
I'm having some issues with on_migrated
<hkaiser>
what's up there?
<mbremer_>
It looks like the component doesn't always wait for on_migrated to finish before executing functions
<mbremer_>
or more correctly actions (not functions)
<hkaiser>
hmmm, shouldn't happen, but who knows...
<hkaiser>
mbremer_: on_migrated shouldn't do anything asynchronous
<mbremer_>
I have seen the comments on migrate_component. I probably need to dig through that more then.
<mbremer_>
That example I sent you does fail frequently though. Although it seems more likely to fail if I invoke, migrate_component on the locality the component will be migrated to.
<ctnguyen>
I am looking for a C++ library that can be used for my job
<heller>
ok
<ctnguyen>
I found a lot of various implementations like TBB, fastflow, raftlib ... and of course HPX
<heller>
how can we help you?
<ctnguyen>
my need is to be able to implement an execution graph, (in form DAG). I just need to implement what a node does, and the rest of scheduling, switching context etc would be left to the library/framework
<ctnguyen>
Then I just need to write a config file, with a C++ code that parse that config file, then creates all the node and dependencies , then run the execution graph in the right order
<ctnguyen>
do you thing HPX is the right library to do it?
<heller>
I think so, yes
<ctnguyen>
awesome, thanks for the answer
<ctnguyen>
I'll have a look to the documentation
<ctnguyen>
Looks like the lib is very well maintained
AnujSharma has joined #ste||ar
AnSh has joined #ste||ar
AnujSharma has quit [Client Quit]
AnSh has quit [Client Quit]
AnujSharma has joined #ste||ar
nikunj has joined #ste||ar
david_pfander has joined #ste||ar
K-ballo has joined #ste||ar
AnSh has joined #ste||ar
AnujSharma has quit [Ping timeout: 260 seconds]
hkaiser has joined #ste||ar
diehlpk_mobile has joined #ste||ar
mcopik has joined #ste||ar
diehlpk_mobile has quit [Ping timeout: 268 seconds]
<nikunj>
hkaiser: so I was able to integrate my code into cmake by creating an option in add_hpx_executable
Anushi1998 has quit [Quit: Bye]
<nikunj>
by the name of INCLUDE_HPX_MAIN (name can change if you want to)
AnujSharma has quit [Ping timeout: 264 seconds]
<hkaiser>
k
<nikunj>
so whenever I include this option it would link with my static library and add correct linker flags as well
<hkaiser>
cool
<hkaiser>
what happens if this is specified for an executable that does not #include hpx_main.hpp?
<nikunj>
I have tested it with a few test directories and it works well. Should I continue with this method?
<nikunj>
It will still link but it would not work
<hkaiser>
can you make it fail compiling instead?
<nikunj>
since my linker files depends upon a #define in hpx_main
<hkaiser>
also, what happens if this flag is not specified, but you still #include hpx_main.hpp?
<nikunj>
then it will not link and the generated executable will throw runtime error
<hkaiser>
both cases should fail, preferrably at compile time with a sensible message
<nikunj>
hkaiser: how do I identify if hpx_main is included or not?
<hkaiser>
either add a #define there or use the existing one
<hkaiser>
also, you can check inside hpx_main.hpp, if needed
david_pfander has quit [Ping timeout: 245 seconds]
<hkaiser>
have a #error there, for instance
<nikunj>
does cmake responds to #defines in c++ files as well?
<hkaiser>
no
<hkaiser>
but compilation responds to pp constants specified from the cmake env
anushi has quit [Ping timeout: 265 seconds]
<nikunj>
ok
<nikunj>
hkaiser: I'm not aware of it in the context of cmake, would you please suggest any resources from where I could study and then implement it?
<K-ballo>
cmake scripts run at configuration time, compilation time is during build time
<K-ballo>
configure -> build -> run
<hkaiser>
nikunj: you can define pp constants at configuration time by using add_definitions() (or add_hpx_definition() in our case) which is then added to the compilation
<hkaiser>
this can be used at compile time (using a #if FOO/#endif) to check whether it was specified or not
<nikunj>
ok, I will look into it and implement the same
<mbremer>
I'm printing when agas::end_migration gets called and when the migrate_component_action returns, and it looks like agas::end_migration gets called before the future returns.
K-ballo has quit [Quit: K-ballo]
zura has quit [Ping timeout: 256 seconds]
<mbremer>
@hkaiser: it looks like adding an launch::async fixes my bug...
zura has joined #ste||ar
K-ballo has joined #ste||ar
zura has quit [Ping timeout: 265 seconds]
eschnett has joined #ste||ar
zura has joined #ste||ar
mbremer has quit [Quit: Page closed]
<hkaiser>
mbrthat all doesn't make sense :/
aserio has quit [Ping timeout: 260 seconds]
mbremer has joined #ste||ar
<mbremer>
@hkaiser: Any recommendations on how to proceed? I can reduce my mini-app even further and just open an issue.
<mbremer>
It actually looks like migration works for me now. I'm going to run dgswem like 100 times just to be safe, but the first few runs have been deterministic and agree with the no-migration results.
<hkaiser>
mbremer: what did you mean by saying 'adding an async makes it work'?
<mbremer>
Here, I made the first argument launch::async
<mbremer>
and then the second argument is the lambda
<hkaiser>
ok, that just delays the execution slightly as teh continuation is scheduled to run on a new thread
anushi has joined #ste||ar
<hkaiser>
this might just hide your problem
<hkaiser>
this .then() should be called only after the function that runs on_migrated has returned
<mbremer>
For whatever reason, it didn't look like that to me.
<mbremer>
I know printf debugging is dubious, but I had on_migrated sleep for ten seconds.
<mbremer>
And I print a statement after agas::end_migration immediately, and then ten seconds later the future assocaited with migrate_component_action returns
<hkaiser>
unexpected
<mbremer>
could it be that there's a launch::apply somewhere that influences the following future's launch policies?
<hkaiser>
mbremer: could you try reverting #3283 and try again?
<mbremer>
Ya, I"ll try it. I have a meeting at 1. I'll let you know how it goes
<hkaiser>
tks
mbremer has quit [Quit: Page closed]
anushi has quit [Ping timeout: 245 seconds]
mcopik has quit [Ping timeout: 256 seconds]
anushi has joined #ste||ar
anushi has quit [Remote host closed the connection]
zura has quit [Ping timeout: 240 seconds]
quaz0r has quit [Ping timeout: 264 seconds]
aserio has joined #ste||ar
galabc has quit [Quit: Leaving]
quaz0r has joined #ste||ar
zura has joined #ste||ar
aserio1 has joined #ste||ar
diehlpk_work has quit [Remote host closed the connection]
diehlpk_work has joined #ste||ar
aserio has quit [Ping timeout: 260 seconds]
aserio1 is now known as aserio
zura has quit [Ping timeout: 245 seconds]
zura has joined #ste||ar
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
aserio has quit [Ping timeout: 256 seconds]
K-ballo has joined #ste||ar
aserio has joined #ste||ar
mbremer has joined #ste||ar
mbremer has quit [Client Quit]
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 255 seconds]
aserio1 is now known as aserio
eschnett has quit [Quit: eschnett]
zura has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
jakub_golinowski has joined #ste||ar
<nikunj>
hkaiser: yt?
bibek has quit [Quit: Konversation terminated!]
bibek has joined #ste||ar
bibek has quit [Client Quit]
<hkaiser>
here
<nikunj>
I checked out the documentation of add_defintions. I didn't understand how it would help us?
<hkaiser>
add_definitions(-DFOO=1) add a compiler command line option -DFOO=1
<hkaiser>
add_hpx_definitions(FOO 1) adds an entry to our config.hpp file #define FOO 1, that in the end has the same effect
<nikunj>
yes it does. But how do I identify if hpx_main.hpp is added using that?
<hkaiser>
the latter is preferred as it propagates through to applications using HPX
<nikunj>
To confirm if #define FOO 1, I will have to change the src code (i.e. example/test files)
<nikunj>
How can I confirm the same through cmake?
<hkaiser>
cmake has to be handled separately
<hkaiser>
add_hpx_option(FOO ...) defines a cmake configuration constant which you can then check using if(FOO)
<nikunj>
hkaiser: oh I see. I took care of the #defines in my src/hpx_wrap.cpp so that part has been taken care of.
<hkaiser>
just try to understand how its done for the other cfg settings