solver warmstart

[thowell]

the existing solver implementation initializes qacc with qacc_warmstart.

this pr:

• if the warmstart disableflags option is not set, solve compares the costs associated with qacc_smooth and qacc_warmstart in order to determine the initialization for qacc
• if the warmstart disableflags option is set, qacc is initialized with qacc_smooth

benchmarking:

mjwarp-testspeed --function=solve --mjcf=humanoid/humanoid.xml --batch_size=8192 --iterations=1 --ls_iterations=5 --solver=newton

this pr:

Summary for 8192 parallel rollouts

 Total JIT time: 0.15 s
 Total simulation time: 8.48 s
 Total steps per second: 966,092
 Total realtime factor: 4,830.46 x
 Total time per step: 1035.10 ns

main:

Summary for 8192 parallel rollouts

 Total JIT time: 0.14 s
 Total simulation time: 7.91 s
 Total steps per second: 1,036,164
 Total realtime factor: 5,180.82 x
 Total time per step: 965.10 ns

[erikfrey]

This is an interesting scenario! It seems to suggest we should not follow the exact same behavior here as MuJoCo because the cost of the thread divergence is higher than the cost of the occasional extra solver step. That's my read at least.

I would suggest holding off on this and revisiting after we implement logging and measuring solver statistics, because then we can get a really good intuition on how early returning relates to step perf and the tradeoffs for this kind of thread divergence.