In your other thread you brought up destiny and their simultaneous update/drawing routines and how this will increase latency. This isn't necessarily true and becomes obvious once we draw some timelines.
Let's say we've got three CPU tasks in a frame, with these costs, which must occur in this serial order:
Poll Inputs: 1ms
Update Simulation: 15ms
Draw Scene: 17ms
Single threaded:
0ms 1ms 16ms 33ms 34ms 49ms 66ms
Core1: | Poll#1 | Update#1 | Draw#1 | Poll#2 | Update#2 | Draw#2 |
Dual threaded, no buffering / pipelining:
0ms 1ms 16ms 33ms 34ms 49ms 66ms
Core1: | Poll#1 | Update#1 | Idle | Poll#2 | Update#2 | Idle |
Core2: | Idle | Draw#1 | Idle | Draw#2 |
Dual threaded, pipelined:
0ms 1ms 16ms 17ms 32ms 33ms
Core1: | Poll#1 | Update#1 | Poll#2 | Update#2 | Idle | Poll#3...
0ms 16ms 33ms 50ms
Core2: | Idle | Draw#1 | Draw#2 |
Single-threaded, this takes 66ms for two frames.
Putting draw and update onto their own threads, but enforcing mutual exclusion still takes 66ms for two frames.
Running Update and Draw in parallel, by pipelining two frames together, reduces the critical path to 50ms for two frames if you include the pipeline warmup time. Once the pipeline is warmed up, it's actually just 34ms per two frames from that point onwards!
There's still no extra latency for the user -- the path from input polling to finished drawing is 33ms in all three situations.
The only difference is that first two options pump frames at ~30Hz, while the third option pumps frames at ~59Hz - so it's increased framerate while leaving input latency exactly the same as it was before.
Now, extending this. Let's say that your Draw cost is still 17ms, but your Update cost is only 2ms. If we pipeline this as above, then the critical path goes through the Draw tasks, so the best framerate we can achieve is still ~59Hz as above.
So, seeing that our user is only able to perceive the game world at 59Hz... you could argue that polling any faster than this is not required. We can then use the exact same timeline as above, but replace the |Update#N| block with |Update[#N - #N+8)| , and replace Draw#1/Draw#2 with Draw#8/Draw#16 - i.e. we do 8 updates per poll/draw.
If you accept the argument that there's no need to poll faster than the drawing rate, then this will be just as responsive as before, even though we're "dropping" seven out of eight frames :)