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
aalekhn has quit [Quit: Connection closed for inactivity]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Client Quit]
diehlpk has joined #ste||ar
diehlpk has quit [Client Quit]
diehlpk has joined #ste||ar
hkaiser has quit [Quit: Bye!]
K-ballo has quit [Quit: K-ballo]
diehlpk has left #ste||ar [#ste||ar]
Yorlik has joined #ste||ar
Yorlik has quit [Read error: Connection reset by peer]
sestro[m] has joined #ste||ar
<sestro[m]> Hello, just started giving HPX 1.8.0 a try. Are there any known issues regarding the MPI parcelport and APEX? Some code that worked fine with 1.7.1 segfaults now in `MPI_Isend` in `apex_mpi.cpp`. Didn't dig into the details so far but it seems to happens during the shutdown of the runtime.
<ms[m]> sestro: I'm not aware of anything, but you can try `-DHPX_WITH_APEX_TAG=2.4.1` to use the version of apex that was default in hpx 1.7.1 to check if the problem is in apex or hpx (likely the former since I don't think the apex integration has had any changes recently)
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
<sestro[m]> <ms[m]> "sestro: I'm not aware of..." <- Thanks for the idea, indeed it seems to be related to a change in APEX, I don't encounter any issues with the 2.4.1.
<ms[m]> sestro: all right, in that case kevin might appreciate a report on https://github.com/UO-OACISS/apex/issues
<sestro[m]> ms[m]: Yep, just ran some more tests to be sure.
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
Yorlik has joined #ste||ar
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 272 seconds]
<sestro[m]> While looking at https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/partitioned_vector_spmd_foreach.cpp I'm a bit confused about the `partitioned_vector_view` defined in this example. This has nothing to do with with the idea of `hpx::partitioned_vector_view`, i.e., the 'SPMD multidimensional views' described in the documentation, does it?
<hkaiser> hmmm, I thought it did
<hkaiser> sorry, don't remember the details of this
<john98zakaria[m]> <sestro[m]> "While looking at https://github..." <- I can't say whether it does or not... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e333c80b291f2dde5cf3a9494c33ee5d646fc69d)
<hkaiser> john98zakaria[m]: a segmented vector could do that as well, it would even work if v[i] is not local, but it would be utterly inefficient
<hkaiser> but partitioned_vector is ne-dimensional, the co_array stuff is multi-dimensional (IIRC)
<john98zakaria[m]> I meant it doesn't have the fancy (i,j,k) Index as the other coarray
<john98zakaria[m]> hkaiser: How many items are loaded when accessing an element out of your locality?
<john98zakaria[m]> Do we have "cachelines" in distributed containers?
<john98zakaria[m]> * How many items are loaded when accessing an element out of your locality?
<john98zakaria[m]> Do we have "cachelines" in distributed containers?
<john98zakaria[m]> Can we load chucks in one call?
<hkaiser> just one
<hkaiser> john98zakaria[m]: loading chunks is tricky as there is no (easy) way to ensure data consistency
<hkaiser> if one locality has loaded the data (and has cached a chunk), how would you know that the cached values are stale?
<john98zakaria[m]> hkaiser: A proxy object could mark the line as "dirty" but i see the problems in that.
<john98zakaria[m]> * A proxy object could mark the line as "dirty" but i see the problems in that. And the amount of work needed to be done would make the structure useless
<hkaiser> john98zakaria[m]: you'd need some distributed consistency algorithm, not sure if that's worth it - writing code in an SPMD fashion sounds better to me
<hkaiser> that would try to access the data locally only - if remote access is required, I'd rather move the work to the data
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 250 seconds]
<gonidelis[m]> satacker: still having trouble with `tag_invoke`?