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
Yorlik__ has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
<satacker[m]>
Only over futures, vanilla code is still a faster one by 2x over coroutines
<hkaiser_>
satacker[m]: co_await on futures doesn't give any perf improvements, just better usability
<satacker[m]>
Ohh, the compiler glues the mutex for awaitables?
<hkaiser_>
not on futures
<hkaiser_>
co_await for our futures is just a syntactic wrapper for future::then()
<satacker[m]>
I think that coroutines should be faster than the futures, why--> I don't think any mutex is necessary here, the only overhead could be the dynamic allocation for coroutine
<satacker[m]>
I am not sure how futures handle sync on the inside, but there should be some mechanism that has significant overhead for mutex...
<satacker[m]>
why is this wrong (or it's not?)?
<hkaiser_>
coroutines + senders/receivers will be faster compared to futures
<hkaiser_>
what I meant was that co_await future<>(); is not faster than future::then()
<satacker[m]>
Right, so the results of the fun experiment do make some sense although only `just` sender is used which isn't the best showcase
<hkaiser_>
yes, absolutely
<satacker[m]>
* Right, so the results of the fun experiment do make some sense
tufei_ has joined #ste||ar
tufei has quit [Ping timeout: 258 seconds]
K-ballo has quit [*.net *.split]
K-ballo has joined #ste||ar
diehlpk_work has joined #ste||ar
hkaiser_ has quit [Quit: Bye!]
hkaiser has joined #ste||ar
<pansysk75[m]>
Why are we still using futures then? :P