hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<gonidelis[m]> hkaiser: do you aggree with this? https://twitter.com/Cor3ntin/status/1464536453791338496
<hkaiser> gonidelis[m]: sure, but how do you know it's safe to memcpy?
<gonidelis[m]> hkaiser: so how could memcpy be not safe?
<gonidelis[m]> for example when you need to retain the reference to the object, right?
<K-ballo> self referential means it points, directly or indirectly, to itself
<K-ballo> struct S { S* self = this; };
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
<hkaiser> gonidelis[m]: I guess that you could apply this optimization for any trivially copyable types
<hkaiser> also, I would even assume that the standard libraries already apply this optimization
<hkaiser> for instance, our hpx::copy and hpx::move algorithms do that
<gonidelis[m]> but i thought copying was deteriorating the performance
<gonidelis[m]> to put it in prespective if I can move instead of copying, I would
<hkaiser> gonidelis[m]: move is copy with a twist, remember
<gonidelis[m]> huh... yeah
<gonidelis[m]> it's still more efficient though, no?
<hkaiser> gonidelis[m]: depends on the type
<gonidelis[m]> true
<hkaiser> for trivially copyable types, move and copy are the same, otherwise they wouldn't be trivially copyable
<K-ballo> corentin is probably refering to relocatable types
<K-ballo> for which a move is a memcpy followed by NOT calling any destructor
K-ballo has quit [Ping timeout: 245 seconds]
K-ballo has joined #ste||ar
<hkaiser> K-ballo: so his point is not to just use memcpy instead of explicit repeated moves, but to avoid calling the destructors afterwards
<K-ballo> something like that
<K-ballo> the memcpy becomes viable only if not calling the destructor
<hkaiser> well, just using memcpy instead of repeated moves already gives some speedup
<K-ballo> think std::vector<std::string>
<hkaiser> makes sense
<K-ballo> you can memcpy all the strings to their new positions during a resizing operation, as long as you don't destroy the moved-from ones
<K-ballo> they just "magically cease to exist"
<K-ballo> that said, std::string is perhaps not the best example since in some implementations it is self referential
hkaiser has quit [Quit: Bye!]