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
hkaiser has quit [Quit: Bye!]
K-ballo has quit [Quit: K-ballo]
hkaiser has joined #ste||ar
hkaiser has quit [Quit: Bye!]
diehlpk_work has quit [Remote host closed the connection]
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 268 seconds]
Yorlik has joined #ste||ar
Yorlik has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 268 seconds]
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 268 seconds]
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 268 seconds]
diehlpk has joined #ste||ar
diehlpk_work has joined #ste||ar
<jedi18[m]> <zao> "jedi18: There's several ones..." <- I should probably create a PR to change the tests to use Mersenne Twisters then
<hkaiser> jedi18[m]: many tests already do that
<gonidelis[m]> jedi18: hkaiser please excuse my absence today. need to prepare for the taskbench meeting
<diehlpk_work> ms[m], Are you available?
<ms[m]> diehlpk_work: yeah, shortly
<ms[m]> what's up?
<diehlpk_work> Some question about the nvcc_wrapper
<diehlpk_work> It seems that the host compiler is set to gcc as default or?
<diehlpk_work> On Cray it should be the CC
<diehlpk_work> Can we might use $CXX instead to take the correct compiler
<diehlpk_work> Or I am doing sth wrong?
<ms[m]> diehlpk_work: yeah, it's g++ by default
<ms[m]> which on cray will be almost the same as CC
<ms[m]> but won't give all the mpi-linking-for-free as CC gives
<ms[m]> but you can set NVCC_WRAPPER_DEFAULT_COMPILER
<diehlpk_work> OK
<diehlpk_work> That was missing
<ms[m]> hkaiser: btw, was there an executors meeting/did you attend?
<hkaiser> ms[m]: I attended, yes
<hkaiser> no news
<ms[m]> hkaiser: no news is good news
<ms[m]> what was the topic?
<hkaiser> discussing what to ask during the upcoming super-telecon
<ms[m]> hkaiser: makes sense... will you have time to attend (parts of) it?
<hkaiser> ms[m]: I will try to, yes - still waiting for Bryce to send the invitation
<ms[m]> hkaiser: just forwarded the details to you, it was on the lewg and sg1 lists
<hkaiser> ahh, thanks!
<hkaiser> jedi18[m]: see pm, pls
<hkaiser> ms[m]: have not received the invitation yet :/
diehlpk has quit [Quit: Leaving.]
ericniebler[m] has joined #ste||ar
<hkaiser> ms[m]: also, do you have a benchmark I could use for the fork_join_executor?
<ericniebler[m]> Hi HPX people! I understand that standard executors (P2300, sender/receiver) are a part of the plan for the future of HPX. Just wanted to give a heads up that P2300 will be the subject of an extended design review session in Library Evolution (LEWG) on Monday and Tuesday. It would be awesome if there were HPX reps on the telecons who would be willing to speak to the HPX field experience with sender/receiver.
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 268 seconds]
<ms[m]> ericniebler: hey, I (mikael) am planning on joining the supertelecon, at least as much as I can given the time difference
<ms[m]> do you already know the schedule for the individual sessions? any that we should definitely show up for?
<ericniebler[m]> The meeting is in 4 parts over 2 two days. I'm not sure what timezone you're in. These times are in UTC.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/337c148f5975dbca1207fb6159120c180c068cda)
<hkaiser> ericniebler[m]: I'm planning to join at least partially, so an agenda might help
<ms[m]> ericniebler: I'll definitely be there for the first sessions of the day, hopefully at least listening in on the second ones (I'm in CET)
<ericniebler[m]> I'll be missing the earlier sessions on both days myself. I'll speak to Michal D. who will present in my absence. I'll coordinate with him, but I expect before we get into detailed design review, we'll go over the new bits in R3, including the expanded field experience section. It would be especially good to have HPX people there t
<ericniebler[m]> s/t/then/
<ms[m]> sounds good
<gonidelis[m]> <ericniebler[m]> "Hi HPX people! I understand that..." <- i see you find your way to our secret IRC cave
<ms[m]> hkaiser: what sort of benchmark are you looking for? I've mostly tested it with stream, it's also the only benchmark that we have that uses it
<hkaiser> ok, I modified the foreach_scaling_test now
<hkaiser> that works well enough - I want to have a closer look at the executor
<hkaiser> ms[m]: btw, we see occasional hangs when using the fork-join executor, is that something you have seen in the past?
<ms[m]> no, but it's not very extensively tested, so I wouldn't be surprised if there are more lurking bugs
<ms[m]> c.f. gonidelis' test case ;)
<ms[m]> if you have another one let me know
<ms[m]> they're typically quite straightforward to debug
<hkaiser> ms[m]: nothing reproducible
<hkaiser> *reliably reproducible*
<ms[m]> that's all right, bash has a while loop
<ms[m]> even if it just hangs occasionally, do post it anyways
<ms[m]> or gonidelis
<ms[m]> issue please, thought, I'll forget otherwise ;)
<ms[m]> -t
<hkaiser> ok
<gonidelis[m]> ms: it's on a taskbench run where I am running the same hpx forkjoin executor script 100 times and report timings
<gonidelis[m]> it's pretty straightforward to understand but since it's overall dependent on TB i don't think I should raise an issue for htat
<gonidelis[m]> that*
<gonidelis[m]> hkaiser: see pm please
<ms[m]> gonidelis: dependent on tbb how? anyway, you're the best judge but if you think it's an issue with the executor it's worth looking into
<gonidelis[m]> tb = taskbench
<ms[m]> oh... misread :P
<ms[m]> makes more sense
<gonidelis[m]> s/find/found/
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
<hkaiser> gonidelis[m]: see pm, pls
<hkaiser> gonidelis[m]: what command line options do you use?