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/
<Yorlik>
Its the initial learning curve. I expect stuff to get easier later on. I'm missing a ton of low level knowledge and experience I need to acuire now.
<Yorlik>
It's just work ;)
<Yorlik>
The good thing is, it's really fun.
<K-ballo>
parsa: do you know if it requires an extension? that worked on one machine but not another
<K-ballo>
one of the machines has the "enable debugging tools" option (set), the other one doesn't even have that
<parsa>
K-ballo: no extension needed. even VS community has it
<parsa>
what!
<K-ballo>
...
<K-ballo>
I'm puzzled
<parsa>
does it have Debug->Windows?
<K-ballo>
yes it does, though the contents change depending on projcet and such
<parsa>
like .Net projects?
<K-ballo>
lol, all the options in options -> debugging are set to the same values, except for debugging tools which is just missing
<K-ballo>
I also don't have the just-in-time options category
<K-ballo>
and also also it doesn't have the "automatically close console option set", but it closes anyways
<parsa>
i thought they changed the default to close the console automatically and you had to explicitly change the subsystem to console to avoid it
jbjnr__ has quit [Read error: Connection reset by peer]
<K-ballo>
I wonder if it could be affected by some OS setting
<K-ballo>
there's something called "Performance Tools" I don't have, maybe I did not install it
Yorlik has quit [Read error: Connection reset by peer]
Yorlik has joined #ste||ar
khuck has quit []
hkaiser has quit [Quit: bye]
parsa is now known as parsa_
daissgr has joined #ste||ar
<zao>
Once upon a time one got to select "C#" or "C++" keybinds, which also messed with layout. Menu item ought to always be there tho.
<zao>
Odd.
jbjnr has joined #ste||ar
jbjnr_ has joined #ste||ar
daissgr has quit [Ping timeout: 250 seconds]
<jbjnr_>
so .....
<jbjnr_>
with all my changes to the shared-priority-scheduler and the lockfree queues, I'm seeing a 3x speedup in overall throughput on 4 or 8 threads and on the other schedulers we're getting a 5%-40% speedup. So now they are all faster and the shared-priority is as good as all the others. Except one test which puts the shared-priority just behind.
<jbjnr_>
I will compile some stats and plot some graphs. Overall. I'm quite pleased with myself.
<simbergm>
jbjnr_: yes?
<jbjnr_>
this is for the future_overhead test which is really just stress testing the queues and schedulers with no actual work
<simbergm>
awesome, you should be :)
<simbergm>
what else did you do than replace the queue?
<jbjnr_>
the bad news is that the new fifo queue is much better than the boost one, but it doesn't run as a dequeue, so we can't steal from the wrong end.
<jbjnr_>
for the existing schedulers, just replacing the lockfree queue is all i have done. But the shared-priority has been realy cleaned up a lot
<jbjnr_>
example: shared-priority master branch 1.585287 us per future
<simbergm>
it can still replace the fifo queue
<jbjnr_>
example: shared-priority JB branch 0.430741 us per future
<simbergm>
nice
<jbjnr_>
on 8 threads
<jbjnr_>
on 1 thread there is not so much difference.
<simbergm>
run it on 36 ;)
<jbjnr_>
I will\
<jbjnr_>
I have the tests ready for daint and for the AMD 8 numa node machine
<simbergm>
ok
<jbjnr_>
but I need to produce a graph plotting script
<jbjnr_>
so I can really see all the results in one place.
<jbjnr_>
the real win is that we can remove an aloc/dealloc completely from every single task in thread_queue
<simbergm>
how did that happen?
<jbjnr_>
cos the new queue can hold hpx:util::tuple<stuff> instread of a pointer to one
<jbjnr_>
so no need to allo one every time
<jbjnr_>
if you scroll up, you'll see some chat from late last night fixing the tuple class
<simbergm>
yeah, I saw that and didn't understand how it was related
<simbergm>
now I do
<jbjnr_>
K-ballo: is completely awesome, (but I'm glad I persevered and poked around until I found what was wrong).
<heller_>
jbjnr_: probably does the allocation internally instead
<jbjnr_>
it reserves space in blocked chunks at start and when resizing and uses move to copy values in/out. Seems pretty awesome.
<heller_>
ok
<heller_>
good
<simbergm>
I hate cmake
<simbergm>
diehlpk_work: I know roughly what's wrong but I'm not sure it's our fault/problem
<simbergm>
jbjnr_: it's not an rvalue if it's called data!?
<simbergm>
ignore me
<simbergm>
I'm silly
<simbergm>
you meant the other move
<jbjnr_>
(I'm happy with the second version where I drop the first move).
<jbjnr_>
the second move is needed regardelss.
<jbjnr_>
i just get confused sometimes ...
mdiers_ has quit [Read error: Connection reset by peer]
mdiers_ has joined #ste||ar
<heller_>
jbjnr_: yes, move isn't needed here
<jbjnr_>
ta
<heller_>
the first one that is
<jbjnr_>
PR submitted just now on selfcontained lockfree stuff
<heller_>
a newly created object is an rvalue
<heller_>
a move is just a cast to an rvalue
<jbjnr_>
yup. Sorry to waste your time
<heller_>
nice!
<heller_>
no problem
<heller_>
getting there with the cuda stuff...
<Yorlik>
Do I understand correctly, that a locality essentially also is just represented as a global object in AGAS, because it is retrieved as an hpx::id_type?
<simbergm>
btw jbjnr_, your pr is exactly the kind of thing we need to avoid openmp silliness, so thanks for doing that
<simbergm>
I'll be rerunning my benchmarks once that goes in
<jbjnr_>
simbergm: NB. I have a two more big PRs incoming. One for Numa allocators and some cleanup, another for the shared-priority-scheduler. Don't think they will affect your benchmarks, but now I feel like I understand the thread queing quite well, so I will have another go at the stack cleanup soon.
<jbjnr_>
my last attempt at stack init on the lazy-stack branch resulted in slowdowns :(
<jbjnr_>
lunch!
<heller_>
Yorlik: more or less, yes
<Yorlik>
I didn't find anything yet how to publish running processes and have them communicate. IIRC there is an AGAS master service running somewhere, right?
hkaiser has joined #ste||ar
<Yorlik>
I guess it's all in the ini settings - hpx.parcel. ... ?
<Yorlik>
Allright - here we go: hpx.agas ...
<Yorlik>
After all it's all in the docs - just need to search better ...
<jbjnr_>
the docs are a bit thin in places. I was shocked yesterday when I looked at the new sphynx docs and see the API reference is all somehow merged into one enormous page with no structre. Awful.
<Yorlik>
A doxygen doc would be nice, indeed.
<zao>
Doxygen for template-heavy C++? Heh.
<Yorlik>
I like sphinx a lot for handwritten manual documentation and I use it to document my stuff alongside programming it, so I always keep a birds eyes perspective, but for code documentation I'd rather have a doxygen setupo.
<Yorlik>
I never tried Doxy for templated C++ - you get symbol explosion or what ?
<Yorlik>
Actually I never used templates - never been that deep in C++
<zao>
Most of my experience is from the old days where C++03 almost was supported.
<zao>
Not sure how well they've coped with the language getting harder to parse.
<Yorlik>
The last 4 years, when I was doing Lua scripting against an engine API (which was documented so-so) and a default script base which was entirely undocumented I learned to love Sublimetext and its directory search ... The scriptbase documented itself .. sortof ...
<Yorlik>
For HPX i just have to get "in tune" and find my search terms ;)
nikunj has joined #ste||ar
<jbjnr_>
hkaiser: if I put a try {} catch {} block around myfuture = hpx::async(stuff) and the stack allocation fails when creating the task. The exception is thrown in some far away code and I can't seem to catch it. Am I doing it wrong?
<jbjnr_>
(I expected the future to be filled with the exception - but I guess when task allocation fails, it is so deep inside the runtime that it doesn't propagate back)
<hkaiser>
sounds like a bug to me
<hkaiser>
can you construct a test case for me to look at?
<Yorlik>
Just wasted 2 hours with weird include path errors only to learn that I had to delete my .vs folder for everything to refresh properly .....
* Yorlik
distastes hidden caches
<Yorlik>
Rescan Solution in VS didn't fix it ...
<Yorlik>
Everything compiled nicely, but all my includes were wiggled and marked as "not found"
hkaiser has quit [Quit: bye]
<heller_>
jbjnr: the stack creation might happen when calling wait_or_add_new, at this point, we have no knowledge about futures
<heller_>
And the entire runtime is failing
eschnett has joined #ste||ar
hkaiser has joined #ste||ar
<jbjnr_>
hkaiser: yes that's correct.
<jbjnr_>
I am running tests and when I create too many tasks the stack allocation fails and I can't catch the errors, so I can't make my scripts output sensible values for those options
aserio has joined #ste||ar
<heller_>
jbjnr: stack allocation failing is not good. Under which scenario do they fail?
<jbjnr_>
the future_overhead test can be used. Just generate millions of tasks using --futures=1000000 and then it happens.
<diehlpk_work>
simbergm, Ok, let me know what to do
<hkaiser>
jbjnr_: even with the lazy initialization of threads?
<diehlpk_work>
simbergm, I was thinking to hardcode the paths for the 1.2.1 release and we will look for the 1.3 release how to solve it properly
<jbjnr_>
the lazy init branch doesn't help much until we fix the reuse of threads. That's what I was working on a week or so ago, but I made the code slower insted of faster.
<hkaiser>
but we reuse threads, don't we?
<jbjnr_>
yes, but the lazy init branch broke something and I messed everythig up when I redesigned it all
<jbjnr_>
I will have a look at it again soon. Gradually, my understanding of our problems is getting better
<hkaiser>
so the OOM exception is caused by your messup? ;-)
<jbjnr_>
I never looked deeply at this thread creation code before,
<jbjnr_>
no the OOm is master branch
<hkaiser>
ok, that's bad
<hkaiser>
heller_: ?
<hkaiser>
I thought we have the lazy init on master already
<jbjnr_>
no
<jbjnr_>
leave it to me though as I'm already working on this
<hkaiser>
k
<jbjnr_>
I have two more PRs to do first though
<hkaiser>
not sure if it's worth catching OOM on stack allocation
<hkaiser>
if this happens all bets are off anyways
<jbjnr_>
correct. but the lazt stack stuff should make it much less probable
<jbjnr_>
(once we fix it)
<hkaiser>
indeed
<heller_>
OOM on stack allocation should only happen if you have tons of threads that have been suspended. This scenario should be very likely and shows that you have a problem in any case
<jbjnr_>
heller_: is correct though that if we disabled stealing suspended tasks, then we would not need to worry about stacks migrating across cores/dmoains etc.
<heller_>
not stealing pending tasks is an orthogonal issue though
<jbjnr_>
the master branch has OOM constantly if you use the --futures=lots option
<heller_>
but makes stack management *a lot* easier
<jbjnr_>
it has always been that way
<heller_>
*nod*
<heller_>
makes perfect sense
<jbjnr_>
I think I know what's wrong with the code, but I wanted to fix some of the oter stuff with my scheduler first before I retry it
<simbergm>
are tasks being created directly on master? they shouldn't with apply
<simbergm>
diehlpk_work: so we could declare it not our problem anymore
<Yorlik>
Are these two variations of using macros (One versus two macros) to turn a free function into an action just a matter of taste/notation preferences or do they have any other effects?
<heller_>
yes, depends on how you start them ... completely arbitrary, more or less
<simbergm>
what's happening is that cmake doesn't look in lib64 for HPXConfig.cmake unless you tell it to do that
<heller_>
Yorlik: declaration vs definition
<simbergm>
ok, plain apply without executor shouldn't
<hkaiser>
not arbitrary
<heller_>
hkaiser: looks arbitrary to me ;)
<hkaiser>
one macro introduces the action declaration, the other introduces its defintion
<hkaiser>
what's arbitrary about this?
<diehlpk_work>
simbergm, I would just add the three potential path to /usr/lib and we should be set for fedora
<Yorlik>
There are two variations described in the docs: using either HPX_PLAIN_ACTION in global namespace or using HPX_DEFINE_PLAIN_ACTION AND HPX_REGISTER_ACTION. I guess the first case is just a convenience that contains both?
<heller_>
hkaiser: not the action declaration/definition, the thread creation stuff
<simbergm>
diehlpk_work: there's not much you can hardcode
<heller_>
Yorlik: correct
<simbergm>
but we could install our cmake files into lib or share and cmake would look there by default
<Yorlik>
Thanks!
<simbergm>
one can set FIND_LIBRARY_USE_LIB64_PATHS to ON and cmake will suddenly decide to look there
<simbergm>
that's in a project using hpx
<simbergm>
do you happen to know where other projects install their cmake files?
<diehlpk_work>
simbergm, in the same directories, because these are predefined fedora macros
<diehlpk_work>
ls
<jbjnr_>
simbergm: I don't understand your question. Are you still hoping for an answer?
<simbergm>
jbjnr_: I'm not sure
<simbergm>
I just dislike
<simbergm>
cmake
<jbjnr_>
sorry. I guess you were not talking to me
<simbergm>
jbjnr_: you might know better
<simbergm>
we currently install our HPXConfig.cmake to whatever libdir is set to, which will be lib64 on some systems
<simbergm>
but cmake doesn't look there by default so find_package doesn't work without telling it to do so
<simbergm>
so I'm wondering if we should just move it to share where it will look, and where it will be independent of bitness
<simbergm>
I think that would actually make sense
<jbjnr_>
(I'm afriad I never install hpx and only ever use the build tree, so I doubt I can be helpful) - perhaos you should ask on the cmake list? (I can for you if you want)
<simbergm>
don't worry
<simbergm>
diehlpk_work: all the different variations of hpx with and without mpi are mutually exclusive, no?
<diehlpk_work>
Yes, only one variant is installed at once
<heller_>
simbergm: moving it share (without dependending on the bitness), makes it impossible to install 32 and 64 at the same time ;)
<simbergm>
heller_: sure, but who would do that?
<heller_>
users...
<simbergm>
but I'm fine with that as well, then we'll just have to tell users to look in lib64 as well
<heller_>
I don't care
<heller_>
sounds like a fedora bug though
<simbergm>
cmake bug I would say
<heller_>
if every XXXConfig.cmake is there, their cmake should look there
<simbergm>
then it would find ours as well, don't think that's the case
<simbergm>
annoying nevertheless
<simbergm>
diehlpk_work: do you have any other cmake packages installed? can you look where their XConfig.cmake files are?
<heller_>
diehlpk: can you change 'set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "/usr/lib/cmake/HPX")' to set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_LIST_DIR})'?
<heller_>
and see if that fixes your problem?
<heller_>
I'd assume that '/usr/lib/' will show up in a lot of places...
<diehlpk>
Yes, it is in many places
<heller_>
diehlpk: where do you have the cmake command line from?
<Yorlik>
I defined a class inside the "lua" namespace with: class luathread : hpx::components::component_base<luathread> and tried to register it with "HPX_REGISTER_COMPONENT ( lua::luathread, lua_luathread_component );". Now I get a compile error of: "'heap_type': is not a member of 'lua::luathread'. Are there some interfaces I need to implement or what did I miss here?"
<simbergm>
hrm, maybe github serves old zip files
<heller_>
checked the content of mine...
<diehlpk>
Ok, I started a new build. Yesterday, I just downloaded the zip file once simbergm told me to give it a try
<Yorlik>
Woops - wrong parameter - I withdraw my question.
<Yorlik>
the cpp only has some method implementations
<hkaiser>
do you have the register module macro?
<Yorlik>
Argh ....
* Yorlik
bangs head on table ...
<Yorlik>
lol
<Yorlik>
FFS - you need a PhD justr to build this ;)
* Yorlik
chuckles
<hkaiser>
nah, just some reading required
<Yorlik>
I think I just need more patience
<hkaiser>
and we need better docs
<Yorlik>
pushing everyday - after some time this will be behind me
<Yorlik>
The docs ore okay - just a wee bit unpolished.
<Yorlik>
The API docs could be nicer though
<hkaiser>
right
<hkaiser>
any help would be appreciated ;-)
<Yorlik>
I have started to write down some stuff for myself in rst
<Yorlik>
If I evener produce something usable you'll get it
<hkaiser>
thanks a lot!
<Yorlik>
I think it would help to have a sort of systematic curriculum of what you need to learn to build and program for HPX
<Yorlik>
And then just fill in that skeleton over time.
<Yorlik>
Actually I'd be willing to help out to some extent since HPX solves a ton of our problems
<hkaiser>
that'd be much appreciated
<hkaiser>
we're way too close to the metal here...
<Yorlik>
It would help if someone of the experienced guys could help me write down a rough curriculum, so i could learn along and fill in bits from the docs or my own stuff and give it to you later for proofreading
<Yorlik>
Just a todo list like learn a then learn b then learn c ....
<Yorlik>
I just find my way by hitting a wall, turning a little, hitting the next wall, rinse repeat
<Yorlik>
And ofc -i also have obstacles due to inexperience with C++, VS and a ton of other stuff.
<Yorlik>
I have no problems understanding the highlevel concepts though
<Yorlik>
Its all about the dirty gritty details ;)
<hkaiser>
Yorlik: see - that list of a, b, and c is very difficult for us to create
<hkaiser>
kinda taking this for granted...
<Yorlik>
That's why I suggested to work with one of you to set up such a list - my inexperience is an advantage here, because i do the stupid things and ask the obvious questions
<hkaiser>
right
<Yorlik>
We could do that in a not too long voice chat and get such a list done as a newbie's biew on things
<hkaiser>
cool, I'd be happy to work with you
<Yorlik>
Do you have Discord or teamspeak?
<Yorlik>
I think such a project works better in voice than typing
<Yorlik>
Discord allows screen sharing which also help
<hkaiser>
does skype work for you? any other of those can be organized as well (webex anyone)
<hkaiser>
appear.in has worked well as well
<Yorlik>
Skype is totally broken on my pc, but I could try again. I've not been using it for years
<Yorlik>
In our team we use Discord and slack
<hkaiser>
nod
<Yorlik>
Signing up with appear.in nopw
<hkaiser>
Yorlik : we have a standing link there: appear-in/stellar-group
<hkaiser>
let's find some time next week to talk about this
<Yorlik>
Allright
<Yorlik>
I'm around
<hkaiser>
k
<hkaiser>
thanks
<Yorlik>
Seems I managed to intrude your room - I think I'm set for next week.
<diehlpk_work>
hkaiser, We should apply for Google Fall of Documentation
<hkaiser>
right
<Yorlik>
hkaiser: HPX_REGISTER_COMPONENT_MODULE ( ); was missing and now it compiled
<Yorlik>
Thanks a ton !
<hkaiser>
k
<K-ballo>
simbergm: that clang-11 builder of yours, it's failing on mastre too, right?
<hkaiser>
K-ballo: it's clang v3.x
<K-ballo>
ok...
<K-ballo>
I'm seeing failures related to spinlock_pool which should be preexistent
<K-ballo>
(if I am even the cdash results right, I havr trouble figuring out to which sources a build corresponds)
<K-ballo>
nevermind, it links to a build from 8 hours ago, so it can't be current source
<parsa_>
Skype has a completely standalone Web interface that also supports webcams and microphones. https://web.skype.com/
parsa_ is now known as parsa
<simbergm>
K-ballo there's been a runtime failure with clang 3, but it used to compile at least, but I might not have kept up with master properly
<K-ballo>
oh, they are randomly sorted
<simbergm>
(And pycicle does have quite a delay so you might've fixed it already)
<K-ballo>
could you link me to the latest build for that branch on that compiler?
<K-ballo>
I don't know how to read the dash
<K-ballo>
I suspect by now I fixed it twice.. Ikeep looking at old results
<diehlpk_work>
With the latest release it seems that there are no files /usr/lib64/mpich
aserio has joined #ste||ar
<K-ballo>
I'm going to take it back to the original "fix" and then wait for someone else to figure the ci reports
<diehlpk_work>
simbergm, Now it is always installed to /usr/lib64
<diehlpk_work>
And somehow my /usr/lib64/mpich and /usr/lib64/openmpi are ignored
jbjnr has quit [Ping timeout: 264 seconds]
<Yorlik>
I registered a free function as action with: HPX_PLAIN_ACTION ( lua::luastuff, luastuff_a ) in the global namespace, but luastuff_a remains an "unknown identifier" when I try to invoke it with "hpx::apply ( luastuff_a , hpx::find_here ( ) );". What am I missing here?
<Yorlik>
The function was defined in a components sourcefile - maybe that's why?
<K-ballo>
IIRC `luastuff_a` would be a type, not an object.. but that would not expect the error message
<K-ballo>
s/expect/explain
<Yorlik>
I think I made a mistake in the code structure. Probably the function should not be in the dlls source file
<Yorlik>
Does it have to be in the executables global space?
<Yorlik>
I think I'm doing something stupid here. Where would I put a function I want to be a part of a namespace which has a component and this function?
<K-ballo>
what would be the options?
<Yorlik>
I have no idea. What I did was declaring the function in the header of the dll which has the component and the free function.
<Yorlik>
And that header is in the executable ofc
<Yorlik>
The macro for the free function though is in the cpp file and not the headxer
bibek has quit [Quit: Konversation terminated!]
<Yorlik>
Allright - I moved the macro to the header and invoked with: "hpx::apply ( luastuff_a() , hpx::find_here ( ) );" Now it compiles but I get linker errors.
<Yorlik>
I think I need to study some examples.
<hkaiser>
Yorlik: no limitations on using namespaces
aserio has quit [Ping timeout: 250 seconds]
<hkaiser>
the macros have to be in global scope, however
<Yorlik>
The macro was in the Cpp of the library, not in the header
<hkaiser>
which macro?
<Yorlik>
the executrable using the library didn't know the action identifier then
<hkaiser>
the action declaration or the definition?
<Yorlik>
HPX_PLAIN_ACTION
<Yorlik>
One single macro for a free function
<hkaiser>
that is the definition, should be visible to one TU
<Yorlik>
I put only this below the function declaration in the header: HPX_PLAIN_ACTION ( lua::luastuff, luastuff_a )
<hkaiser>
if you need to declare it , add HPX_PLAIN_ACTION_DECLARATION to the header
<Yorlik>
IC
<hkaiser>
if you put the definition in the header you might end up with multiple defined symbols
<Yorlik>
So the MAcro stays in the cpp and the additional declaration goes to the header
<hkaiser>
yes, as usual
<hkaiser>
declarations -> header, definitions src
aserio has joined #ste||ar
<hkaiser>
K-ballo: would it be ok for me to change your executor PR?
<Yorlik>
lol - nothing is usual for me in the moment - I'm a toddler bumping into every obstacle he can find
<hkaiser>
I would like to add direct support for sync/then/deferred to it
<hkaiser>
Yorlik: yah, in our experience the biggest problems people have with HPX are c++ related
<K-ballo>
hkaiser: sure, I'm done with it
<Yorlik>
Yup. Don't forget - I did 4 years of Lua and really very little c and c#
<hkaiser>
Yorlik: sure, np
<Yorlik>
It's a rough start, but I'm confident i will cope over time.
<simbergm>
diehlpk_work: LIB still needs to go, that was our creation
<K-ballo>
simbergm: no, I pushed various fix attempts after seeing your link, because I kept seeing the same output (literally)
<simbergm>
K-ballo: yeah, it's not really made for interactive debugging ;)
<simbergm>
there's up to 12 hours of delay
bibek has joined #ste||ar
bibek has quit [Quit: Konversation terminated!]
bibek has joined #ste||ar
<Yorlik>
I can't get my head around using the action I created. So - IIUC I need to create an instance of the action - which is a struct. But trying something like: auto ls = new luastuff_a; gives me an "incomplete type is not allowed" error.
<heller_>
forget about new for a few weeks ;)
<heller_>
you won't need it
<Yorlik>
I just want to fire s tupid function lol
<Yorlik>
How do I use my type "luastuff_a" ?
<heller_>
so, luastuff_a is your action type?
<Yorlik>
Yes
<heller_>
give me a second
<Yorlik>
I tried hpx::aply, but no way
<diehlpk_work>
simbergm, Ok, I run with out -DLIB
<diehlpk_work>
Yes, simbergm they should go there
<heller_>
Yorlik: do you want to wait on it's completion?
<diehlpk_work>
Ok, but how do I get to install in /usr/lib64/openmpi?
<heller_>
you can do two things: `hpx::apply<luastuff_a>(hpx::find_here());` or `hpx::apply(luastuff_a(), hpx::find_here());`
<heller_>
both do the same thing
<simbergm>
but also, if LIB_INSTALL_DIR and friends is set by fedora to /usr/lib64, why can't the mpi packages go in the same locations? they definitely won't be found by cmake...
<heller_>
the first is just passing along the type as some kind of a tag, the second, creates an object of the type
<simbergm>
you'll have to set a combination of CMAKE_INSTALL_PREFIX and LIBDIR/INCLUDEDIR
<heller_>
which can be deduced by some C++ machinery, and then be used as the tag again
<simbergm>
which ends up as ${CMAKE_INSTALL_PREFIX}/${LIBDIR} for libraries and the same for includes etc
<Yorlik>
The second variant gives an incomplete type wiggle
<heller_>
and the first one?
<Yorlik>
It looks nice in the editor, but the compile breaks with use of undefined type 'luastuff_a'
<Yorlik>
In the header of the dll I have this: HPX_DECLARE_PLAIN_ACTION ( lua::luastuff, luastuff_a );
<Yorlik>
And that header is included in the header for the executable which refuses to compile
<Yorlik>
So afaik the typ ~should be known to the executable
<Yorlik>
The exact error comes from here: C:\INSTALL\Release\include\hpx\traits\extract_action.hpp(20): error C2027: use of undefined type 'luastuff_a'
<diehlpk_work>
Ok, simbergm I will play around
<K-ballo>
undefined type means declared but not defined
<K-ballo>
Yorlik: you have your action declaration, do you have an action definition too? is it visible at the point you try to use it?
<hkaiser>
Yorlik: there are two versions of apply/async
<Yorlik>
In the cpp the action is defined in the namespace and registered in global namespace
<Yorlik>
The example has the define iside and the register outside the ns
<simbergm>
diehlpk_work: do you only need libs to installed in the openmpi/mpich directories or is the root of the installation /usr/lib{64}/{openmpi,mpich}?
<diehlpk_work>
Second one
<diehlpk_work>
gcc should go /usr/lib64 and mpi to /usr/lib64/mpich and so on
<simbergm>
and includes?
<diehlpk_work>
always to user include
<simbergm>
diehlpk_work: in that case you just need to set LIBDIR
<diehlpk_work>
Ok, I will give it a try
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
<Yorlik>
The pair of "HPX_PLAIN_ACTION ( lua::luastuff, luastuff_a );" in the cpp and "HPX_DECLARE_PLAIN_ACTION( lua::luastuff, luastuff_a );" in the header for declaration should be correct, right ?
<Yorlik>
Where lua:luastuff is a void free function
<hkaiser>
yes
<zao>
Can you define an action for something namespaced outside of its namespace, or do you need to break it open?
<hkaiser>
those names have changed several times
<hkaiser>
not sure even if the docs are still correct, I need to go back and check
<Yorlik>
Which names?
<hkaiser>
the macro names you listed above
<Yorlik>
Yes - I condensed the two together again
<Yorlik>
But the error stays constant - whatever variant I use
<Yorlik>
The first error I get is: "C:\INSTALL\Release\include\hpx\traits\extract_action.hpp(20): error C2027: use of undefined type 'luastuff_a'"
<Yorlik>
The cited line 20 is: "typedef typename hpx::traits::extract_action<Action>::type action_type_;"
<hkaiser>
Yorlik: give me your code, I don't know what you're doing
<Yorlik>
OK - I'll zip it
<Yorlik>
DCC sending zip
<hkaiser>
Yorlik: send the file to hartmut.kaiser@gmail.com
<Yorlik>
OK
<Yorlik>
Mail is out - tiutle: "Broken Code"
<Yorlik>
It was blocked
<Yorlik>
Stupid google
<hkaiser>
Yorlik: will look at things later tonight only, though
<Yorlik>
I think I should use the time and make a more slef contained example
hkaiser has quit [Quit: bye]
parsa is now known as parsa_
<K-ballo>
Yorlik: is your action *defined* by the time you try to use it? you did not answer me that
aserio has quit [Ping timeout: 250 seconds]
aserio1 has joined #ste||ar
<Yorlik>
The action is defined in the cpp of the library: HPX_PLAIN_ACTION ( lua::luastuff, luastuff_a );
<Yorlik>
K-ballo: And it is declared in the header:
<Yorlik>
No - I tried to build it here and it still broke
<K-ballo>
what's the offending line?
<Yorlik>
inside that fat comment in sim.cpp
<K-ballo>
I built it as-is
<K-ballo>
I did not look at code, let's see
<Yorlik>
It should not - I think I sent it with the line uncommented
<heller_>
phew, finally got everything built with cuda support
<K-ballo>
if I break the source it still builds successfully, it's not actually touching the source
<Yorlik>
What do you mean with break the sopurce? You mean everything not commented out?
<Yorlik>
I wonder if something is wrong with my hpx build
<heller_>
hkaiser: i think we eventually need a decent customization point for the parallel algorithms to be specialized for different iterators, executors and policies
<K-ballo>
there's something wrong with your cmake, it's not actually building anything here on my build
<Yorlik>
My cmake is part of a superbuild
<Yorlik>
That might have consequences
<K-ballo>
by looking at the code I can see the reason for the error, but I do not know whether it is expected behavior or not
<Yorlik>
What does your configure print?
<Yorlik>
What do you suppose is the error?
<K-ballo>
the error is exactly what the error says, the action is being used at a point where the action is not defined
<Yorlik>
Does it not propagate through the header to the sim.cpp?
<K-ballo>
the header does not define it, only declare it
<K-ballo>
now whether hpx should be requiring a complete type at that point, I suspect not
<K-ballo>
the DECLARE macro should be spewing suficient stuff for the action to be used with an external definition
<Yorlik>
Should I make the component header only maybe for checking ?
<Yorlik>
Or at least move the define there
<Yorlik>
hkaiser suggested I just need this additional declare
<K-ballo>
maybe... I can't get the build to actually build, so I can't reproduce the error message :P
<K-ballo>
I have to go, will continue playing later
<Yorlik>
Thanks! I'll work on the cmake
aserio has joined #ste||ar
<hkaiser>
Yorlik: how do I configure your project, I tried using cmake and couldn't get it to generate anything useful
<Yorlik>
I am working on a better selcontained standalone example.
<Yorlik>
The cmake is part of my superbuild and expects certain locations - I will adapt it to work with vcpkg
<Yorlik>
I should have anticipated that - sorry for that
<Yorlik>
essentially it's just an executable (sim) and the dll with the component and the free function
<Yorlik>
This one shopuld compile with vcpkg enabled and having hpx built there
<Yorlik>
The error is still present
<Yorlik>
You could directly open it with "Open Folder" In VS if you have the Cmake extension
<Yorlik>
Then you woudl have to edit the json file, or you manaually call cmake and use "-DCMAKE_TOOLCHAIN_FILE=F:/vcpkg/scripts/buildsystems/vcpkg.cmake" (wherever that file is for you .)
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<hkaiser>
Yorlik: CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
<Yorlik>
Seems VS is doing that for me.
<Yorlik>
I should just drop VS for any demo purpose.
<heller_>
jbjnr_: the first problem is that the dtor of the Guard tries to delete an already moved from element. The second is the same, but directly after the move
<heller_>
in principle this should be fine (call the dtor should always be possible)
<heller_>
adding a `// NOLINT` to the should take care of that, as a workaround
<hkaiser>
Yorlik: don't worry about a build system, I can test your stuff without one
<hkaiser>
Yorlik: your component compiles for me without problems
<Yorlik>
Yes - the component worked all the time
<Yorlik>
Its the executable
<hkaiser>
ok
<Yorlik>
In the hpx main there is the offending line
<hkaiser>
need to run now - will try later
<Yorlik>
I dropped a big and fat comment woith ypur name on it
<Yorlik>
You can't miss it
<Yorlik>
Now the cmake gui is trolling me: The following configuration files were considered but not accepted:
<Yorlik>
I targeted VS with CMake and opened the püroject. Now I get: 3>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include\list(240): fatal error C1060: compiler is out of heap space
<Yorlik>
3>Done building project "sim.vcxproj" -- FAILED.
<Yorlik>
This is crazy
<parsa_>
Yorlik: your code is not compiling because neither your component class' nor your action's symbols are exported
<Yorlik>
What's missing then?
<parsa_>
HPX_COMPONENT_EXPORT
<Yorlik>
Oh damn
<Yorlik>
Too many Macros - lol
parsa_ is now known as parsa
<Yorlik>
parsa_: How would HPX_COMPONENT_EXPORT ve used with the free function?
<K-ballo>
I suspect that error might be a genuine hpx issue, there's no way `extract_action` works on a declared but not defined action
<K-ballo>
and it's not the only trait I recall that requires completeness, anything with a :: in it will
<heller_>
hmm, we have code like this all over the place
<heller_>
let me check...
<Yorlik>
putting HPX_COMPONENT_EXPORT in the class or in front of the function didn't change anything.
<Yorlik>
DLL compiles, exe not
<heller_>
ok, we don't have that all over place :P
<heller_>
yeah, it's a bug indeed
<Yorlik>
heller_: That broken compile of mine?
<heller_>
Yorlik: if you replace HPX_DECLARE_PLAIN_ACTION(...) with this: `struct luastuff_a : hpx::action::make_action<decltype(&lua::luastuff), &lua::luastuff, luastuff_a> {};` it should work
<heller_>
Yorlik: indeed
<Yorlik>
Nice. So I moight have just earned my first QA badge ;)
<K-ballo>
isn't that just what HPX_PLAIN_ACTION would expand to?
<Yorlik>
Not compiling
<Yorlik>
lua_engine_component.cpp(21): error C2039: 'action': is not a member of 'hpx'