aserio 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/
diehlpk has joined #ste||ar
ct-clmsn_ has quit [Ping timeout: 265 seconds]
jaafar has quit [Ping timeout: 260 seconds]
jaafar has joined #ste||ar
vamatya has quit [Ping timeout: 268 seconds]
gedaj has quit [Ping timeout: 255 seconds]
gedaj has joined #ste||ar
diehlpk has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
vamatya has joined #ste||ar
eschnett has quit [Quit: eschnett]
ct-clmsn has joined #ste||ar
ct-clmsn is now known as Guest81104
diehlpk has joined #ste||ar
eschnett has joined #ste||ar
jaafar has quit [Ping timeout: 256 seconds]
hkaiser has joined #ste||ar
Guest81104 is now known as ct-clmsn__
eschnett has quit [Quit: eschnett]
hkaiser has quit [Quit: bye]
diehlpk has quit [Remote host closed the connection]
diehlpk has joined #ste||ar
diehlpk has quit [Remote host closed the connection]
<heller_>
the question is: will thread_id_type be used in comparisons other than == and !=, if the answer is yes, we need a proper wrapper there anyways
<K-ballo>
that's the kind of thing your changes ought to be careful of
<K-ballo>
with intrusive_ptr, whatever is defined (not the full set) behaves ok
<heller_>
I can be careful within my change, but I think it's not reasonable to ask for this in general (not using the relational operators, that is)
<K-ballo>
I don't see how we are disagreing?
<K-ballo>
it's not reasonable to ask to not use the relational operators, so give the types the proper ones
<heller_>
right
<K-ballo>
intrusive_ptr has the proper ones, raw pointer has not
<hkaiser>
heller_: I think you should create a wrapper separate type anyways
<hkaiser>
separate wrapper type*
<heller_>
that's the conclusion of this discussion
<hkaiser>
if for nothing more than proper implicit initialization
<K-ballo>
so should I go back to x.id_ < y.id_ ?
<heller_>
yeah
<github>
[hpx] K-ballo force-pushed thread-id-relops from 1ef56d3 to 17768df: https://git.io/vNBTs
<github>
[hpx] K-ballo opened pull request #3107: Remove UB from thread::id relational operators (master...thread-id-relops) https://git.io/vNBi8
jaafar has quit [Ping timeout: 276 seconds]
rod_t has quit [Ping timeout: 276 seconds]
mcopik has joined #ste||ar
mbremer has joined #ste||ar
<github>
[hpx] sithhell force-pushed fix_thread_overheads from bc74956 to 96142a9: https://git.io/vNByp
<github>
hpx/fix_thread_overheads 96142a9 Thomas Heller: Don't use boost::intrusive_ptr for thread_id_type...
xxl- has joined #ste||ar
<github>
[hpx] sithhell force-pushed fix_thread_overheads from 96142a9 to 09a6fa1: https://git.io/vNByp
<github>
hpx/fix_thread_overheads 09a6fa1 Thomas Heller: Don't use boost::intrusive_ptr for thread_id_type...
xxl- has quit [Read error: Connection reset by peer]
xxl- has joined #ste||ar
xxl- has quit [Read error: Connection reset by peer]
xxl- has joined #ste||ar
kisaacs has joined #ste||ar
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
<kisaacs>
I'm trying to build hpx on rostam. I've given cmake the boost root, hwloc root, c compiler and cxx compiler (gcc 6.4.0 w/matching boost, default module load hwloc). The cxx11_exception_ptr test fails in linking (it was using -std=c++17). Am I missing something obvious?
<heller_>
did you try with a complet new build directory?
<heller_>
what's the actual error?
<hkaiser>
kisaacs: rostam has a finicky setup where modules not always do what you think they should
<hkaiser>
kisaacs: I use this to build hpx: module load clang/5.0.0 binutils/2.28 boost/1.65.1-clang5.0.0-debug cmake/3.9.0
<kisaacs>
CMakeFiles/cmTC_ebcc0.dir/cxx11_std_exception_ptr.cpp.o: In function `main':
<kisaacs>
cxx11_std_exception_ptr.cpp:(.text+0x13): undefined reference to `std::__exception_ptr::exception_ptr::exception_ptr()'
<hkaiser>
kisaacs: rostam has an old version of boost installed in the system, cmake sometimes refuses to use the boost version you point it to which them lets it compile things against the specified boost version but links agains the version installed in the system
<kisaacs>
(repeat similar errors to the last line)
<heller_>
ok, that sounds like it couldn't find its standard library, for some reason or another
<hkaiser>
heller_: I agree
<heller_>
let me check...
<kisaacs>
I got a similar set of errors a month ago when I tried building something in std=c++11 when one of the libs it was using was not compiled with std=c++11
<kisaacs>
(not hpx)
<heller_>
yeah, they introduced different ABIs recently
<heller_>
a while back actually
<heller_>
I cna't really reproduce the problem :/
<kisaacs>
the clang version seems to be chugging along at least
<kisaacs>
for ref, the other setup was (module load gcc/6.4.0 boost/1.63.0-gcc6.4.0 hwloc cmake cmake -DBOOST_ROOT=/opt/boost/1.63.0-gcc6.4.0/release -DHWLOC_ROOT=/opt/eb/software/hwloc/1.11.3 -DCMAKE_INSTALL_PREFIX=/home/kisaacs/opt -DCMAKE_C_COMPILER=/opt/mn/gcc/6.4.0/bin/gcc -DCMAKE_CXX_COMPILER=/opt/mn/gcc/6.4.0/bin/gcc ..) ...I forgot that I shouldn't be using an install prefix because I'm not going to make
<kisaacs>
install
parsa has quit [Quit: Zzzzzzzzzzzz]
eschnett has joined #ste||ar
mcopik has quit [Ping timeout: 256 seconds]
<heller_>
kisaacs: is there any progress on ravel, btw? Or a similar tool to look at the APEX otf2 traces?
<heller_>
which is not vampir
kisaacs has quit [Ping timeout: 248 seconds]
<heller_>
K-ballo: do you happen to know the rationale why less etc. is undefined for operator versions, but not for the functor? Finding reasoning is beyond me, especially since it would make sense to have a operator< and operator> (etc) available at all
<K-ballo>
heller_: segmented architectures
<heller_>
ok, but why have the one being defined, and the other undefined?
<heller_>
makes no sense
<K-ballo>
relops on pointers are valid as long as they point to the same object, because an object must be all contained within a segment, but objects in different segments are unordered
<heller_>
ok, I am fine with that
<K-ballo>
std::less<T*> is the awkward way ancient WG21 found to do a total order on pointers, one that considers both segment and offset
<heller_>
are there still relevant segmented memory machines? (modulos the x86 boot sequence)
parsa has joined #ste||ar
<K-ballo>
relevant to whom?
<heller_>
as in, still in use
<K-ballo>
unlikely
<hkaiser>
parsa[w]: what's wrong there?
<heller_>
sounds like something that should be deprecated...
<parsa[w]>
hkaiser: message "Unknown compiler version - please run the configure tests and report the results" everywhere
<hkaiser>
parsa[w]: yah, ignore that - the compiler is newer than the boost version
<parsa[w]>
:))))
<K-ballo>
deprecation keeps being suggested each time the topic is touched
<K-ballo>
noone ever does the homework for it
gedaj has joined #ste||ar
<heller_>
I see
<K-ballo>
gets to sit in the corner, right next to vector<bool> and the others
kisaacs has joined #ste||ar
<heller_>
public reminder that noone is perfect, i guess ;)
xxl- has quit [Ping timeout: 248 seconds]
xxl- has joined #ste||ar
rod_t has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rod_t has joined #ste||ar
eschnett has quit [Quit: eschnett]
<kisaacs>
I am trying to build Phylanx using the blaze/3.2 module and pointing cmake to the blaze_DIR of /opt/mn/blaze/3.2/share/blaze/cmake but at the end of configuration, I get an error in src/CMakeLists.txt that "Imported target "blaze::blaze"" includes non-existent path "/opt/mn/blaze/3.2/install" in its INTERFACE_INCLUDE_DIRECTORIES." Should I be building my own blaze?
<hkaiser>
parsa[w]: can you answer that question? ^^
<hkaiser>
kisaacs: I never tried building phylanx on rostam :/ but I was told the installed version should work
<hkaiser>
otoh, if its V3.2 it might be too old
<hkaiser>
K-ballo: LSU is closed today so we will not be able to get it updated
<parsa[w]>
kisaacs: why do you need to install phylanx?
<K-ballo>
..?
<hkaiser>
K-ballo: sorry ;-)
<hkaiser>
kisaacs: this was for you ^^
<hkaiser>
parsa[w]: why shouldn't she build phylanx on rostam?
Smasher has quit [Remote host closed the connection]
<parsa[w]>
building is fine, installing isn't necessary
<hkaiser>
well, sure
jaafar has joined #ste||ar
<parsa[w]>
3.2 is old, but as far as i know alireza and bibek use 3.2 on rostam
<parsa[w]>
3.2 doesn't have your hpx integration stuff in it
<parsa[w]>
stuff: hpx thread support
<hkaiser>
right, that's what I meant
<kisaacs>
ah okay, so I should build a newer version of Blaze. (I want to build phylanx so I can generate my own expression tree data for the vis)
<kisaacs>
(I planned to make, but not make install.)
<kisaacs>
The install stuff is just what happened at the end of the cmake command
kisaacs_ has joined #ste||ar
kisaacs has quit [Ping timeout: 256 seconds]
kisaacs_ is now known as kisaacs
xxl- has quit [Read error: Connection reset by peer]
xxl- has joined #ste||ar
<hkaiser>
kisaacs: for playing around the old blaze should be just fine