bepu / bepuphysics2

Pure C# 3D real time physics simulation library, now with a higher version number.
Apache License 2.0
2.25k stars 261 forks source link

Clarification on pre-warming JIT paths #252

Closed BlueCyro closed 9 months ago

BlueCyro commented 1 year ago

Hi! I'm just a moderately knowledgable C# hobby-level programmer and I was looking for clarification on how exactly you could pre-warm the JIT paths for colliders and such. I noticed that the problem was stated in the documentation, but never expanded on (at least that I could find).

The emission of the unique JIT code for different things in bepu 2 seems to cause some pretty gnarly hitches - perhaps due to the fact it's running in a pretty old mono runtime, but I can't avoid that for the time-being.

Could you elaborate on how I could warm up those code paths so that they're nice and toasty?

RossNordby commented 1 year ago

The brute force approach of running a representative simulation, or invoking all the relevant codepaths directly, will work. For something like CoreCLR's tiered JIT, you'd need to invoke the codepaths more than once. Running a full representative simulation for 128 frames with a bunch of relevant collision tests and constraints being executed would do the trick.

Not sure how an old mono version would act, or what it would require to reach maximum steady state performance. Depending on what you're doing, there may be some AOT path you could use- there won't be a JIT cost if there's no JIT execution, after all.

(By the way, if you weren't already aware, old mono versions can struggle a lot with bepuphysics2 even in steady state performance; you may want to confirm it can run well enough before bothering to try to figure out how to get rid of the JIT spikes.)

BlueCyro commented 1 year ago

For context I'm using a program called Neos (I believe Frooxius has posed some questions here before, even), which unfortunately is stuck on a real old unity mono runtime. It has it's own bepu simulation already running; would this work with my own simulation running for a bit and warming the code paths?

I'm also curious if you could describe what a "Full representative simulation" is. Are there specific objects I should create or functions I should run? Sorry for the naive questions, I'm a little out of my depth.

RossNordby commented 1 year ago

It has it's own bepu simulation already running; would this work with my own simulation running for a bit and warming the code paths?

Yup- provided it's actually the same code being executed in both cases (not some sort of duplicate version), the JIT's work on one simulation will transfer to the other.

I'm also curious if you could describe what a "Full representative simulation" is. Are there specific objects I should create or functions I should run?

It's pretty much "whatever is in the actual simulation you want to do." So if your goal simulation is a bunch of spheres colliding with some ball socket joints, you'd want to include colliding spheres and ball socket joints.

The thing that makes the the warmup simulation representative is that the same codepaths are hit. (So you don't have to worry about having 10000 spheres in the warmup just because the "real" simulation does, so long as all the relevant sphere cases are invoked a sufficient number of times for the JIT to optimize them.)

BlueCyro commented 1 year ago

Thank you very much, I'll definitely give it a go!