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/
nanmiao has quit [Quit: Connection closed]
hkaiser has quit [Quit: bye]
<bering[m]>
The bridge error might be due to recent events at freenode.
<ms[m]>
I couldn't reproduce a segfault happening where you said it was happening but I could reproduce a segfault quite regularly
<gnikunj[m]>
ms thanks! Will do
<ms[m]>
in principle I could say that you were using the backend wrongly, but it's subtle enough that it deserves a change
<ms[m]>
it might also explain the performance differences you see
<ms[m]>
I think I told you at some point that the instances are not threadsafe
<ms[m]>
what that means though is that kokkos view construction is not threadsafe, because at the moment they all use the default instance for initialization
<ms[m]>
I think there's been some talk among the kokkos developers that one could initialize a view using a specific instance but it's not there yet
<ms[m]>
if you don't need to zero-initialize whatever views you're using you might also want to do Kokkos::View<...> v(Kokkos::view_alloc(Kokkos::WithoutInitializing, "v"), ...) which skips the initialization (so the backend isn't involved, it only does allocation)