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>
It's crazy how much time just getting the build system right absorbs
<Yorlik>
Anyone ever had issues with an error like this? : "The keyword signature for target_link_libraries has already been used with
<Yorlik>
the target "luaengine". All uses of target_link_libraries with a target
<Yorlik>
must be either all-keyword or all-plain."
<Yorlik>
I am using target link libraries alingside hpx_setup_target, but it seems not to wok anymore
<Yorlik>
This: target_link_libraries(sim PRIVATE ${Boost_LIBRARIES} luaengine ) is now causing issues
eschnett has quit [Quit: eschnett]
<jbjnr__>
Yorlik: it means that somewhere else target_link_libraries(sim stuff) was used without the PRIVATE or PUBLIC keywords and you can't mix them.
<jbjnr__>
one is old syntax, one is new (PRIVATE)
<jbjnr__>
heller_: how would you feel about the libfabric parcelport being able to bootstrap and us not needing boost:asio for it any more?
<heller_>
jbjnr__: that would be very nice!
<jbjnr__>
fningers crossed that in about an hour I should have the definitive test of it being feasible
<heller_>
nice!
<heller_>
what about the serialization error?
<jbjnr__>
not fixed. I started looking at it, but it is hard to reproduce reliably (race somewhere it seems) and I decided to start debugging it via the sockets version on my laptop, but I also wanted to get the bootstrap running too to make life easier to debug as well.
<heller_>
ok
<jbjnr__>
it's very bad that I cannot remember most of how the parcelport works any more.
<jbjnr__>
I need to make documentation as I work on it
<Yorlik>
jbjnr__: Finally fixed it - don't ask me what it was - looked all a bit like black magic to me. Changing anything in my build always feels a bit like walking through a minefield. I want a CMake++ ;)
K-ballo has joined #ste||ar
nikunj97 has joined #ste||ar
nikunj has quit [Ping timeout: 240 seconds]
<Yorlik>
Is there a way to use templates to collect data over all instantiations of a given type, like how many instantiation were used or which types were instantiated? My guess is no - but who knows - there's magic in the templates.
<Yorlik>
:)
<Yorlik>
Background is, I am creating a collection of vectors holding one type of template instantiation each. The instances are accessed through an Interface to an abstract class for storing them or creating them right in the correct Vector in the Vector collection. Knowing ahead of time which instantiations are actually use could help me pre-create them and not test everytime on a creation attempt.
nikunj1997 has joined #ste||ar
nikunj97 has quit [Ping timeout: 246 seconds]
nikunj97 has joined #ste||ar
nikunj1997 has quit [Ping timeout: 246 seconds]
<K-ballo>
there are many tools that will give you that kind of information
<K-ballo>
IIRC you are on msvc, you could just try /d1reportTime, will give you all template instantiations
<K-ballo>
since you seem to have some kind of runtime interface, sounds like printing that information at runtime would be much simpler
nikunj has joined #ste||ar
nikunj97 has quit [Ping timeout: 245 seconds]
<Yorlik>
What I want to try (not sure if it is possible) is, to fill the collection with vectors for each type at compile time in a generic way.
<Yorlik>
So - if I change my code, to have an additional instance type, i want the templates to automagically create the vector needed to store it inside the collection of vectors
<Yorlik>
My instances are composed from components like: E<c1, c2,c3 ...>
<K-ballo>
sounds like you want template variables
<Yorlik>
where c1...cn get added by simple public inheritance inside the E template
<K-ballo>
sounds like you don't want template variables
<Yorlik>
Argh ... what do i want then ? lol
<K-ballo>
it is not clear
<Yorlik>
The vectors are holding the E types by value - densly packed
<Yorlik>
All the C types are simpüle Pods
<Yorlik>
This allows me to have all the E types densly packed in their respective vectors
<Yorlik>
The vectors are bundled in a collection
<Yorlik>
So - I have as many Vectors as i have E type instantiations
hkaiser has joined #ste||ar
<Yorlik>
The master !
<Yorlik>
So - the question is, if i can create vectors for each E specialization automagically at compile time
<Yorlik>
Otherwise every time a new specialization out of the c type composition needs to be added manually to the vector collction
<Yorlik>
woops - it ate a word
<Yorlik>
meant. if a new specialization is created ...
<Yorlik>
I doubt its possible, since the compiler would somehow have to collect the specializations across the codebase
<hkaiser>
sure, just make it a static public member of E
<hkaiser>
Yorlik: inside the clas 'E" is sufficient
<Yorlik>
Smeet
nikunj has quit [Ping timeout: 268 seconds]
<Yorlik>
s/m/w/g
<K-ballo>
sounds like you could have wanted a template variable after all, but you don't need it if you have where to define your vectors already
<Yorlik>
The initial idea was to use a separate collection of vectors, but having them as static members is better for various reasons - e.g. I have a faster resolution of the storage space
<Yorlik>
No map or vector to search for the right container
<K-ballo>
what I had in mind was `template <class E> std::vector<E> the_vectors;`, then `the_vectors<E>` gives you the one you want.. the underlying machinery is alike that of the static member you have
<Yorlik>
It couldn't be a vector<E> the_vectors: the E's are all different. It would have been a map<BitMaskTypeHint, IContainers> where the IContainers would have been Container<vector<E<class...Ts> >> with an IContainers parent.
<K-ballo>
it's not a vector<E> the_vectors, it is a template <class E> the_vectors.. you get a different vector per E
<Yorlik>
But the vectors inside the collection are heterogenous
<Yorlik>
I don't understand , I think.
<K-ballo>
you already have a logical place in which to define each vector instance
<Yorlik>
With the new layout to have them be static class members
<K-ballo>
what you already have with the static vectors is better, but if you did not have a logical place in which to define those, a variable template automatically gives you an instance per type of those types you use
<Yorlik>
Oh I see
<Yorlik>
What you did was similar to what hkaiser said, just you put it in another place
<Yorlik>
Sorry for being so clumsy - this generic stuff is all new to me and often totally over my head
<Yorlik>
I think I need some time to really develop the mindset for it
<hkaiser>
K-ballo: neat! wasn't aware of this trick
<K-ballo>
same underlying principle
<hkaiser>
K-ballo: this could be used to get rid of some of the action macros...
<Yorlik>
Now there's an interesting Caveat:
<Yorlik>
auto testent = pecs::Entity<pecs::base_c, pecs::physics_c, pecs::container_c>::items.emplace_back() ;
<K-ballo>
C++14 only
<Yorlik>
This doesnt compile
<Yorlik>
With the error:
<Yorlik>
error C2228: left of '.emplace_back' must have class/struct/union
<Yorlik>
So - the class is not yet instantiated at that point
<hkaiser>
K-ballo: I know :/
<K-ballo>
if we could use variable templates though, we should be able to do the same with 11 variations
<hkaiser>
one day...
<Yorlik>
They should just embed pytrhon inside C++ for templates ... ;)
<hkaiser>
Yorlik: you might not be able to do this inside the class before it is defined
<hkaiser>
might have to define the function out of class scope
<Yorlik>
You mean the items member?
<Yorlik>
as a template?
<hkaiser>
no, the member function accessing it
eschnett has joined #ste||ar
<Yorlik>
Oh - I used emplacxe_back directly
aserio has joined #ste||ar
<Yorlik>
With this definition inside the class it works: inline static std::vector < Entity > items = std::vector < Entity > ();
<mdiers_>
i have a performance problem with hpx applications started with slurm compared to started with mpirun. a problem is that hyperthreading is handled differently. usually it is mapped to the physical cores, but per slurm it is mapped to the logical cores (i have debugged down to slurm_environment::retrieve_number_of_threads. ). Enforcing by --cpus-per-task= set the hpx:cores to fit, but this didn't change the performance much.
<mdiers_>
hpx is configured with HPX_WITH_TCP_PARCELPORT OFF and HPX_WITH_MPI_PARCELPORT ON
<hkaiser>
mdiers_: sounds like a bug to me
<Yorlik>
I am getting the following error:
<Yorlik>
error C2663: 'hpx::lcos::future<unsigned char>::get': 2 overloads have no legal conversion for 'this' pointer in this code (expanded from macro): https://imgur.com/a/ihmGxlC . Basically I am using a Lambda to wrap cout and put a mutex around it - is there a problem with putting futures into a lambda? In all other cases the construction works as expected and wraps cout (out is just a : guard<std::ostream&> out {
<Yorlik>
std::cout };)
<hkaiser>
you shouldn't call std::cout from an HPX thread, that will block all of the progress on this core
<hkaiser>
but to answer your question, there is no reason why a lambda shouldn't work
<hkaiser>
use hpx::threads:run_as_os_thread([](){}) to wrap calls to cout and similar
<hkaiser>
gtg
hkaiser has quit [Quit: bye]
<mdiers_>
hkaiser: ok, with srun is hpx.parcel.mpi.enable=0 , and with mpirun hpx.parcel.mpi.enable=1 ($[hpx.parcel.enable]). is this a problem? i also don't want to exclude that our slurm configuration is correct. at least i'm checking the environment variables SLURM_ which are set to validate it.
<K-ballo>
gah.. screenshots of source code, shame on you Yorlik
<K-ballo>
is your future const?
<Yorlik>
The screenie shows the Macro expancion nicely
<K-ballo>
what's your native language?
<Yorlik>
basic
<Yorlik>
;)
<Yorlik>
German
<K-ballo>
so yeah, your future is const, it is a value capture of a non-mutable lambda
<K-ballo>
wait... how can you even capture the future in the first place?
<K-ballo>
the capture must be capturing `this` rather than the actual future
<Yorlik>
It's inside a free function
<Yorlik>
How would there be a this?
<K-ballo>
you would not have been able to capture a future<T> via [=], there would have been other errors before the one you pasted
<K-ballo>
[sidenote: names starting with underscore followed by capital are reserved to the implementation, your _Equal call will break]
<Yorlik>
So many oopsies .. oh man
<zao>
Oh right, I need to file bugs on the atomic stuff, still broken in trunk
bibek has joined #ste||ar
<K-ballo>
zao: could you try removing all the volatiles? graspin at straws here...
<zao>
I guess I can try after work
<heller_>
mdiers_: single or multi locality?
<mdiers_>
heller_: multi locality
aserio has quit [Ping timeout: 252 seconds]
<heller_>
mdiers_: which one is faster?
<mdiers_>
heller_: started with mpirun
<heller_>
mdiers_: also, srun does not automatically imply an mpi application
<heller_>
If you disabled the tcp parcelport, you might get N localities with srun
<heller_>
You can configure slurm to start an mpi application though
akheir has quit [Quit: Konversation terminated!]
akheir has joined #ste||ar
nikunj97 has quit [Read error: Connection reset by peer]
<mdiers_>
heller_: what configuration would you recommend for hpx via slurm? at the moment i can adjust everything. ;-)
nikunj has joined #ste||ar
<heller_>
mdiers_: why not stick with mpirun for now?
aserio has joined #ste||ar
<diehlpk_work>
david_pfander, see pm
<mdiers_>
heller_: for our production environment we need a job scheduling system, and it is great to schedule over night tasks
<heller_>
You can use mpirun inside a sbatch script
<heller_>
You could also check how the performance is looking with the tcp parcelport enabled
<heller_>
Or the libfabric one
<heller_>
Or configure slurm to start your mpi application
<mdiers_>
heller_: The first point is too easy to figure out. I will test it tomorrow in order. thank you.
<zao>
On my site, srun is properly competent at running MPI applications with all the possible MPI backends. :)
<zao>
We used to have a messy recommendation to which applications to run with mpirun and which ones to run with srun, but eventually got it homogenized.
aserio has quit [Ping timeout: 244 seconds]
aserio has joined #ste||ar
hkaiser has joined #ste||ar
<diehlpk_work>
jbjnr__, see pm
aserio has quit [Ping timeout: 252 seconds]
<Yorlik>
hkaiser: How would that wraping of function calls work? I naively tried "hpx::threads::run_as_os_thread( printf, 1, 2, 3 );" but that doesn't work and I didn't find any usable examples
<K-ballo>
other than those being incorrect argument types, it should have worked
david_pfander has quit [Quit: david_pfander]
david_pfander has joined #ste||ar
<Yorlik>
Uh - thge format string :D
<Yorlik>
And it compiles ...
<Yorlik>
Thanks K-ballo
<zao>
:D
david_pfander has quit [Ping timeout: 244 seconds]
<Yorlik>
I tried referencing operator() ut failed utterly.
<K-ballo>
what is "wrap"?
<Yorlik>
Such that operator() is running inside a thread with hpx::threads::run_as_os_thread
<K-ballo>
just pass out as the callable
<Yorlik>
I tried passing &out
<K-ballo>
why?
<K-ballo>
do you want to keep a reference to "out"?
<K-ballo>
std::ref(out) will do
<Yorlik>
That worked. Thanks for helping my babysteps!
<K-ballo>
run_as_os_thread(f, x, y, z) copies all the arguments to the new thread, then calls f(x, y, z) on the copies
bibek has quit [Quit: Konversation terminated!]
<K-ballo>
when you say run_as_os_thread(std::ref(f)) it only copies "a reference to f"
<Yorlik>
I was missing the std::ref part and tried just passing it as &out, &out::operator() and all kinds of funky stuff
<Yorlik>
Now I can use my new macro just like: S_OUT2( "Heyo! " << 2 << 3 << std::endl);
<K-ballo>
&out, &out::operator() would have worked if you had specified the template arguments
<Yorlik>
How would you have written that? I tried it, but failed
<K-ballo>
the name of the operator is not operator() but operator()<F>
<K-ballo>
for a concrete F
<Yorlik>
So like &operator()<(&)(std::ostream&){}> ?
<K-ballo>
that's not actually the type of the lambda, but otherwise yes
<Yorlik>
initial brackets are wrong too - should be square
<Yorlik>
lambdas are another beast to tame for me. I'm kinda familiar with functions as fiorst class citizens from my lua times, but the notation is quite different ofc
<Yorlik>
K-ballo: How would you write the lambda in the given case?
<Yorlik>
so - if I had chosen to pass &out or &out::operator()
<K-ballo>
I wouldn't
<Yorlik>
Would there never be any situation where you had to wroite such a lambda?
<K-ballo>
that's kinda why we have std::ref
<Yorlik>
In the given case std::ref is easiest, ofc, I'm just wondering about the notation
<K-ballo>
a lambda is an expression, it results in a closure, the type of the closure can only be obtained from asking the closure its type
<K-ballo>
each lambda expression has a different type, so if you have [](int){}; [](int){}; each of those has a distinct type
<K-ballo>
and if you say decltype([](int){}) you are getting the type of the lambda inside the decltype, a type that is not shared by any other lambda in the program
<Yorlik>
So we actually do have unicorns in C++?
<Yorlik>
I wonder - if that s the case - how at all you would be able to pass a type to the operator()<>, when the actual lambda would be the second argument.
<Yorlik>
I wrongly thought the prototype would define the type, like with functions
<K-ballo>
normally operator()'s F would be deduced, and that's why we use std::ref
<K-ballo>
else, you'd have to put your lambda somewhere, ask the type of that somewhere, then pass that along
<Yorlik>
makes sense - for example like: f = lambda ... ( operator()<decltype(f), f)
<Yorlik>
woops - you were fastewr :
<Yorlik>
Thanks a ton - that cleared it a lot
<K-ballo>
btw I just realized the order for member function was wrong all along, it would have been &out::operator()<F> first, then &out
nikunj has quit [Ping timeout: 240 seconds]
nikunj has joined #ste||ar
<diehlpk_work>
jbjnr__, yet?
<heller_>
Hmm, what happened with the documentation build?
<K-ballo>
boost 1.70-rc3 works fine with msvc
<K-ballo>
some hickups with their new cmake config packages
<Yorlik>
I'm amazed how often VS manages to freeze my keyboard input.
<Yorlik>
K-ballo: Now a real trick question: How to forward out.
<Yorlik>
I tried: template<typename C>struct guard; extern guard<std::ostream&> out;
<Yorlik>
But thats not enough - I also need to forward operator()
<K-ballo>
forward what? forward declare? extern it is
<Yorlik>
Yes - but how?
<Yorlik>
woops - extern .. forgot that in my other attempts
<K-ballo>
you can't forward declare a member of an incomplete type
<Yorlik>
Dang
<Yorlik>
I have two source files, both need the type and the member function
<Yorlik>
but i can't define in both or I get a double symbol error when linking
<Yorlik>
So I need a forward somehow
<Yorlik>
Seems I'm running into a sopurce code organization issue here.
<Yorlik>
So - do I have to solve this with a static library then?
<K-ballo>
you can always patch over your double symbol error
<Yorlik>
How does that work? What should I look / google for?
<K-ballo>
what's the actual error? your `guard` is a template so that must be fine, your op() is in-line, only `out` should be problematic
<Yorlik>
Yes - I need to forward out's operator()
<K-ballo>
no, why? you can have the entire class defined in the header
<Yorlik>
Then I run into the double symbol thingamabob
<K-ballo>
which symbol is the problematic one?
<Yorlik>
out is a template instance and such produces a symbol
<Yorlik>
Out is defined as this: guard< std::ostream& > out { std::cout };
<K-ballo>
so `out` is the problematic symbol, right?
<Yorlik>
Yes
<K-ballo>
not `op()`
<Yorlik>
I forward declared out and the guard template
<K-ballo>
why?
<Yorlik>
Because they are used in that source file
<Yorlik>
I have two source files which get lnked together
<K-ballo>
that does not answer the question
<K-ballo>
the problem you are running into is that you are defining `out` twice
<Yorlik>
the symbol gets used in both source files
<Yorlik>
exactly
<K-ballo>
the solution is: a) to define `out` once, b) to define `out` multiple times as a weak symbol so that the linker deduplicates
<Yorlik>
Thats why I am trying to forward declare it
<K-ballo>
none of that affects the definition of guard, nor of its op().. just `out`
<Yorlik>
Yes - its all about out
<K-ballo>
so why do you mess with guard?
<Yorlik>
because guard is in the type for out
<Yorlik>
I forward declared like this: template<typename C> struct guard; extern guard<std::ostream&> out;
<zao>
K-ballo: Removed all ` volatile` from that deque.hpp, got further.
<zao>
`/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/atomic:298: undefined reference to `__sync_val_compare_and_swap_16'`
<K-ballo>
the type of out is not the problem, only out itself is
<K-ballo>
zao: awesome.. more libatomic mess
<zao>
While linking lib/libhpxd.so.1.3.0
<Yorlik>
K-ballo: So just struct out; ?
<zao>
Note that this is my Ryzen, so no idea what it is supposed to support atomic-wise.
<K-ballo>
out is not a structure, it is a variable
<zao>
it has built hpx in the past tho
<K-ballo>
Yorlik: do you want to a) define `out` just once, or b) define `out` as a weak symbol
<Yorlik>
I'd prefer to dfine it just once
<Yorlik>
And to properly forward declare it in the other source
<Yorlik>
but extern out or extern struct out don't work
<Yorlik>
extern out; gives me a missing type error
<K-ballo>
extern guard<std::ostream&> out;
<K-ballo>
assuming the definition is guard<std::ostream&> out;
<Yorlik>
tried that. It gives me another error: error C2143: syntax error: missing ';' before '<'
<Yorlik>
I need to include the template I think
<K-ballo>
you need to leave guard untouched
<Yorlik>
the guard header is just the wrapper template
<K-ballo>
and the declaration of out, presumably?
<Yorlik>
Ok - it works now
<Yorlik>
I have included the guard template and forward declared as extern guard<std::ostream&> out;
<zao>
Aaw, godbolt's down :(
<Yorlik>
K-ballo: Again - thanks a lot helping with this. I guess I'll need a bit of time before I'm really up to speed. Feels all so clumsy right now - but I remember it was the same when I started learning Lua 5 years ago
<Yorlik>
C++ is just a wee bit tougher :o
<zao>
(rewrite it all in Rust!)
<Yorlik>
Never
<Yorlik>
Rust is sweet and I loved the compiler talks really - I produced bugs just to have it talk to me so nicely ...
<Yorlik>
But i like it the hard way, because it makes me a better programmer
<K-ballo>
...
<Yorlik>
Too much handholding dumbs you down, though it initially helps
<Yorlik>
Don't ask me what I experienced with my Navi ...
<K-ballo>
simbergm: where's this clang build? I'm starting to think it does not support C++14
<Yorlik>
K-Ballo: For some reason calling my lambda with run_as_os thread now creates an assertion inside run_as_os thread, which it didn't in my test compile. I am running it now inside hpx_main - couzld that be an issue? My initial test was running it from the normal main()
<Yorlik>
I wonder if the mutex causes an issue
<Yorlik>
Guard uses a mutes to protect the call to cout
<Yorlik>
mutex
<K-ballo>
are you sure you are running it inside hpx_main now and normal main before? not the other way around?
<Yorlik>
Yes
<Yorlik>
100%
<K-ballo>
sounds backwards...
<K-ballo>
are you using an hpx mutex in an os thread?
<zao>
K-ballo: Build of tests completed with the flag, btw.
<simbergm>
K-ballo: hold on, which clang build?
<Yorlik>
Its a std:mutex
<Yorlik>
I guess that might be the culprit
<K-ballo>
zao: can you show me the current command for whatever target was failling before?
<K-ballo>
simbergm: the one you says builds master fine
<K-ballo>
Yorlik: std::mutex is right, an os thread is not an hpx thread
<Yorlik>
All in all I need another cout sync method anyways - but its for learning
<K-ballo>
Yorlik: run_as_os_thread must be called form within an hpx thread, the assertion you get tells you you are calling it from an os thread instead
<zao>
I'll see if I can get at it, had to rebuild verbose.
<Yorlik>
I'll dopuble check
<Yorlik>
Actually it might be in my init code in anormal thread, indeed
<Yorlik>
And the test compile has hpx in main already
<Yorlik>
So i that makes snse actually
<simbergm>
K-ballo: all of but you're right to be suspicious about it
<zao>
Nothing "atomic" or "sync" found in libgcc_s.so.1
<Yorlik>
K-ballo: You were right. I now created two versions of the Macro - one you can call from inside HPX threads and one from outside and now they live in peace :)
<Yorlik>
Thanks a ton !
<K-ballo>
is libgcc.so still a thing?
<K-ballo>
Yorlik: yey!
<Yorlik>
A little macrto here and there is nice to have - though I could just have created another functor
<zao>
Only find libgcc.a, nothing of interest there.
aserio has quit [Ping timeout: 252 seconds]
<K-ballo>
this one is extra odd...
<K-ballo>
could it be a clang/libstdc++ mismatch?
<zao>
They're both from the distro, but it's quite possible that they're never meant to be together.
eschnett has quit [Quit: eschnett]
nikunj has quit [Ping timeout: 268 seconds]
<zao>
K-ballo: This Clang version is not a hard requirement at all for me. I see our CI uses 7.0.1
<zao>
Oh fudge me... this is Debian 9.2 :D
<zao>
(same Clang and libstdc++ as Debian 9.8)
nikunj has joined #ste||ar
<zao>
I'm perfectly fine with using some other toolchain, just curious.
hkaiser has joined #ste||ar
<hkaiser>
bita: yt?
<hkaiser>
bita: what does np.var(np.array([[[1.,2.,3.]],[[-4.,5.,6.]]]), axis=(1,2)) actually calculate?
jpenuchot has joined #ste||ar
eschnett has joined #ste||ar
eschnett has quit [Quit: eschnett]
<heller_>
simbergm: hmpf. We need the season of docs ;)