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
hkaiser has quit [Quit: bye]
diehlpk has quit [Ping timeout: 244 seconds]
K-ballo has quit [Quit: K-ballo]
nanashi55 has quit [Ping timeout: 264 seconds]
nanashi55 has joined #ste||ar
jaafar has quit [Ping timeout: 240 seconds]
jbjnr has joined #ste||ar
biddisco has joined #ste||ar
jbjnr_ has joined #ste||ar
jbjnr has quit [Ping timeout: 240 seconds]
<M-ms>
jbjnr_: how about trying gcc to rule out libc++ or clang? I think mathieu has a full gcc stack that you could use
<jbjnr_>
M-ms: would be a good plan. I am still setting up stuff in my horrid new office. Not going to get much done for a bit
<biddisco>
\help
biddisco has left #ste||ar ["WeeChat 2.1"]
<heller_>
jbjnr_: sounds a bit like a stack overflow?
<zao>
Sounds silly, considering that the set of libraries installed may not be at all what autolinking expects.
<jbjnr>
zao: no. I have just compiled boost myslef and the cmake stuff is finding it fine
<zao>
jbjnr: The problem is that Boost.Config has an "autolink" feature when using MSVC, where it "intelligently" decides what libraries to link with #pragma comment(lib,"libboost-blargh...")
<hkaiser>
jbjnr: release/debug mismatch?
<zao>
(the generic problem, not necessarily _your_ problem, that is)
<zao>
It can be disabled and have the user link everything themselves, but apparently we don't do that for regular builds.
<hkaiser>
jbjnr: release/debug will cause linker errors with boost
<zao>
The autolinker might be looking for the wrong variant or dynamic/static libraries you may not have built.
<zao>
What kind of errors do you get?
<zao>
Libraries not existing at all, or some particular symbols?
<jbjnr>
just a couple of symbols
<zao>
Personally, I tend to use the binary downloads from boost.org, Good Enough for me.
<hkaiser>
jbjnr: I'd bet it's a release/debug mismatch
<jbjnr>
lost them now as I started a rebuild. I am familiar with the boost autolinking.
* zao
nods
<zao>
hkaiser: As in debug Boost w/ Release HPX?
<zao>
Shouldn't that be handled properly by FindBoost and friends?
<hkaiser>
or vv.
<hkaiser>
cmake sometimes fails to handle that correctly
<zao>
Joy.
<hkaiser>
yah
<jbjnr>
it's not a debug/release problem
<hkaiser>
I tend to explicitly specify CMAKE_BUILD_TYPE=Debug, in which case cmake finds both types properly
<hkaiser>
the generated VS project then properly handles both configs
<zao>
What Boost version, any particular flags, what --layout?
K-ballo has joined #ste||ar
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
<zao>
Dependencies on MSVC seem to be a bit botched...
<zao>
»50>LINK : fatal error LNK1104: cannot open file '..\..\..\Debug\lib\hpxd.lib'«
<zao>
Someone's doing something naughty with std::streampos in slurm_environment.cpp :D
<zao>
Oh gods, Boost.Iostreams is assuming things about the implementation.
<zao>
2>c:\local\boost_1_67_0\boost\iostreams\positioning.hpp(96): error C2039: 'seekpos': is not a member of 'std::fpos<_Mbstatet>' (compiling source file F:\Stellar\hpx\src\util\batch_environments\slurm_environment.cpp)
<zao>
Didn't Billy rewrite MSVC's impl lately?
<K-ballo>
why didn't I run into those?
<zao>
I'm on the Preview compiler.
<K-ballo>
courageous
<zao>
Comments in headers make it sound like they're transitioning away from _Fpos completely, setting it to 0 for new code.
<zao>
K-ballo: I'd build with the regular compiler if I could be arsed finding the gosh-darn powershell scripts to set the correct vcvars environment.
<zao>
Let's see if I managed to hit the old compiler now.
<K-ballo>
so boost.iostreams broken for msvc, lovely
<jakub_golinowski>
M-ms, yt?
<M-ms>
jakub_golinowski: I will have a short meeting soonish, can let you know when I'm done and we can have the call whenever after that
<jakub_golinowski>
M-ms, OK I just got back home and am available the whole evening
<zao>
There's plenty of errors in tests with regular 2017 too, fwiw.
<zao>
K-ballo: std::uniform_int_distribution<uint8_t>, didn't you people mention this the other day?
<K-ballo>
yeah, PR ready and waiting
<zao>
Ah.
<zao>
28>f:\stellar\hpx\hpx\parallel\algorithms\find.hpp(582): error C3489: '&op' is required when the default capture mode is by copy (=)
<zao>
Ooh, an ICE.
<zao>
I should probably upgrade to 15.7.5
<K-ballo>
PR ready and waiting for the captures too
_bibek_ is now known as bibek
<jbjnr>
zao: i forgot to say. I fixed the problem by recompiling boost with -DBOOST_PROGRAM_OPTIONS_DYN_LINK=1 as instructed here https://svn.boost.org/trac10/ticket/13326
<jbjnr>
known bug it seems. (feature). That's why I asked if hk used any special settings
<jbjnr>
last time I used boost on windows was 1.59
<jbjnr>
now 1.67
<zao>
Eew, you can tune that at Boost build time?
<zao>
I wonder how my binary Boost is built, as that "works".
<jbjnr>
some #define means the symbols are not there if you don't
<jbjnr>
(buggy feature)
<M-ms>
jakub_golinowski: now?
diehlpk has joined #ste||ar
<zao>
cmake_build_dir_test fails to compile, linker errors in schedule_last_test_exe, those bloody HPX_COMPILER_FENCE things in spinlock_overhead*.
<zao>
MSVC error list doesn't get easier to navigate with all these fail_* tests polluting it :)
<K-ballo>
pr ready and waiting for those bloody fences too
<zao>
Figured as much :D
galabc has joined #ste||ar
hkaiser has joined #ste||ar
<zao>
K-ballo: Is foreach_prefetching_test_exe ICE:ing for you?
<M-ms>
jakub will hopefully have some good benchmark results to show tonight, but this vpisarev guy already seems a bit more positive about the backend than in the beginning
<diehlpk_work>
Yes, I think we should mention that this is more a proof of concept and we have to investigate for performance improvements
jakub_golinowski has quit [Quit: Ex-Chat]
jakub_golinowski has joined #ste||ar
<jakub_golinowski>
M-ms, I just realized there are binaries of opencv_perf_dnn
<jakub_golinowski>
I think this incorrect closing of test applcation is the reason for the performance dependency on the order of launches
<M-ms>
jakub_golinowski: I don't follow
<jakub_golinowski>
So I noticed that I have the 20% utilization of all cores
<jakub_golinowski>
Then I looked into processes in the System Monitor
<jakub_golinowski>
and found 7 or so instances of opencv_perf_test running and they were at the top of the cpu consumption list
<jakub_golinowski>
Therefore I am now suspecting that the test apps are not closed properly? Maybe it has to do sth with them being run from bash script?
<jakub_golinowski>
not sure - exploring that now
<nikunj>
hkaiser, yt?
<M-ms>
That would be bad... I'll check in a bit if I have some leftovers
<jakub_golinowski>
but I am not 100% sure as I was developing the script and the leftovers might be from that
<jakub_golinowski>
(some wrong launches etc...)
<M-ms>
jakub_golinowski: all clean here, but I was launching mine directly from the command line, not through a script
<M-ms>
also cancelled quite a few runs and it seems to have worked fine
<jakub_golinowski>
M-ms, ok will investigate that
<jakub_golinowski>
but I had some bad launches that hanged
<jakub_golinowski>
maybe did not kill them properly
<jakub_golinowski>
this was caused by bad args
jaafar has joined #ste||ar
nikunj has quit [Quit: Leaving]
galabc has quit [Quit: Leaving]
aserio has joined #ste||ar
jakub_golinowski has quit [Remote host closed the connection]
jakub_golinowski has joined #ste||ar
<jakub_golinowski>
M-ms, I had some issues and cpufrequutils settings wer ignored by the intel_pstate driver
<jakub_golinowski>
but now I succeded in upeer bounding the cpu at lower freq
nikunj has joined #ste||ar
nikunj has quit [Quit: goodnight]
hkaiser has quit [Quit: bye]
<jbjnr>
M-ms: you were telling me that i can't use command line params if I include hpx_main - I can't write hpx apps any more
<jbjnr>
terminate called after throwing an instance of 'std::invalid_argument'
<jbjnr>
what(): hpx::resource::get_partitioner() can be called only after the resource partitioner has been allowed to parse the command line options.
<jbjnr>
nevermind. seems to be working again
hkaiser has joined #ste||ar
<jbjnr>
hkaiser: how do I use --hpx:ini hpx.parcel.boot=tcp it says "what(): Attempt to initialize unknown entry: ..."
<jakub_golinowski>
or does it work without the first '=' as well?
<jbjnr>
hkaiser: thanks. Silly me
<jbjnr>
I used boot instead of bootstrap
jakub_golinowski has quit [Quit: Ex-Chat]
aserio has quit [Quit: aserio]
<jbjnr>
hkaiser: or heller_ if I did not compile with MPI parcelport - is there any way I can mpirun -n 4 blah blah (boot = tcp) on a single node and get the localities to correctly initialize without manually having to do agas and hpx for every instance. I can't seem to find a way of getting the mpi env to do the setup of the ports and nodelist
<hkaiser>
jbjnr: I don't think so
<hkaiser>
but on a single node setting up multiple localities should be trivial
<hkaiser>
app --hpx:localities=N -0 &
<hkaiser>
app -1 &
<hkaiser>
...
<hkaiser>
app -N
<hkaiser>
-(N-1) that is
<hkaiser>
jbjnr: or use hpx_run.py --localities=N app