Clarification on pre-warming JIT paths about bepuphysics2 HOT 4 CLOSED

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.)

from bepuphysics2.

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.

from bepuphysics2.

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.)

from bepuphysics2.

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

from bepuphysics2.