<hkaiser>
diehlpk: write it as (void const*)(&cuda_multipole_interactions_kernel_rho) for now
<diehlpk>
hkaiser, Thanks, octo compiled
<diehlpk>
Now I am running the benchmarks
hkaiser has quit [Quit: bye]
<Yorlik>
Does hpx::this_thread::sleep_for(...) also yield?
diehlpk has quit [Ping timeout: 252 seconds]
<heller>
Yorlik: sure
<Yorlik>
So a sleep can make a task lose control ...
<Yorlik>
Thats a tricky side effect
<Yorlik>
Does the sleep need task time to go away or is it strictly using the real time clock? Like hpx::this_thread::sleep_for(10s) - would it require the task to burn 10 seconds while scheduled?
<heller>
No
<heller>
It gets suspended, and woken up after 10 seconds
<heller>
So yes, it's using a clock in the background
<Yorlik>
Good :)
Yorlik has quit [Read error: No route to host]
Yorlik has joined #ste||ar
nikunj has quit [Remote host closed the connection]
rori has joined #ste||ar
hkaiser has joined #ste||ar
daissgr_work has quit [Read error: Connection reset by peer]
daissgr_work has joined #ste||ar
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
hkaiser has joined #ste||ar
daissgr has joined #ste||ar
eschnett has joined #ste||ar
quaz0r has quit [Quit: bbl]
aserio has quit [Ping timeout: 250 seconds]
aserio has joined #ste||ar
hkaiser has quit [Quit: bye]
eschnett has quit [Quit: eschnett]
aserio has quit [Ping timeout: 272 seconds]
rori has quit [Quit: byr]
aserio has joined #ste||ar
hkaiser has joined #ste||ar
<diehlpk_work>
simbergm, hkaiser parsa GSoD is submitted and the student should start with the community bonding phase next month
<simbergm>
diehlpk_work: thanks! let's hope we get what we asked for
<parsa>
?
<diehlpk_work>
I think we should meet with her in person and help the student to setup irc
<diehlpk_work>
and parsa should meet with the student once a week at the beginning
eschnett has joined #ste||ar
<Yorlik>
Is there a way to have a "sleep at least", like a timed yield with no guaranteed/enforced rescheduling ?
<hkaiser>
Yorlik: what should that do?
<Yorlik>
wait and then give the scheduler leeway to decide when to schedule
<hkaiser>
sleep_for just guarantees that the task doesn't come back earlier than specified already
<Yorlik>
Or is that happening anyways?
<Yorlik>
OK - then it's already implemented like that
<Yorlik>
I realize one particular difficulty this app lockup I had (seems fixed now, still testing):
<Yorlik>
Since the output is totally async I never know where I am in the app
<Yorlik>
Is there a built-in way to have sync output?
<hkaiser>
use std::flush
<hkaiser>
that should do the trick
<Yorlik>
Does that also work when using printf?
<Yorlik>
like fater
<Yorlik>
after
<hkaiser>
no
<Yorlik>
I prefer printf for the built in formatting
<hkaiser>
there you use fflush
<Yorlik>
ok - seems I'll have top use fmt
<Yorlik>
Ah ..
<Yorlik>
like fflush(); ?
<hkaiser>
you shouldn't rely on kernel io
<hkaiser>
like std::cout or printf
<Yorlik>
What would you recommend top use?
<Yorlik>
Write my own logger task?
<hkaiser>
hpx::cout and hpx::util::format or fmt{}
<Yorlik>
oh - didn't know hpx has fmt
<Yorlik>
I'll look that up
<hkaiser>
or move the output code into a lambda that you run through hpx::threads::run_as_os_thread(f)
<hkaiser>
the important part is that you don't suspend any hpx threads/tasks with a kernel mutex
<Yorlik>
BTW: Indeed it was a race
<Yorlik>
Thomas had the glorious idea to test with thread=1 and it all worked
<Yorlik>
Seems I have to learn how to trace races :)
<Yorlik>
the async output was a major hurdle debugging this
<hkaiser>
it didn't even work with hpx:threads=1 for me
<Yorlik>
I probably already had another version
<hkaiser>
Yorlik: but yah, it's easy to always suspect HPX is broken... you would never claimed that if your version hanged using std::thread
<Yorlik>
he race was, that under certain conditions a worker couzld get a limit of -1 (FFFFFFFF...) and create an insanely huge batch and never return from it
<Yorlik>
Yes
<Yorlik>
std::thread worked perfectly
aserio has quit [Ping timeout: 250 seconds]
<Yorlik>
Now I need to find a good way to manage yields and not add a ton of overhead, like it is right now
<Yorlik>
Controlling granularity efficiently is a thing I have to learn now.
<hkaiser>
Yorlik: I'd suggest creating smaller tasks instead of yielding
<Yorlik>
They are already pretty short
<hkaiser>
how short?
<Yorlik>
With OS threads sub microseconds
<Yorlik>
Only in this specific test case ofc
<hkaiser>
that's way too short for std::thread, even for hpx::threads