K-ballo 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 has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
diehlpk_work has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<K-ballo>
the boost.bimap removal change has a strong effect on debug bloat
<K-ballo>
either <unordered_map> is considerably heavier than <boost/bimap.hpp> (unlikely, since it pulls intrusive, mpl, concept_check, etc)
<K-ballo>
or <boost/bimap.hpp> is already present everywhere already, so that one removal had no effect
<K-ballo>
but <unordered_map> was already being pulled by action factory... what's going on
<K-ballo>
a single unordered_map instantiation shouldn't be that bad, even if multiplied by the total number of TUs
<hkaiser>
I think we use bimap somewhere else as well, not sure if you have removed it everywhere
<K-ballo>
I don't see any other
<hkaiser>
ok
<K-ballo>
no, it's definitely the instantiation
<K-ballo>
somehow that single instantiation brings ~120mb of extra debug stuff
<gonidelis[m]>
Is the executors proposal accepted yet?
<gonidelis[m]>
K-ballo: i didn't even know about this goldmine
<gonidelis[m]>
K-ballo: so official answer is no, but do you think it's going to be accepted for c++23? I only know that we want to stray away from it (??)
<K-ballo>
I don't know
<gonidelis[m]>
what's the tendency?
<gonidelis[m]>
i mean you are in those meetings, aren't you?
<K-ballo>
no, haven't been in any wg21 business for about a year, not even mailing lists
<gonidelis[m]>
hm ok
<gonidelis[m]>
do you like executors though? or you don't even mind ?
<hkaiser>
gonidelis[m]: afaik, the plan is to get it in by 2023
<K-ballo>
I'm not familiar with whatever the current iteration of the executors proposal is
<K-ballo>
I stopped following executors progress after the first few years
<gonidelis[m]>
hkaiser: i think that HPX's position though, is that we don't give special attention to them anymore, right?
<K-ballo>
I like the _idea_ of executors, sure
<gonidelis[m]>
hkaiser: we do support them, but....
<gonidelis[m]>
K-ballo: don't get me wrong but I roote for whatever gets us C-ishier and in a lower level of control. I know I am not supposed to say that...
<gonidelis[m]>
root^
<hkaiser>
gonidelis[m]: why, we are in the process of implementing p0443r13, the ones we already have for years are from p0443r3 or so
<K-ballo>
executors happen to be about lower level of control
<gonidelis[m]>
hkaiser: hm ok... i might have been of the wrong impression. i thought i was not supposed to use them in hPX ;P
<gonidelis[m]>
K-ballo: that's why i like them and i aggree with you
<gonidelis[m]>
K-ballo: then again people say c++ is all about higher level abstractions. i am too young to talk about "the vision" though...
<K-ballo>
I wouldn't caracterize them as C-ish at all
<K-ballo>
abstraction and control aren't necessarily opposites
<gonidelis[m]>
well C give you better control over your hardware, isn't it?
<K-ballo>
not really, no
<gonidelis[m]>
it has pthreads.... and sys calls
<gonidelis[m]>
it heaviliy utilizes ^^
<gonidelis[m]>
c++ has them, too
<K-ballo>
I am not following
<gonidelis[m]>
isn't C more low level than cpp?
<K-ballo>
no, not really
<K-ballo>
anything lower level you can do in C you can do in C++ too, so it definitely isn't _more_ lower level
<gonidelis[m]>
what's any advantage of C over cpp then
<gonidelis[m]>
?
<K-ballo>
exactly :)
<gonidelis[m]>
lol
<gonidelis[m]>
K-ballo: roast
<K-ballo>
now seriously.. less chances of bloat, as everything needs to be done manually
<K-ballo>
considerably easier to learn, since it has so few features, language and library
<gonidelis[m]>
K-ballo: doesn't that make it faster? or closer to the OS? or sth...
<K-ballo>
dead stable, de-facto ABI
<gonidelis[m]>
C is easier to learn than C++ ??????? lol
<K-ballo>
yes
<K-ballo>
imagine learning C++ but not having to learn classes, inheritance, overloading resolution, templates, ...
<K-ballo>
..constexpr, noexcept, the entire std::
<K-ballo>
no modules, no filesystem, no algorithms
<K-ballo>
no containers
<K-ballo>
it's orders of magnitude easier to learn
<gonidelis[m]>
but there are segfaults
<gonidelis[m]>
and pthreads?
<K-ballo>
...yes?
<K-ballo>
there are segfaults in C++ too, and pthreads
<gonidelis[m]>
execvp's, malloc's, JUST MEMORY MANAGEMENT IS A BEAST ON ITS ON
<gonidelis[m]>
<K-ballo "there are segfaults in C++ too, "> C sounds pathetic then
<K-ballo>
you think those don't exist in C++?
<gonidelis[m]>
i don't know if they are heavily used
<K-ballo>
there's very few things C has and C++ hasn't
<K-ballo>
restrict/atomic qualifiers (not good design choices), VLAs (now optional in C11 since not very good either), flexible array members (pretty cool, hard to replicate in C++), generic macros (no need when having real templates)
<gonidelis[m]>
flexible array members?
<K-ballo>
C even cherry-picks changes back from C++.. like bool, and const, and attributes