<mdiers_>
-DCMAKE_DEBUG_POSTFIX="" has unfortunately not helped
<jbjnr>
mdiers_: why is the extra d a problem. The debug and release builds are not binary compatible, so it's a good idea to have different names to avoid link/run time problems
<simbergm>
lsl88: yt? do you think you'd have time to combine your PRs into one before we lose you?
<jbjnr>
simbergm: I'm free for a call any time this morning (wanted to pop out ata about 11:30 but I can do that after lunch)
<simbergm>
jbjnr: sounds good
<simbergm>
let's do it whenever heller shows up
<mdiers_>
jbjnr: yes, since the builds in general could not be binary compatible, and therefore the headers are partly dependent on the build type, i have gone over to having uniformly completely separate builds.
<heller>
jbjnr: simbergm: would after lunch be ok for you as well?
<simbergm>
heller: everything except 2-2:30 PM works
<jbjnr>
ok for me too
<jbjnr>
simbergm: do we have group meeting today or is it cancelled
<simbergm>
jbjnr: actually not sure, haven't seen ben around today so might be cancelled
<jbjnr>
fingers crossed
<simbergm>
yeah, he's gone so anytime is fine
<simbergm>
jbjnr: I think cdash is back in business
<simbergm>
changed to https...
<simbergm>
and btw, I got complaints from operations about using srun for the tests, I had to remove it
<jbjnr>
sorry - remove it from where - from the cmake, or from the build script
<simbergm>
jbjnr: just from the build/test script
<simbergm>
your pr from ages ago would still be nice to have
<jbjnr>
I never finished that PR I don't think. It didn't work properly - if you mean the srun for testing stuff.
<heller>
jbjnr: simbergm: ping me once you are free
<jbjnr>
having lunch now, back in 20-30 mins
<heller>
Kk
<simbergm>
heller, jbjnr free now
<jbjnr>
ok. gimme 2 mins to move to another room
<heller>
Me as well...
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
<simbergm>
jbjnr: btw, to add to your stress, is there anything that still needs to be done for the gpu hackathon application?
<jbjnr>
probably.
<jbjnr>
I'll ping diehlpk_work about it.
<jbjnr>
ping diehlpk_work ^^^
<jbjnr>
:)
<jbjnr>
I'm a mentor, so I don't have to do anything, and the application is just a quick form to write half a page
<hkaiser>
simbergm: all_to_all PR should be fine now
<hkaiser>
thanks for reviewing!
<diehlpk_work>
jbjnr, Gregor and parsa will work on the proposal this week
<jbjnr>
diehlpk_work: great - it should be half a page deascribing the project. doesn't need a lot of work if I recall.
<diehlpk_work>
Gregor works currently to get this FMM code compiled on Daint
<diehlpk_work>
And compares apples with bananas. We try to compare our FMM code with the their MPI+CUDA implementation
<jbjnr>
any results to speak of yet?
<diehlpk_work>
No, he just got the code compiled and Dominic works on getting the most similar scenario
<diehlpk_work>
We do not have node hours on Daint yet. We have to wait for next month
<diehlpk_work>
We burned all our hours for the SC paper
<jbjnr>
if you need to run something, then ask me. I'm a bit busy, but for the paper, I'll find a way
<diehlpk_work>
Thanks, I will let Gregor know
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
daissgr_work has joined #ste||ar
<simbergm>
tarzeau: yt? I got hello world running, but I'm not sure the dependencies are quite right, had to install some manually
<simbergm>
specifically some of the build-depends of libhpx-dev should be depends maybe? but I'm not sure what the conventions are for that on debian
<tarzeau>
to build the package from source? that can perfectly be , what was missing?
<tarzeau>
aha libhpx-dev (the header files only) should depend on libhpx1 ? or what do you mean?
<tarzeau>
but basically you were able to install your own built deb packages, install them and build your own software linking against libhpx?
<tarzeau>
any suggestions/comments are welcome, that improve the packaging, and usefulness of it for a broad audience
<simbergm>
tarzeau: I didn't build it myself, just used the ones you'd built
<simbergm>
but yes, I think libhpx-dev should probably depend on libhpx1
<simbergm>
and the second is that if I install libhpx-dev and libhpx1 I don't actually get any of the boost or hwloc headers installed
<simbergm>
not sure if it's me messing up the install or not
<simbergm>
I did apt install ./libhpx-dev...deb for the record
<simbergm>
I think I did get the library dependencies via libhpx1 though
<simbergm>
I'd have to check again what exactly was installed and what was missing
<tarzeau>
normally i use dpkg -i *.deb with single packages, apt only works if it's taken from a deb repo (official, or ppa or reprepro)
<tarzeau>
dpkg -l |grep hpx # :)
<simbergm>
apt apparently does install local packages nowadays
<tarzeau>
i didn't know
<simbergm>
I couldn't get the dependencies installed automatically with dpkg so I tried apt instead
<simbergm>
I'd assume apt does the right thing with local packages but who knows
<simbergm>
and I noticed you'll need to change HPX_WITH_MALLOC=system to jemalloc to actually use jemalloc, probably a leftover
<simbergm>
an MPI variant would be nice to have
<simbergm>
it could even be the only option
<tarzeau>
yes dpkg doesn't handle deps, it's you have to do it
<tarzeau>
i started with system, but already added jemalloc, then figured there's 5 more *mallocs
<tarzeau>
so i'm not sure which one to take, or wheather i should build all of them with -jemalloc -tcmalloc appended in pkg name, so i start with the system one for a start
<tarzeau>
mpi there's openmpi and the other mpi right?
<hkaiser>
tarzeau: no need for more than one allocator, jemalloc should be fine
<heller>
tarzeau: doesn't Debian have a meta mpi package?
<heller>
Just use that as a dependency
<heller>
IIRC, there was some problem with either Debian or Ubuntu properly messing up their openmpi package