hkaiser changed the topic of #ste||ar to: The topic is '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/
<simbergm>
diehlpk_work: thanks for testing!
Yorlik has quit [Read error: Connection reset by peer]
Yorlik has joined #ste||ar
mdiers_ has quit [Remote host closed the connection]
jaafar has quit [Ping timeout: 260 seconds]
jaafar has joined #ste||ar
<Yorlik>
When doing a calculated hpx::sleep_until to keep frame the time stable I see a delay of 1-2 ms - is that die to the HPX scheduling? And if yes - how could I fix this? I want the final frametime ( work + wait padding ) to be very precise.
<Yorlik>
E.g. my calculation is currently for 60 fps, but instead of 16.66 ms I see 18-19
<Yorlik>
And the work is much much less, ofc - most of the time is padded by sleep.
<Yorlik>
Also my stddev is ~0.2-several ms
<Yorlik>
rolling stats over 60 frames / 1 second
<Yorlik>
The problem is, that a server based physics simulation should have very precise stable frametimes.
<simbergm>
I doubt we have the apis to control that right now
<Yorlik>
OK. So - nothing like precise timed rescheduling?
<simbergm>
in theory we could add an argument to sleep_{for,until} to set the priority when the task is woken up (we even had almost that for yield until not too long ago)
<simbergm>
it would also depend on how precise the underlying boost timer pool is
<simbergm>
we can't be more precise than that
jaafar has quit [Ping timeout: 272 seconds]
<Yorlik>
I think 1-2 ms is too much for time critical stuff.
<simbergm>
but there may be some extra delay on top of that depending on how many tasks are in the queue (the woken up task will be last in the "active" tasks queue)
<Yorlik>
Should be possible to get that below 100 us
<simbergm>
yeah, completely understandable
<simbergm>
it just hasn't been a focus for us, throughput is much more important in hpc
<Yorlik>
Its my main task - the frame update
<Yorlik>
All other tasks have finished when it yields.
<Yorlik>
So - it's prety much the only left - the "Highlander Task" (There can only be one ... ;)
<Yorlik>
How hard would it be to implement some real time priority (within the constraints of the timers) ?
<Yorlik>
However - time for a nap. BBL - so happy my lockups are gone and output now is nicely synced :)
<simbergm>
well, true real time is practically impossible for us so then it's a question of "acceptable" (really, soft) real time
<simbergm>
if you haven't yet played around with giving your important tasks higher priority I'd try that first
<Yorlik>
simbergm: What should I change here then to raise priority to the max"hpx::async<agns::sim::controller::start_action>( hpx::launch::fork, gcId );" ??
<simbergm>
Yorlik: hmm, that's an action... maybe `HPX_ACTION_HAS_HIGH_PRIORITY(start_action)`
<Yorlik>
I have an issue with my frametime stability. When I am padding time to my frame update with hpx::sleep_until the result is 1-2 ms too long, prolly because of HPX scheduling. How can I fix this? simbergm suggested to use HPX_ACTION_HAS_HIGH_PRIORITY. How and where would I use that (cpp/hpp) - and are there better ways to get more precise times?
<Yorlik>
I am padding like this: hpx::this_thread::sleep_until( frame_starttime + ( 1000000000ns / fps_rate ) );
<Yorlik>
As a last statement in the frame update
<hkaiser>
Yorlik: there is no way to get precise times :/
<Yorlik>
But a delay of 1-2 ms ... ???
<Yorlik>
Sometimes even more
<hkaiser>
depends on many things
<Yorlik>
How difficult would it be to implement something like an as precise as possible reschedule something?
<hkaiser>
no idea
<Yorlik>
My task aftr all is the last one standing after the frame update - nothing is left
<hkaiser>
could be easy enough if you left one core for the timer thread
<Yorlik>
All futures have treturned and there is plenty of time left.
<hkaiser>
or simply to a busy wait loop
<hkaiser>
*do*
<Yorlik>
So the thread doesn't get swapped out ...
<Yorlik>
I'll give that a try
<Yorlik>
Good idea.
<hkaiser>
the hpx kernel threads are affinity bound to their cores
<hkaiser>
so as long as they are running (not suspending), the OS will not swap them off
<Yorlik>
Kinda sucks burning time for this
<hkaiser>
and since we don't suspend, they get the full timeslice
<zao>
As runtimes, you fight a lot with scheduler granularity of the OS, for bonus fun.
<hkaiser>
the hpx timer runs on a separate kernel thread which then schedules a high-priority hpx thread
<zao>
Kind of hard to do anything if the OS is involved in games, as the granularity of OS primitives is quite coarse.
<hkaiser>
Yorlik: I think heller1 was looking into real-time features for hpx at some point
<hkaiser>
not sure what the outcome was
<Yorlik>
For fixed frame based physics simulations you'd want that.
<heller1>
there was a bachelor thesis
<hkaiser>
sure
<heller1>
essentially, it was implementing a custom scheduler which schedules wrt deadlines and an executor to set deadlines to the tasks
<heller1>
the scheduler was a gang scheduler, IIRC
<heller1>
not sure if that is really what you want though
<Yorlik>
Gotta dig what's best. If we end up with a 10 fps server it won't matter much anyways
<Yorlik>
The busy loop definitly works. So my rolling statistics at least wasn't bonkers. Nap4real now :) BBL.
<simbergm>
hkaiser: what would be the target name to build all our tests on windows? ALL_BUILD seems to be the equivalent of all
<Yorlik>
I think the busy loop actually is a good solution, because it gets launched only when there's a lot of time left in the frame and all tasks are done, all futures collected. So - I 'm burning only spare time and not time needed. I assume future.get() also yields, right?
<hkaiser>
simbergm: good question
<simbergm>
probably not possible if pseudo-dependencies are off (and turning that on of course doesn't work at the moment)?
<hkaiser>
Yorlik: .get() yields the hpx thread
<hkaiser>
simbergm: right
<Yorlik>
Great - so no time is wasted. But now Nap4reallyreal ... BBL ! And thanks a lot for the busy loop hint! :)
<simbergm>
hkaiser: if you have time please have a look at #4379
<simbergm>
it has two more commits that I'd like to add to the 1.4.1 release
<simbergm>
(the HPX_EXPORT pr from yesterday wasn't quite enough)
<hkaiser>
simbergm: ok, I have plenty of time before lunch today to test the rc
<simbergm>
hkaiser: excellent
<simbergm>
gh actions claims that at least examples build fine on windows now
<simbergm>
tests may still be broken
<hkaiser>
great
<hkaiser>
was it difficult to add?
<hkaiser>
(you forgot the license in the yaml file, btw)
<simbergm>
not really, just a pain to get the syntax right without an interactive console ;)
<simbergm>
good catch, thanks!
<hkaiser>
where can I see the results?
<simbergm>
hkaiser: uhm, good question
<simbergm>
I was hoping they'd show up on the status checks but maybe I need to do something to have them show up there
<simbergm>
I should've separated the compilation fixes into another pr, sorry
<hkaiser>
no worries
<hkaiser>
I like the C++ standard selection scheme you introduced, btw
<hkaiser>
less trouble for the user
<simbergm>
just let me know if you think the non-gh actions changes look ok and I'll cherry pick those over
<simbergm>
we don't need to merge the full pr for that
<simbergm>
yeah, I figured it's more straightforward than the eager way of picking the highest supported standard
<hkaiser>
yah, looks fine, thanks
<hkaiser>
go ahead with #4379 (except for the gh-actions)
hkaiser has quit [Quit: bye]
<simbergm>
hkaiser: thanks
hkaiser has joined #ste||ar
<hkaiser>
simbergm: what branch should I test for the rc? the tag?
<simbergm>
hkaiser: I just wanted to write to you... I didn't tag another rc, so just the release branch unless you'd prefer a tag
<simbergm>
and it's pushed now
<hkaiser>
ok, the branch is fine
<hkaiser>
I wasn't sure what branch you're using for this
jaafar has joined #ste||ar
<hkaiser>
simbergm: testing the release branch...
<hkaiser>
has the hpx/type_support/pack.hpp header been moved (again?)
<hkaiser>
if yes, it needs a forwarding header
<simbergm>
hkaiser excellent catch
<simbergm>
No, I left that one out because I thought it was moved by the pack pr
<simbergm>
I'll add that as well, thanks!
<hkaiser>
yah, but Phylanx breaks (which is nobrainer as we can fix it, just thought to mention it)
<hkaiser>
simbergm: I would just like to avoid being forced to update Phylanx whenever things change in HPX - a bit of leeway would be nice to have ;-)
<simbergm>
No problem, we should fix that in hpx
<hkaiser>
it's a problem only if your project follwos HPX stable
<simbergm>
I wouldn't want you to do that either, that's why the compatibility are there
<hkaiser>
thanks!
<hkaiser>
HPX itself seems to build fine, BTW
<simbergm>
Ah...
<simbergm>
Yeah, that's not great
<simbergm>
Wait, phylanx breaks because you already made some changes to match stable hpx? And now going back to 1.4.1 breaks it again...?
<hkaiser>
yes
<hkaiser>
grrr
<simbergm>
Or?
<hkaiser>
Phylanx refers to hpx/type_support/pack.hpp, but 1.4.1 still uses the old one
<hkaiser>
it's probably not an issue as we will stay with stable instead of the 1.4.1 release anyways
<simbergm>
Hmm
<hkaiser>
it's not broken backwards compatibility, we broke forward compatibility ;-)
<hkaiser>
so please ignore this, just can't test Phylanx against 1.4.1
<simbergm>
Right, but we're not adding a forwarding header for that...
<hkaiser>
right
<hkaiser>
I can edit Phylanx for testing purposes, however
<simbergm>
Yeah :p
<simbergm>
You could go back to the old header in phylanx :p
<simbergm>
But yeah, I'll ignore that for 1.4.1
<hkaiser>
doing it right now
<hkaiser>
simbergm: Phylanx compiles ok after changing pack back to the old
<hkaiser>
so we're good to go with the release, I think
<simbergm>
hkaiser great, thanks!
<simbergm>
Did hpx tests and examples finish completely as well or still running?
<simbergm>
I take it they finished in that case...
<hkaiser>
I didn't compile all of the tests/examples, just core
<hkaiser>
and ran hello_world ;-)
<simbergm>
Ok :p
<simbergm>
I'm pretty sure the examples build now so we should be good there
<hkaiser>
right
<simbergm>
Noone can build the tests anyway except one by one so I guess we're kind of safe there...
<hkaiser>
well, you can build all of them in the VS IDE
<hkaiser>
but who would do that ;-)
<simbergm>
Crazy people!
<simbergm>
More seriously, I should fix it again (I'm pretty sure I broke pseudo dependencies at some point on windows)
<hkaiser>
they are tricky there because of the path length limitations and the related uniqueness requirement
<hkaiser>
simbergm: it should be possible to make the pseudo targets unique by appending 1, 2, 3, ... as necessary
<hkaiser>
create_pseudo_target can do some checking and apply the necessary changes
<hkaiser>
that should simplify our task in keeping them unique