Nikunj__ has quit [Read error: Connection reset by peer]
hkaiser has quit [Quit: bye]
<mdiers[m]>
My application has a performance drop of 30% between 11 Mar and 17 Apr. can you find anything in this range in the hpx tests over the period? Maybe it came in during the revision of the executors? (block_executor<local_priority_queue_attached_executor>,static_chunk_size)
<ms[m]>
mdiers: very possible, but I can't see anything that stands out particularly (our performance tests aren't very comprehensive either)
<ms[m]>
one question, are you explicitly using block_executor<local_priority_queue_attached_executor> or are you leaving the executor as the default (the default is not local_priority_...)
<ms[m]>
?
<mdiers[m]>
ms: thanks for the hint. i will have a look now, i actually use the default. at some point i had a problem with the policy, and had explicitly specified the default. i will adapt it.
<mdiers[m]>
ms: on 11 Mar, the local_priority_queue_attached_executor was the default of the block_executor.
<ms[m]>
mdiers: right, it changed in the executors cleanup pr
<ms[m]>
so it's possible that I made the old default slower, but the new default hopefully faster...
<ms[m]>
in any case, if you can try the new default (restricted_thread_pool_executor) that'd be great
<mdiers[m]>
ms: I'm already on it
<ms[m]>
thanks!
<mdiers[m]>
ms: i test on a single-numa system. on the quad-numa-system the new version now scales, but cannot make a direct performance comparison.
<mdiers[m]>
<ms[m] "in any case, if you can try the "> 1% difference between block_executor<local_priority_queue_attached_executor> and hpx::compute::host::block_executor<hpx::parallel::execution::restricted_thread_pool_executor>
<mdiers[m]>
the same with a direct restricted_thread_pool_executor
hkaiser has joined #ste||ar
Nikunj__ has joined #ste||ar
Hashmi has joined #ste||ar
<ms[m]>
mdiers: same bad performance or same good?
mcopik has joined #ste||ar
mcopik has quit [Client Quit]
<ms[m]>
hkaiser: no sleep, eh? :/
<hkaiser>
ms[m]: yah :/
<ms[m]>
we need more boring issues for you to take care of ("type: boring" or "type: makes hartmut fall asleep")
<hkaiser>
lol
<mdiers[m]>
ms: ahh i'm going crazy: i'm rowing back, it's probably only my special case where i use the gpus with opencl.
Nikunj__ has quit [Read error: Connection reset by peer]
<mdiers[m]>
ms: so, have now the test once again cleanly one after another. whether with or without opencl, I get a performance loss of now 20%.
<mdiers[m]>
* My application has a performance drop of 20% between 11 Mar and 17 Apr. can you find anything in this range in the hpx tests over the period? Maybe it came in during the revision of the executors? (block_executor<local_priority_queue_attached_executor>,static_chunk_size)
Hashmi has quit [Quit: Connection closed for inactivity]
Nikunj__ has joined #ste||ar
<mdiers[m]>
ms: will continue tomorrow morning
nikunj97 has joined #ste||ar
Nikunj__ has quit [Ping timeout: 244 seconds]
nikunj has joined #ste||ar
nikunj97 has quit [Ping timeout: 246 seconds]
nikunj97 has joined #ste||ar
nikunj has quit [Ping timeout: 240 seconds]
akheir has joined #ste||ar
nan11 has joined #ste||ar
weilewei has joined #ste||ar
rtohid has joined #ste||ar
nikunj97 has quit [Read error: Connection reset by peer]
<weilewei>
hkaiser does hpx mpi future need mpi when compiling HPX? If I do not provide mpi module on my hpx build script, then it says "MPI could not be found but was requested by your configuration, please specify MPI_ROOT to point to the root of your MPI installation"
nikunj has joined #ste||ar
<weilewei>
I set -DHPX_WITH_NETWORKING=OFF -DHPX_WITH_PARCELPORT_MPI=OFF
<hkaiser>
weilewei: yes, it needs mpi
<weilewei>
If I provide mpi module in the script, then hpx will be built with networking:on, however, I don't want this way. because when I run my application, it will warns mpi is started twice
<weilewei>
hkaiser but in the earlier version, hpx mpi future does not require mpi when building hpx, that's what I remembered
<hkaiser>
weilewei: it always required mpi, iirc
<weilewei>
hkaiser then how should I avoid the error that mpi is started twice? because the main
<hkaiser>
weilewei: no, if you disable networking, then networking will be off
<hkaiser>
you see an error? you didn't say so
<weilewei>
hkaiser right, I see the error "mpi is started twice" even when I disabled networking in hpx
<hkaiser>
what error do you see? can I see the full output, pls?
<hkaiser>
weilewei: pls update from the branch, I fixied this 10 minutes ago
<weilewei>
hkaiser ok, let me try it again
<weilewei>
Another questions is about threaded ring G algorithm, I suspect MPI_Isend/recv might not be able to aware of threads locally. I am thinking to achieve the following scenarios: in multithreaded ringG, local thread sends data to corresponding thread in right-hand side neighbor, such that we have implicitly constructed multiple MPI communicator. For
<weilewei>
example, we have two ranks, and each rank has 2 threads. Thread 0 from rank 0 issues MPI_Isend with tag associated with send_tag (thread_id+1 = 1) to thread 0 from rank 0 that has recv_tag (thread_id+1=1). However, this threaded ring G algorithm just breaks. See the sample program:
<weilewei>
or Cuda failure /__SMPI_build_dir_______________________________________/ibmsrc/pami/ibm-pami/buildtools/pami_build_port/../pami/components/devices/ibvdevice/CudaIPCPool.h:205: 'invalid resource handle'
<weilewei>
from my experience, it seems the send and recv ends are not matched together
shahrzad has quit [Ping timeout: 244 seconds]
bita_ has quit [Quit: Leaving]
karame_ has quit [Remote host closed the connection]
karame_ has joined #ste||ar
<hkaiser>
weilewei: is your MPI implementation thread-safe? is it initialized using MPI_Init_thread?
shahrzad has joined #ste||ar
<Yorlik>
Can we mabe get rid of this annoying warning? include\hpx\threading\jthread.hpp(258): warning C4267: 'return': conversion from 'size_t' to 'unsigned int', possible loss of data