nanmiao11 has quit [Remote host closed the connection]
nanmiao11 has joined #ste||ar
Yorlik has quit [Ping timeout: 240 seconds]
<weilewei>
With mpirun, how do I limit number of cores that run application? For example, if I have 56 cores, but I only want to run 7 cores on that machine?
<weilewei>
Or how to limit that actually
<hkaiser>
weilewei: with hpx?
<hkaiser>
generally you should be able to do that through slurm
<weilewei>
hkaiser no, just regular application
<hkaiser>
mpirun should pick it up
<weilewei>
ok, let me explore sbatch
hkaiser_ has joined #ste||ar
hkaiser has quit [Ping timeout: 260 seconds]
hkaiser_ has quit [Quit: bye]
weilewei has quit [Remote host closed the connection]
akheir has quit [Quit: Leaving]
kale[m] has quit [Ping timeout: 265 seconds]
kale[m] has joined #ste||ar
nanmiao11 has quit [Ping timeout: 245 seconds]
<zao>
mpirun deals with the number of processes to spawn, which you can indicate with `-np` if you want a number different from the default or environment.
<zao>
SLURM has knobs for the number of tasks/processes --ntasks (-n) and --cpus-per-task (-c). You would set those accordingly to have configurations like "one task per node with all its cores" or "N tasks per node, one core each" or something inbetween like "7 tasks per node, each with 4 cores".
<zao>
Bah, seems like weilwei went offline :D
<gdaiss[m]>
@hkaiser Should we move the Kokkos meeting to next Thursday (or another day that week) as Mikael is on vacation this week?
hkaiser has joined #ste||ar
<ms[m]>
hkaiser: how was your schedule next week? are you away all week or just at the usual hpx meeting time? I wouldn't be there for the potential meeting today, but should we try to have one tomorrow or next week (if you're around)? also rori_[m] jbjnr gdaiss (we can have the kokkos meeting the same day)
<rori>
👍️
<gdaiss[m]>
<ms[m] "hkaiser: how was your schedule n"> for the kokkos meeting I would prefer next week over tomorrow! My calendar for tomorrow is already completely full!
<hkaiser>
ms[m]: I'm around next week
<hkaiser>
no plans to be away atm
<hkaiser>
ms[m]: should we cancel today's meeting, then?
<ms[m]>
hkaiser: yes, unless you'd like to have it anyway (I don't mind really)
<hkaiser>
ok, I'll cancel it for today, should we paln for next Thursday?
<hkaiser>
ms[m]: ^^
<ms[m]>
thursday works, but not that time
<ms[m]>
another day might be easier
<ms[m]>
sorry :/
<hkaiser>
ok, let's skip it then and reconvene in 2 weeks
<ms[m]>
all right, works too
<ms[m]>
thanks!
<hkaiser>
: np
Yorlik has joined #ste||ar
<gonidelis[m]>
hkaiser: you are on a roll ;p I need to step up my adaptation game
<gnikunj[m]>
hkaiser: I'm seeing a lot of contention with my distributed benchmarks (which I kind of expected)
<hkaiser>
contention? where?
<gnikunj[m]>
the apis work best when I run with 20ms or more worth of grain size
<gnikunj[m]>
per distributed call
<hkaiser>
ahh, including networking?
<hkaiser>
what parcelport?
<gnikunj[m]>
yes
<gnikunj[m]>
tcp
<gnikunj[m]>
should I switch to mpi?
<hkaiser>
try MPI
<hkaiser>
might improve things
<gnikunj[m]>
good idea, let me
<hkaiser>
gnikunj[m]: also, the remote actions work best if local work is overlapping things
<hkaiser>
I wouldn't suggest exposing/measuring pure latencies
<gnikunj[m]>
I see, so I should add some local work on remote invocations
<hkaiser>
or measure just the overhead introduced by replay/replicate compared to non-replay/non-replicate
<hkaiser>
gnikunj[m]: how is qbc working for you?
<gnikunj[m]>
qbc?
<hkaiser>
qbc.loni.org
<gnikunj[m]>
aah I'm able to login now
<gnikunj[m]>
I haven't done any benchmarking there. I'm playing with rostam right now
<hkaiser>
right
diehlpk has joined #ste||ar
diehlpk has joined #ste||ar
diehlpk has quit [Changing host]
<gnikunj[m]>
hkaiser: mpi backend works really nicely. With tcp I was having trouble with lower grain sizes. With mpi I can go as low as 5ms for the grain size.
<hkaiser>
nod, good
diehlpk has quit [Ping timeout: 256 seconds]
diehlpk_work has quit [Ping timeout: 244 seconds]
diehlpk has joined #ste||ar
diehlpk has quit [Changing host]
diehlpk has joined #ste||ar
weilewei has joined #ste||ar
diehlpk_work has joined #ste||ar
<gnikunj[m]>
hkaiser: I've added some local work to the benchmark. This should be a more real world scenario. I'll run a script now to get some results for various configurations. Let's discuss them in tomorrow's call.
<hkaiser>
gnikunj[m]: ok
<zao>
weilewei: 09:28 <zao> mpirun deals with the number of processes to spawn, which you can indicate with `-np` if you want a number different from the default or environment.
<zao>
09:28 <zao> SLURM has knobs for the number of tasks/processes --ntasks (-n) and --cpus-per-task (-c). You would set those accordingly to have configurations like "one task per node with all its cores" or "N tasks per node, one core each" or something inbetween like "7 tasks per node, each with 4 cores".
<weilewei>
zao thanks!
<zao>
The manual page for sbatch isn't that bad, and most HPC sites have some sort of writeup on submit file design.
<gonidelis[m]>
Should this be changed from `result_type()` to `result_type{}` ?
<gonidelis[m]>
that's the case that I am working on
<K-ballo>
I see no `result_type()` in there, only `result_type(args)`
<gonidelis[m]>
should this be `result_type{things_here}`
<gonidelis[m]>
K-ballo: yeah that's what I am talking about
diehlpk has quit [Ping timeout: 244 seconds]
<K-ballo>
ok, `result_type()` is a separate language construct, different rules, different semantics
<K-ballo>
if that result_type is an `in_out_result` it needs to be using braces, yes
<gonidelis[m]>
yeah sure...
<K-ballo>
fwiw, never change a `T()` into a `T{}` unless you know why you are doing it
<gonidelis[m]>
as you can see I have a `using result_type = util::in_in_out_result<FwdIter1B, FwdIter2, FwdIter3>`
<gonidelis[m]>
you mean `T(args)` to `T{args}` or just plain `T()` to `T{}`?
<K-ballo>
plain T(), it's its own language construct distinct from T(args)
<gonidelis[m]>
K-ballo: so it's not `in_out_result`, but rather `in_in_out_result`
<gonidelis[m]>
K-ballo: got it thanks ;)
bita_ has joined #ste||ar
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
<gonidelis[m]>
hkaiser: yt?
<hkaiser>
here
<gonidelis[m]>
https://github.com/STEllAR-GROUP/hpx/pull/4855 I have created the CPO for the plain hpx::transform (not ranges::transform yet). I have updated the status of my repo but the compiler complains for a certain `container_algos` test (where I don't think it should be complaining). I think it's a minor detail in order to reach to a stable version of my code. Anyways, the error is at
<gonidelis[m]>
`tests/unit/container_algorithms/transform_range_binary.cpp:50:27` because I changed `hpx::util::get<0>(result) == std::end(c1)` to `result.in1 == std::end(c1)`...
<gonidelis[m]>
Could you give a tip?
<gonidelis[m]>
hkaiser: ^^
hkaiser has quit [Ping timeout: 244 seconds]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 264 seconds]
hkaiser has joined #ste||ar
<gonidelis[m]>
hkaiser: did you happen to missh my message maybe ?
<hkaiser>
could be
<gonidelis[m]>
https://github.com/STEllAR-GROUP/hpx/pull/4855 I have created the CPO for the plain hpx::transform (not ranges::transform yet). I have updated the status of my repo but the compiler complains for a certain container_algos test (where I don't think it should be complaining). I think it's a minor detail in order to reach to a stable version of my code. Anyways, the error is at
<gonidelis[m]>
tests/unit/container_algorithms/transform_range_binary.cpp:50:27 because I changed hpx::util::get<0>(result) == std::end(c1) to result.in1 == std::end(c1)...
<gonidelis[m]>
Could you give a tip?
<hkaiser>
the compiler error could only be caused by a mismatch between what the algorithm returns and what you believe it returns
diehlpk has joined #ste||ar
diehlpk has quit [Changing host]
diehlpk has joined #ste||ar
<gonidelis[m]>
hpx::parallel::transform returns either an `in_out_result` or an `in_in_out_result`
<nanmiao11>
hkaiser I am not able to join the room. It says the meeting has problem. Have you joined in?
<hkaiser>
nanmiao11: yes
<hkaiser>
it's not a problem if you can't join today, we'll talk about money, mostly
<nanmiao11>
OK.
diehlpk has quit [Ping timeout: 260 seconds]
mcopik has joined #ste||ar
mcopik has quit [Client Quit]
bita_ has quit [Ping timeout: 256 seconds]
<weilewei>
wow, I got accepted to SCinent volunteer again this year
<weilewei>
"virtual" volunteer
<nanmiao11>
Congrats!
<weilewei>
nanmiao11 thanks!
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
<gonidelis[m]>
hkaiser: it would help a lot if you could take a look at my updated PR and leave some comments until our meeting tomorow morning. I wil have extra updates until then...
<hkaiser>
will do later tonight
kale[m] has quit [Read error: Connection reset by peer]