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
<jgolinowski>
ms[m]1, I started work on the final summary in the blog post as well
diehlpk has quit [Remote host closed the connection]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
nikunj has joined #ste||ar
nanashi55 has quit [Ping timeout: 248 seconds]
nanashi55 has joined #ste||ar
<zao>
heller: the rationale for a distinct environ is that there’s no global convenience one like on Linux/glibc in all modules, so we have to wire up our own, if I remember right
<zao>
An appropriate answer would be that people write code relying on shitty implementation detail that requires tons of workarounds for fun OSes
<zao>
I can’t follow the thread at all on this mobile mail client, but no, it’s a pipe dream that OSes can be split into Windows and “others” as long as Linux dominates the minds of people.
<zao>
Doesn’t help that not even Boost gives any shits.
<zao>
The poor soul is on NetBSD... hohoho
<zao>
Made some sort of rambly answer.
<heller>
Thanks
<zao>
Heading down to the parents for the rest of the week, so I'll probably be rather away later.
<heller>
zao: have fun.
<heller>
would be interesting if the behavior is different for current master of FreeBSD though
jgolinowski has joined #ste||ar
<ms[m]1>
jgolinowski: phase 3 missing in the blog post, right?
<ms[m]1>
README and blog post look very nice from a quick read, but I'll still write down a list of typos and suggestions for you
<jgolinowski>
ms[m]1, ah yes I had to go to sleep and the phase to is still to be written
<jgolinowski>
I will do it today
<ms[m]1>
yeah, no problem
<ms[m]1>
sleep is necessary ;)
<ms[m]1>
just wanted to check that it wasn't missing by accident
jgolinowski has quit [Ping timeout: 256 seconds]
david_pfander has joined #ste||ar
<zao>
heller: Speaking of Boost, 1.68.0 doesn't build properly on FreeBSD as C++14.
<zao>
bootstrap.sh doesn't autodetect the proper toolset, and if you go '--with-toolset=clang"'it seems to build with a command it calls "clang-linux.compile.c++.with-pch" and "clang-linux.compile.c++.without-pth".
<zao>
I knew Boost had become indifferent to other platforms, but breaking this hard? Never thought I'd see it.
<zao>
Was gonna try building on my dinky 2-core FTP machine as it runs FreeBSD 11.2-RELEASE.
<zao>
And of course, nikunj broke FreeBSD's build too :P
<zao>
Could not find the following Boost libraries: boost_context
<zao>
Well, it's right there, screw this.
<zao>
Might be the failed Boost.Math build, I guess.
<heller>
"yay"
<heller>
weren't you supposed to have fun with your family?
<zao>
They haven't arrived yet.
<zao>
Figured I'd kick off a quick build on the 11.2 machine to see how bad it currently is.
jbjnr has quit [Read error: Connection reset by peer]
<nikunj>
zao, what is the error saying?
<zao>
It's the same problem that your 3402 PR addresses.
<nikunj>
iirc Freebsd is unix, so it should build the previous way
<nikunj>
aah! 3402 didn't get merged that's why it's breaking
<heller>
this is how it looks on paper, with proper dimensional relations
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
eschnett has quit [Quit: eschnett]
eschnett has joined #ste||ar
mcopik has joined #ste||ar
hkaiser has quit [Quit: bye]
jbjnr has joined #ste||ar
hkaiser has joined #ste||ar
Vir has joined #ste||ar
aserio has joined #ste||ar
Anushi1998 has joined #ste||ar
Anushi1998 has quit [Client Quit]
<jbjnr>
nikunj: is your runtim init already usable - I have some tests that use std::thread+friends and I've modified them to use hpx tasks, but the test does not call hpx_main/et. I'd quite like to try out the runtime init to see if I can get these tests to pass without me changing the startup
<nikunj>
jbjnr, if you include `hpx_main.hpp`, everything should be initialized from main itself (i.e. main will be running on an HPX thread). So things should work without calling init to initialize the runtime system.
<jbjnr>
aha, so I still have to add hpx_main to the test. ok.
<nikunj>
jbjnr, yes! we chose to keep the previous hpx_main way since many of our tests and examples included it. This way we were able to make changes in the backend without affecting anything in these files.
<jbjnr>
if there was a way to do it without including hpx_main, but by setting an env var - that'd be handy too.
<nikunj>
I had implemented it that way before and things were running as well. Would you want me to add a CMake variable to add_hpx_executable to run things without including hpx_main?
<nikunj>
I could add it to cmake as well
<nikunj>
hkaiser, what say?
<jbjnr>
nikunj: 55: hpx::init: can't initialize runtime system more than once! Exiting...
aserio has quit [Ping timeout: 245 seconds]
<jbjnr>
aha. but my branch might not be up to date with latest master. I'd better rebase just in case
<jbjnr>
actually. I think the error is what(): hpx_startup::user_main: HPX(not_implemented)
<jbjnr>
bbiab
<K-ballo>
boost 1.68.0 is out, the iostream fix didn't make it
aserio has joined #ste||ar
aserio1 has joined #ste||ar
<nikunj>
jbjnr, did you call init after including hpx_main?
aserio has quit [Ping timeout: 265 seconds]
aserio1 is now known as aserio
<hkaiser>
nikunj: pls see #3404
david_pfander has quit [Ping timeout: 244 seconds]
mcopik has quit [Ping timeout: 255 seconds]
<jbjnr>
nikunj:
<jbjnr>
55: hpx is already initialized from main.
<jbjnr>
55: Note: Delete hpx_main.hpp to initialize hpx system using hpx::init. Exiting...
<jbjnr>
when I #include <hpx_main.hpp> and do not call init
bibek has quit [Quit: Konversation terminated!]
<jbjnr>
ooh. mayb eht eold code in the #defines is doing it. I'd better check the google test stuff I modified previously
bibek has joined #ste||ar
<heller>
[18:38:17]:heller@shoeshine:/home/heller/dissertation:0:$ /usr/bin/time -v make : Elapsed (wall clock) time (h:mm:ss or m:ss): 1:49.02
<heller>
fun
<jbjnr>
no. it's total rubbish. hpx_main.hpp create int main and calls init, then it blows up with init called twice
<nikunj>
hpx_main_impl.hpp is included in the case when HPX_HAVE_DYNAMIC_HPX_MAIN is off and it's not linux
<nikunj>
so in that case my implementation is turned off as well
<nikunj>
I do not think it's due to int HPX_CDECL main(int argc, char** argv) in hpx_main_impl.hpp
<nikunj>
jbjnr, Can you try the same with #3404. I think it should resolve the errors
<nikunj>
main.cpp also includes hpx_main_impl.hpp. So it might be confusing your program's int main with int HPX_CDECL main(int argc, char** argv) by calling that instead.
<nikunj>
My implementation calls the int main after initiating the hpx runtime system. So my call to int main might be getting redirected to int HPX_CDECL main(int argc, char** argv) instead
jgolinowski has joined #ste||ar
<jbjnr>
nikunj: fyi - this is my linux laptop
<jbjnr>
I will try 3404
<nikunj>
jbjnr, interesting. Things were working the last time I checked. Could you try running tests to check if the test suite is also failing?
<nikunj>
Also which flavor of Linux are you using?
<nikunj>
Your test code must be relying on a dynamic/static library which was getting linked with libhpx_init
<nikunj>
So it showed up first in the linker path as hkaiser said. My code wraps the first definition of int main so it wrapped int HPX_CDECL main(int argc, char** argv) instead. This way it was the function called by my implementation instead of users int main
<nikunj>
Now that the guard is active in src/main.cpp, things are back to normal
<hkaiser>
should we merge #3404
<hkaiser>
?
<nikunj>
I should have seen the source code properly. I thought that hpx_main was the only place where hpx_main_impl.hpp was included.
<heller>
hkaiser: why would you want to remove it, isn't that completely orthogonal?
<hkaiser>
reduce the size of the shared state
<heller>
ok, but then we have allocations in the completion handlers
<heller>
what's the size of the shared state currently?
<hkaiser>
200 bytes
<hkaiser>
with a bool as the value
<hkaiser>
what I meant is to use std::vector with the thread allocator
<hkaiser>
I'll do some tests
<heller>
hkaiser: ok, so we'd save about 48 byte or so
<heller>
but sounds like a plan
jaafar has quit [Ping timeout: 245 seconds]
<hkaiser>
heller: I tried, it makes perf worse
<hkaiser>
slightly, but measurably
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 245 seconds]
aserio1 is now known as aserio
<heller>
hkaiser: yeah... Two allocations vs one after all
<jgolinowski>
ms[m]1, yt?
<jbjnr>
hkaiser: heller what I said ws that the stream benchmark was not compatible with the RP. It should still work, but uses a non standard way of accessing the threads/executors