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/
primef5 has joined #ste||ar
primef5 has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
Yorlik_ has joined #ste||ar
Yorlik_ has quit [Read error: Connection reset by peer]
<Yorlik>
Do parallel loops accept some sort of hints about how to chop up the portions? I am thinking about how to schedule an array full of stuff and chop it into workloads. Problem is every frame and within the array the times can possibly vary a lot.
<hkaiser>
so static_chunk_size is the default, but you can try using the auto_chunk_size policy (which is measuring things)
<hkaiser>
or simply create your own
<Yorlik>
From your experience - Doing this every frame (minimum 16.6 ms, maybe 100 ms if we go for 10 fps) - how would you estimate the benefit of doing something custom instead of just using the auto_chunk_size?
<hkaiser>
shrug
<hkaiser>
depends
<Yorlik>
I have a weird feeling I might be overoptimizing here.
<Yorlik>
Gott a neasure anyways :D
<hkaiser>
I'd go with the defaults and see how it performs
<Yorlik>
Ya. Thatr's probably best.
<Yorlik>
Is there a way to instrument the vhunks, like mean runtime?
<hkaiser>
then you can measure on the first invocation and use the timings for subsequent invocations of the same loop
<Yorlik>
chunks
<hkaiser>
good question, I don't think we have a hook there, but this could be done
<Yorlik>
When you have very variable update times / chunk times it might help. I have a weird feeling, that any heuristic would have to deal with a very chaotic time distribution.