bita_ has quit [Read error: Connection reset by peer]
akheir has quit [Quit: Leaving]
hkaiser has quit [Quit: bye]
nanmiao11 has quit [Remote host closed the connection]
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
Yorlik has joined #ste||ar
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
<gonidelis[m]>
hkaiser: I have a bunch of updates on #4855 if you wanna check... I am working on the fixed right now
<gonidelis[m]>
fixes*
<gonidelis[m]>
Any ideas on how to make this `get<>` work with `in_out_result` types? Actually I don't even know where its implementation lies (in order to adapt it maybe)...
hkaiser has joined #ste||ar
<gonidelis[m]>
hkaiser: yt?
<hkaiser>
gonidelis[m]: here
<hkaiser>
g'morning
<gonidelis[m]>
Goodmorning :D ! I have a bunch of updates on #4855 if you wanna check... I am working on the fixes
<gonidelis[m]>
but it seems like I am stuck
<hkaiser>
ok, will look
<hkaiser>
stuck?
<hkaiser>
gonidelis[m]: why are you stuck?
<gonidelis[m]>
ok I don't know what to do with these cases
<hkaiser>
instead of writing get<0>(result) just write result.in
<hkaiser>
you said that 'result' is of type in_out_result - which is a normal struct with two public members: in' and 'out'
<hkaiser>
why not directly access them?
<K-ballo>
these types exist to avoid the 0/1 meaningless mapping
<gonidelis[m]>
::facepalm:: ..... god when I dig into sth too much I just forget the trivial stuff!
<gonidelis[m]>
what is the purpose of f.get() though?
<hkaiser>
'f' is a future, f.get() asks for its value
<gonidelis[m]>
so it should not be a problem for the future to be of type `in_out_res`...
<hkaiser>
gonidelis[m]: are you aware of 'future's?
<gonidelis[m]>
right?
<gonidelis[m]>
hkaiser: yes! done my homework on the preseason ;)
<hkaiser>
no, no problem: auto result = f.get(); result.in will work...
<hkaiser>
sorry for asking
<gonidelis[m]>
hkaiser: plz don't apologize
<gonidelis[m]>
Actually these hpx core features are very very interesting and I have no idea how you guys implemented them. It's not like the algorithms, where we write stuff according to standard. After reaching the top of the algorithms mountain, my next goal will be to study the whole HPX parallelization machinery
<gonidelis[m]>
All errors have been resolved!!! hkaiser Thank you so so much!
<hkaiser>
gonidelis[m]: futures are standard as well ;-)
<hkaiser>
gonidelis[m]: also, do you want to meet today?
<gonidelis[m]>
hkaiser: hmm didn't know that...
<gonidelis[m]>
hkaiser: yeah for sure
<gonidelis[m]>
it's the end of the 2nd. let's celabrate!
<gonidelis[m]>
ok so just like we said before: The parallelization is already there, in std C++. We just provide a more dedicated and more refined version of it?
<gonidelis[m]>
hkaiser:
<hkaiser>
yes
<hkaiser>
additional features based on ongoing standardization discussions
<hkaiser>
also, everything on top of a very lightweight threading implementation
<hkaiser>
for instance, our future's API is based on wg21.link/p0159
<hkaiser>
sched_getaffinity(0, ...) gives you the affinity of the calling thread
<weilewei>
They use shift here, not sure what's the point
<hkaiser>
that's to assign unique cores to each thread
<weilewei>
hhh, and they identified 4 "cores" for one physical core
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
<mdiers[m]>
<jbjnr "mdiers: I doubt anyone has bothe"> the 19er has also installed a clang that is used internally on the intel. but it messed up everything for me, ...
<mdiers[m]>
<ms[m] "Not 19, but we do test prs with "> yes, the 18 still works for me