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/
<K-ballo> seems the overload set for `make_ready_future` broke again
<heller_> yeah
<heller_> reference types, as it seems
<hkaiser> when did it break?
<heller_> on K-ballo's branch
<K-ballo> I'm surprised it has worked without deduction guards
<heller_> woah, I finally got a working cuda build!
<heller_> almost...
<zao> Sounds good enough, ship it.
<heller_> :P
<heller_> nvcc errors are the best
<heller_> /home/heller/programming/hpx/hpx/util/deferred_call.hpp(84): error: cannot use an entity undefined in device code
<heller_> and that's it
<heller_> just because something instantiated that template which isn't marked with __device__
<heller_> this compilation model is just broken
<Yorlik> parsa: Testcase compiled and runs after your changes. Thanks a ton !
<Yorlik> Now studying it to undrstand why it works and what was broken before.
akheir_ has quit [Quit: Leaving]
jaafar has quit [Ping timeout: 272 seconds]
K-ballo has quit [Ping timeout: 244 seconds]
K-ballo has joined #ste||ar
hkaiser has quit [Quit: bye]
parsa is now known as parsa_
parsa_ is now known as parsa
jaafar has joined #ste||ar
parsa is now known as parsa_
parsa_ is now known as parsa
parsa is now known as parsa_
jaafar has quit [Ping timeout: 250 seconds]
<simbergm> heller_: did you manage to do something about this one: https://github.com/STEllAR-GROUP/hpx/issues/3545#issuecomment-439294546?
<simbergm> diehlpk_work: a couple of things for the fedora package once you get to work
<simbergm> you don't need to set LIB anymore (it's gone)
<simbergm> it's rightfully not setting the rpath now, whereas before it set it
<simbergm> and those .in files shouldn't be there in the first place, will remove them
david_pfander has joined #ste||ar
<heller_> simbergm: not yet
<heller_> simbergm: in the process of getting everything to compile...
<heller_> simbergm: I think that ticket can be closed though, I had (more or less) the same command line for cmake
<simbergm> well, I'd keep it open for the second error although the original error wasn't our fault
<heller_> yeah, the second error is what I'm fixing...
<simbergm> also see 3692, that was my lazy attempt at fixing some of the undefined in device code errors
<simbergm> but if your branch fixes the same let's go for that instead
<heller_> ok
<heller_> well, i think we need both
<simbergm> probably
<heller_> simbergm: do you remember what the problem with constexpr and nvcc was?
<heller_> it looks like we absolutely require that now...
<simbergm> heller_: I don't know what the problem was, just that it was a problem with clang-cuda
<simbergm> and then it was disabled for all of cuda
<simbergm> diehlpk_work should know more
<heller_> diehlpk_work: works for me (tm)
jbjnr has joined #ste||ar
<heller_> simbergm: works for me (tm)
<simbergm> heller_: with clang?
<heller_> clang and nvcc, yes
<simbergm> (I didn't try)
<simbergm> works with nvcc at least
<simbergm> ok
<heller_> alright. I'll setup the appropriate testers...
<simbergm> you'd better check still with patrick, I think he was building octotiger
<heller_> ok
<heller_> might be a bug in octotiger?
<simbergm> yeah, possible
<simbergm> so did you get everything built then?
<heller_> not yet ...
<heller_> had an exam
<simbergm> :P
<simbergm> I thought you were out of school...
<heller_> I was the examiner, not the examinee
<heller_> and I have one more exam to go
<simbergm> ah, makes more sense
<heller_> I'm also getting rid of CUDA_ARCH, this is causing me nothing but trouble
<simbergm> go wild
<heller_> i love that machine ... building with 32 processes on 188 ram on a ssd
<heller_> and still 16 cores left
<heller_> simbergm: btw, the runtime/core suspension tests like to fail quite often as well recently ;)
<simbergm> heller_: I know :/
<heller_> uups, sorry about rostam ...
<simbergm> what did you do?
<heller_> restarted while builds were ongoing ;)
<heller_> and hopefully fixed the cuda builder...
daissgr has joined #ste||ar
<Yorlik> Is there any dedicated place in the documentation for all the needed macros or is it better to just skim through the quickstart examples?
<Yorlik> I'm trying to give myself a structure for learning and it seems for now that the concepts of actions and components and all their helper macros probably is a good start.
<Yorlik> Thanks !
<Yorlik> It feels like an initial wall, but a manageable one. Thinking of what I get for it, I feel its totally worth going through that.
<Yorlik> :)
<heller_> if anyone here is in the erlangen (nuremberg area) on february the 28th
<heller_> you are invited to attend my doctoral examination starting at 14:00 with the topic "Extending the C++ Asynchronous Programming Model with the HPX Runtime System for Distributed Memory Computing".
hkaiser has joined #ste||ar
<zao> \o/
<hkaiser> Yorlik: think about HPX actions as a way to invoke a (global) function remotely, and HPX components as a way to expose C++ objects remotely - there isn't anything else to it
<Yorlik> Well ... and there is all this CPU utilization efficiency and swapping out of greenthreads/fibers/tasks on blocking operations, the dependency management put into futures, the standards compliant interface and more. There's a lot to like about it, I think.
<Yorlik> :)
<Yorlik> Also opening up the possibilities to parallelize more and more of your code in a relatively painless way
<Yorlik> A big problem in our area is the crosstalking problem between gameobjects (players crammed into a narrow space)
<Yorlik> My impression is, that HPX, while ofc not being the silver bullet everyone wants, still offers a lot of convenience to solve the problems associated with this.
<Yorlik> In the end it comes down to many optimizations in many places and a good starting design. Having a tool helping with that is pretty significant, imo.
<heller_> hkaiser: I have a fix for the other assertion that fails
<Yorlik> I have a question concerning the definition of a locality: The docs say: "... a synchronous domain of execution ..." but also as an example "... a single node in a cluster ...". But isn't a node with multiple threads already a-synchronous? What does "synchronous" in the context of the definition of a locality mean then ?
aserio has joined #ste||ar
<heller_> Yorlik: where do you read that?
<Yorlik> Intuitiveky I'd think a locality should be a hardware (hyper-)thread
<heller_> Yorlik: I think that description is total nonsense
<Yorlik> :)
<heller_> a locality is the entire process
<heller_> represents*
<Yorlik> The program, managing the various threads and tasks then ?
<heller_> yes
<Yorlik> So two processes running on a machione would be two localities?
<heller_> exactly
<Yorlik> Thanks !
<Yorlik> I must admit I feel a little like a toddler walking through a new room, faling down a lot and hitting obstacles.
<Yorlik> But it's super esciting.
<Yorlik> :)
* Yorlik is a big playchild
jbjnr_ has joined #ste||ar
<hkaiser> Yorlik: a locality is the execution domain where you can put an upper limit on any asynchronous execution, for all practical intents and purposes (and in HPX) that is a process
<hkaiser> IOW, as soon as networking is involved all bets are off
<hkaiser> heller_: what assertion?
<Yorlik> Concerning networking: How free are we to use custom serialization, e.g could we integrate external libraries like Flatbuffers or CapnProto or is that not recommended?
<hkaiser> heller_: that's a strange one, everything is under a lock, right?
<hkaiser> Yorlik: sure, remember - it's just C++
<hkaiser> you can do whatever you want
<Yorlik> LOL - I'm coming from 4 years of straight development in Lua only and a wee bit of C# and C.
<heller_> hkaiser: same thing with the assertion you removed previously, no?
<hkaiser> no
<Yorlik> It's a bit like a snake changing skin for me in the moment.
<hkaiser> that one was going through a section without the lock (inside the wait)
<hkaiser> Yorlik: if you have objects that use CpnProto or similar for their serialization you can simply invoke that from inside the hpx serialization functionality
<heller_> hkaiser: ah right ... missed the wait
<Yorlik> I'm lacking tons of low-level knowledge and experience and need to get up to speed there.
<hkaiser> serialization is turning objects into byte streams and back, so any code that is doing that is fine
<heller_> hkaiser: fact is: running since a few hours now without hangs or assertions
<Yorlik> Nice.
<hkaiser> heller_: ok, I might miss something
<hkaiser> the change you made does not hurt in any way
<heller_> yeah
jbjnr__ has joined #ste||ar
akheir has joined #ste||ar
jbjnr_ has quit [Ping timeout: 250 seconds]
akheir has quit [Client Quit]
akheir has joined #ste||ar
<hkaiser> simbergm, jbjnr, heller_, aserio: do we have our meeting now?
<hkaiser> jbjnr__: ^^
<heller_> hkaiser: supposedly
<heller_> give me a second
<aserio> ahhh
<aserio> yes
<diehlpk_work> heller_, I did some fixes for nvcc when I was compiling octotiger on powerpc
<diehlpk_work> I could com[pile hpx with cuda 9.2 and gcc 6/7
eschnett_ has joined #ste||ar
<Yorlik> What IDE do you guys use for development on Linux/*ix systems? I'm strongly tempted to use VS and just compile remotely via SSH. IntelliSense is just too nice.
<Yorlik> For my former Lua development I just used SublimeText for everything.
<diehlpk_work> Yorlik, I use eclipse
<Yorlik> I used eclipse long ago for some minor java stuff only - how is it for C++ development?
<diehlpk_work> Good
<diehlpk_work> I use it for c++ and python
<diehlpk_work> You just need to install the plugins for c/c++ and python
<Yorlik> Did you use it on Wondows too, targeting MSVC?
<Yorlik> I have to work on both platforms and would prefer to use a single environment fo both.
<diehlpk_work> No, I only use Fedora
<Yorlik> I think I'll revisit eclipse - after all its cross platform.
<Yorlik> I might just run into problems when compiling UnrealEngine, which kinda defaults to VS
<Yorlik> But there will be a long time before we really go into graphical client intzegration
<zao> Voluntarily considering Eclipse... that's a first one :)
<Yorlik> LOL
<Yorlik> Nice - FreeBSD server ...
<zao> I've found CLion reasonably fine over the years, but it's not free and on Windows there's not really anything better than VS. Qt Creator worked somewhat OK for a while too.
<zao> (but again, not really good on Windows)
<Yorlik> I'm kinda constantly sneaking around CLion, but their Cmake opnly supports the makefile backend
<Yorlik> Because of the future need to work a lot with the Unreal Engine I might just have to stay with VS
<hkaiser> is that so bad?
<Yorlik> NO - but since I also have to work on Linux (for our server) I'm a little bit torn. Simply trying to avoid as much friction as possible concerning IDEs
<Yorlik> Remote compiling a Linux Project with VS actually is an option.
<hkaiser> : right
<Yorlik> It just feels weird.
<Yorlik> So - there will be a windows client dll as a plugin for the Unreal engine, a Linux server (several actually) and some shared code to allow client side simulation prediction for user experience (server stays authoritative))
adityaRakhecha has joined #ste||ar
<adityaRakhecha> Because of removing prev version of opencv I somehow deleted my intire UBuntu files and now I have again started to build hpx.
<adityaRakhecha> compiling of this program examples.quickstart.fibonacci_local is succesful but not running
<adityaRakhecha> after running `./bin/fibonacci_local` I am getting core dumped error.
hkaiser has quit [Quit: bye]
<simbergm> adityaRakhecha: that should not be happening
<simbergm> does anything else run correctly? hello_world? simplest_hello_world?
<simbergm> diehlpk_work: just pushed another commit to release
<simbergm> did you see my messages from earlier?
<adityaRakhecha> NO. All are getting core dumped error.
<adityaRakhecha> This didnot happen last time.
<diehlpk_work> simbergm, Yes, somehow I can not really influence the cmake options, because fedora set them for me
<diehlpk_work> Ok, so I would not need to use sed to update python in the templates?
<simbergm> diehlpk_work: if you were only doing it for the templates, no, but if you did it for some other files as well you'll still need to do those
<heller_> Yorlik: the cool kids use vim and a shell
<simbergm> and sure, let fedora do it's thing but remove LIB because that was our own thing
<Yorlik> emacs ftw ...
<simbergm> heller_: ehm, emacs, right?
* Yorlik was faster ;)
<simbergm> enough said
<Yorlik> But seriously - I've learned to love Sublimetext. Been using it for years and recently finally succumbed to buying the license.
<diehlpk_work> ok, simbergm I will give it a try with the new release
daissgr has quit [Ping timeout: 250 seconds]
detan has joined #ste||ar
<heller_> simbergm: I appreciate my fingers staying in proper positions and I don't need yet another OS :p
<simbergm> heller_: you just haven't tried evil mode yet
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 264 seconds]
aserio1 has joined #ste||ar
aserio1 is now known as aserio
akheir has quit [Quit: Konversation terminated!]
akheir has joined #ste||ar
jbjnr has quit [Ping timeout: 252 seconds]
<adityaRakhecha> IT's ok. I will sort it out by myself.
jaafar has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
<simbergm> adityaRakhecha: yeah, hard to say what could be going wrong without more information, but start with a clean build dir and check that boost is built with the same settings as hpx (if you've built it yourself)
adityaRakhecha has quit [Ping timeout: 256 seconds]
david_pfander has quit [Read error: Connection reset by peer]
david_pfander has joined #ste||ar
detan has quit [Ping timeout: 256 seconds]
jbjnr has joined #ste||ar
khuck has joined #ste||ar
<khuck> hkaiser: got a minute?
<hkaiser> khuck: sure
<khuck> how do you configure blaze/phylanx to use mkl? For the life of me I cannot figure it out
<hkaiser> khuck: I did it on windows only
<khuck> regardless
<hkaiser> sec
<hkaiser> setting several options in cmake:
<hkaiser> BLA_VENDOR=Intel10_64lp_seq
<khuck> ok, didn't know about that one
<hkaiser> BLAS_LIBRARIES=mkl_core;mkl_sequential;mkl_intel_lp64;mkl_blas_lp64;
<khuck> mostly, I am trying to figure out how to pass the blas/lapack libraries to blaze/phylanx
<khuck> ok, looks familiar. what about the path to those libraries?
<hkaiser> and BLAS_mkl_lapack_LIBRARY=mkl_lapack95_lp64
<hkaiser> yah, with full paths, all of them
<khuck> so, for example:
<khuck> BLAS_LIBRARIES=/path/to/libmkl_core.so;/path/to/... ?
<khuck> I tried that, and cmake butchered it
<hkaiser> hmmm, worked for me
<khuck> of course
<hkaiser> lol
<khuck> cmake is just adding -l to each of the libraries in BLAS_LIBRARIES and LAPACK_LIBRARIES
<khuck> but I can't figure out how to pass the -L path in
<khuck> is there a way to brute force it?
<hkaiser> it retains the paths for me :/
<hkaiser> no idea
<khuck> and what's the difference between the ilp and lp libraries?
<hkaiser> no idea ;-)
<khuck> can you post your actual BLAS_LIBRARIES setting, with full paths?
<hkaiser> khuck: BLAS_LIBRARIES:FILEPATH=C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win/mkl_blas95_lp64.lib;C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win/mkl_intel_lp64_dll.lib;C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win/mkl_sequential_dll.lib;C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl
aserio has joined #ste||ar
<khuck> does the :FILEPATH tell cmake something special?
<hkaiser> khuck: "BLAS_LIBRARIES:FILEPATH=C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win/mkl_blas95_lp64.lib;C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win/mkl_intel_lp64_dll.lib;C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win/mkl_sequential_dll.lib;C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mk
<hkaiser> l/lib/intel64_win/mkl_core_dll.lib"
<hkaiser> I just copied the content of my cache
<khuck> OK
<khuck> what do you actually pass to cmake?
<hkaiser> the settings I listed above (well with full paths)
<khuck> whew, it works I think
<khuck> -DBLAZE_BLAS_INCLUDE_FILE=<mkl_cblas.h> -DBLAS_LIBRARIES=${BLAS_DIR}/lib/intel64/libmkl_core.so;${BLAS_DIR}/lib/intel64/libmkl_sequential.so;${BLAS_DIR}/lib/intel64/libmkl_intel_lp64.so;${BLAS_DIR}/lib/intel64/libmkl_blas95_lp64.a; -DLAPACK_LIBRARIES=${BLAS_DIR}/lib/intel64/libmkl_lapack95_lp64.a;
<khuck> thanks
<khuck> I am hoping we'll see better performance on ALS with mkl instead of BLAS/LAPACK
<jbjnr> hkaiser: good news. using this queue instead of boost::lockfree:deque in fifo mode gives a significant speedup https://github.com/cameron314/concurrentqueue
<jbjnr> (in the schedulers).
<khuck> jbjnr: ha - I've been using that lock-free queue in APEX for years
<jbjnr> khuck: that's great. So you can testify that it's safe and reliable too I hope
<khuck> depends on your opinion of APEX ;)
<jbjnr> There's a place in our thread queues where I want to try using it for more speedups.
<khuck> yeah, it's worked for me.
<jbjnr> APEX. Awesome
<jbjnr> if you've fixed that task naming bug. I need to test it again since you made fixes
<khuck> it's in HPX. Not sure it's what you want, though.
<khuck> if the task doesn't have an annotated_function() wrapper, there's not much to go on
<khuck> let me rephrase that - the task needs a "good" task description
<jbjnr> do you meana warpper, or is it enough to use the raii version?
<jbjnr> there are two annotated function modes
<jbjnr> one is a wrapper, the other an raii
<jbjnr> I prefer the raii one
<khuck> not sure
<jbjnr> ok. I'll test and report back
<jbjnr> (not today though)
<khuck> jbjnr: I just checked, and APEX is using a frozen version of that library from a few years ago. I should probably fix that.
<jbjnr> seems to be well maintained. a merge was done a few weeks ago and previously in dec 18. Looks like tweaks and improvements are ongoing. probably worth upgrading.
<khuck> I grabbed the version from August 27, 2015. Likely things are better.
jaafar has quit [Ping timeout: 257 seconds]
hkaiser has quit [Quit: bye]
diehlpk has joined #ste||ar
<diehlpk> simbergm, New fedora build
<diehlpk> it seems that /usr/lib/ is now the default for all
<diehlpk> on x86 it is installed to /usr/lib instead of /usr/lib64
<diehlpk> on i686 it is working, but it can not find the mpi paths
eschnett_ has quit [Quit: eschnett_]
hkaiser has joined #ste||ar
<jbjnr> hkaiser: yt?
<hkaiser> I'm here to serve
<jbjnr> very good.
<jbjnr> quick question
<jbjnr> but I need a moment to type
<jbjnr> this move assignment is trying to call the
<jbjnr> /home/biddisco/src/hpx/hpx/util/tuple.hpp:264: error: use of deleted function ‘hpx::threads::thread_init_data& hpx::threads::thread_init_data::operator=(const hpx::threads::thread_init_data&)’
<jbjnr> ((this->get<Is>() = other.template get<Is>()), 0)...
<jbjnr> ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
<jbjnr> assignment operator with a const ref and not a move
<hkaiser> ok
<hkaiser> this is a bug in our implementation
<jbjnr> does that seem right?
<hkaiser> K-ballo: ?
<hkaiser> should have a std::move() in it
<K-ballo> looks wrong
<hkaiser> nod
<jbjnr> ok. Thanks. I suspected as much, but was worried about touching this
<jbjnr> if I fix this, then the alocation can be removed from the thread_data_init map insert/delete
<jbjnr> cos I'm using the new lockfree queue
<hkaiser> ... = std::move(other.template get<Is>())
<jbjnr> ta
<K-ballo> mmh no, probably not
<K-ballo> because reference types
<hkaiser> uhh, but it's wrong anyways, other is a rvalue
<K-ballo> yeah, but it should be some form of forward, one sec
<K-ballo> `this->get<Is>() = std::forward<Ts>(other.template get<Is>())`?
<hkaiser> K-ballo: shouldn't it just be operator=(tuple_impl&&) = default; ?
<K-ballo> no, because references assign throu
<K-ballo> think std::tie
<hkaiser> nod, ok
aserio has quit [Quit: aserio]
<jbjnr> wtf is the sequencter_ in there?
<hkaiser> just a poor man's folding operator
<K-ballo> an array, it's there to guarantee left-to-right evaluation
<jbjnr> I'm not sure where to put std::tie - just replce the sequencer with std::tie?
<K-ballo> std::tie was just an example of why it couldn't be =default
<K-ballo> the whole line should read:
<K-ballo> ((this->get<Is>() = std::forward<Ts>(other.template get<Is>()), 0)...
<jbjnr> ok. much clearer. thanks
jaafar has joined #ste||ar
<K-ballo> is it missing one closing parens?
<jbjnr> yup. fixed that already.
<K-ballo> yes, sorry
<jbjnr> machine ground to a halt when the ide started displaying about 10k errors!
<jbjnr> compiling now.
<jbjnr> fingers crossed
<K-ballo> surprising this never hit before..
<jbjnr> stuff like this makes me realize just how much work has gone into hpx and how hard it'll be for others to do the same
<hkaiser> I'd even add another ', 0' in the end
jaafar_ has joined #ste||ar
<hkaiser> sometimes msvc complains about having to allocate a zero sized array otherwise
jaafar has quit [Remote host closed the connection]
<K-ballo> empty tuple<> is special cased
<hkaiser> ahh ok, then it's fine
<K-ballo> maybe for that very reason, don't recall
<jbjnr> you two are amazing.
<jbjnr> spotting stuff like that requires having a compiler in your head really.
<jbjnr> compiling ok now. we might be on to a winner with the new thread map
<hkaiser> jbjnr: nice
<diehlpk> simbergm, nevermind, I fixed the installation path and could build hpx on fedora'S build system
<diehlpk> But the path in cmake is still wrong set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "/usr/lib/cmake/HPX")
<jbjnr> thanks K-ballo hkaiser
<jbjnr> it works
<jbjnr> looks like we have a 10% speedup from my first run.
<hkaiser> great
<jbjnr> that's on top of a speedup from replacing the other queues already btw
<diehlpk> simbergm, For openmpi and mpich the path is include("${CMAKE_CURRENT_LIST_DIR}/HPXMacros.cmake")
<diehlpk> hkaiser, I tested hpx 1.2.1 on the fedora build system and installed the packages on my locla machine
<diehlpk> We still need to fix bugs in cmake
<hkaiser> nice
<diehlpk> But everything else works now
<diehlpk> If I correct the path by hand, we can compile hpx programs and run them
<diehlpk> with gcc and openmpi
<hkaiser> thanks!
diehlpk has quit [Ping timeout: 250 seconds]
jbjnr has quit [Ping timeout: 250 seconds]
<K-ballo> were did vs' little window with cpu and memory usage during debug go?
<K-ballo> the "diagnostic tools"
<parsa_> debug->window->diagnostics*
<parsa_> ctrl-alt-f2
parsa_ is now known as parsa
<Yorlik> parsa: Thanks a lot for fixing my mess yesterday! :)
<parsa> no problem
<Yorlik> It gave me some nice pointers for learning.
<parsa> you may wish to go over the launching and configuring HPX applications part of the hpx docs