Jolt vs PhysX?

[alienself]

Hi there!

Love your physics engine and definitely considering using it for my next project.
What are the known limitations of Jolt compared to PhysX? Did you run benchmarks against PhysX 5.0?
Are you planning to keep supporting it in the future?
Do you have a roadmap of upcoming features?

Thanks

[Pierre-Terdiman]

https://github.com/Pierre-Terdiman/PEEL_PhysX_Edition

[jrouwe]

Hello,

PhysX is obviously a much bigger project and it has more features than Jolt. I think the biggest limitation of Jolt right now is that if your simulation requires all physics objects to be on a single pile then it does not scale well (i.e. the entire simulation will run on a single CPU). If your physics objects are spread out more, then it will use all CPU cores and then the performance is pretty decent. This is a fixable limitation, but as this limitation hasn't been an issue for me, I haven't spent time on it.

I haven't tried out PhysX 5.0 yet, but if you want to use the PEEL test above then please keep in mind that the Jolt version in there has none of the more modern CPU instructions enabled, it links against the Release instead of the Distribution version (which means there's some debug code in there) and the number of solver steps are set to default which is good for a high quality simulation, but you can gain quite a bit by lowering that. You can find my performance comparison for PhysX 4 here which also includes source code to run the test yourself if you want.

With respect to support: I intend to keep working on this, but as it is my hobby project, I don't really have a roadmap for it. I have a large to do list (which I'd rather not disclose as that will create expectations) and I tend to work on what is requested by the community. I think the current popular request is support for double precision, so that's one of the next things to look at.

[Pierre-Terdiman]

The Distribution build config didn't compile for me in PEEL (link error below). But it had the same preprocessor defines as the Release build config w.r.t. CPU instructions.

1>PINT_Jolt.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl JPH::ConvexShape::DrawGetSupportFunction(class JPH::DebugRenderer *,class JPH::Mat44 const &,class JPH::Vec3,class JPH::Color,bool)const " (?DrawGetSupportFunction@ConvexShape@JPH@@UEBAXPEAVDebugRenderer@2@AEBVMat44@2@VVec3@2@VColor@2@_N@Z)
1>PINT_Jolt.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl JPH::ConvexShape::DrawGetSupportingFace(class JPH::DebugRenderer *,class JPH::Mat44 const &,class JPH::Vec3)const " (?DrawGetSupportingFace@ConvexShape@JPH@@UEBAXPEAVDebugRenderer@2@AEBVMat44@2@VVec3@2@@z)
1>PINT_Jolt.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl JPH::BoxShape::Draw(class JPH::DebugRenderer *,class JPH::Mat44 const &,class JPH::Vec3,class JPH::Color,bool,bool)const " (?Draw@BoxShape@JPH@@UEBAXPEAVDebugRenderer@2@AEBVMat44@2@VVec3@2@VColor@2@_N4@Z)
1>PINT_Jolt.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl JPH::SphereShape::Draw(class JPH::DebugRenderer *,class JPH::Mat44 const &,class JPH::Vec3,class JPH::Color,bool,bool)const " (?Draw@SphereShape@JPH@@UEBAXPEAVDebugRenderer@2@AEBVMat44@2@VVec3@2@VColor@2@_N4@Z)
1>PINT_Jolt.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl JPH::CapsuleShape::Draw(class JPH::DebugRenderer *,class JPH::Mat44 const &,class JPH::Vec3,class JPH::Color,bool,bool)const " (?Draw@CapsuleShape@JPH@@UEBAXPEAVDebugRenderer@2@AEBVMat44@2@VVec3@2@VColor@2@_N4@Z)
1>PINT_Jolt.obj : error LNK2001: unresolved external symbol "public: static class JPH::ProfileThread * JPH::ProfileThread::sInstance" (?sInstance@ProfileThread@JPH@@2PEAV12@EA)
1>PINT_Jolt.obj : error LNK2001: unresolved external symbol "private: static bool JPH::ProfileMeasurement::sOutOfSamplesReported" (?sOutOfSamplesReported@ProfileMeasurement@JPH@@0_NA)

[jrouwe]

If you link against a Distribution version of the library you should undefine JPH_FLOATING_POINT_EXCEPTIONS_ENABLED, JPH_PROFILE_ENABLED and JPH_DEBUG_RENDERER (the last one is what is creating the compilation error here).

[Pierre-Terdiman]

D'uh. Silly me. Thanks, fixed. I compiled a distribution + AVX/AVX2 version and uploaded it to the PEEL Github. The cool thing with PEEL is that now you can run Jolt vs Jolt AVX on the same scenes at the same time :)

It doesn't seem to make much of a difference in that perf test though. I think the clearest gains I saw were on raycast-vs-mesh performance perhaps.

[Pierre-Terdiman]

and the number of solver steps are set to default

I kind of missed that you changed that in your pull request :( What was wrong with 1/4 ? Anyway you can change that in the UI guys.

Pierre-Terdiman/PEEL_PhysX_Edition@10f289c

[jrouwe]

I changed because some of the tests that use a lot of constraints didn't look great with these settings.

[Pierre-Terdiman]

You can find my performance comparison for PhysX 4 here which also includes source code to run the test yourself if you want.

FWIW, here's what I get for that scene when comparing Jolt/Release/1+4 iter/16 threads vs PhysX 4.1.2/8 threads in PEEL.

The curves intersect so I'm not sure capturing the results of the test with a single "steps/second" number paints an accurate picture of what's going on, but.... oh well. Use PEEL for more detailed results.

[Pierre-Terdiman]

I like the "extended version" of this test scene in PEEL, where I made the scene a bit larger (it makes the performance curves less noisy).

Here is what I get for Jolt/Release/1+4 iters/16 threads vs PhysX 4.1.2/PhysX 5.1.0/15 threads. It shows the small performance improvements on this scene between PhysX 4 and PhysX 5, and shows in a perhaps clearer way that the "winner" in these tests depends on where you take your performance samples.

Might also depend on your CPU (Intel i9 here). To produce these graphes:

• run PEEL, select the engine(s) you want to use (all at the same time is fine)
• tweak the solver iterations in the UI if needed
• press R to disable Rendering (less noisy)
• run for a number of frames
• press S to save an Excel file. Will be located in PEEL's Excel folder.
• open in Excel, create a graph from the raw numbers.

Have fun :)

[Pierre-Terdiman]

You can also disable sleeping in all engines (in the UI). Here's what I get on my machine with sleeping disabled. Compared to the default PEEL settings I also changed these in the UI:

• 1/4 iterations for Jolt (default was 2/10)
• 15 threads for PhysX (default was 8)

In any case they all look pretty much "the same" to me, I don't think we'll learn much more from that specific test. I'm sure we could cherry-pick PEEL tests with more explicit results and clearer "winners" if we want to (one way or another).

Jolt is pretty good. I just wouldn't draw a conclusion ("it scales better than PhysX") from one number in one benchmark, there is so much more to performance than this.

[Pierre-Terdiman]

Ok while I'm at it, and if people are interested, there's something else in PhysX that explains the behavior of the initial test with 16 threads.

PhysX doesn't use up all available threads in the original test, because of the strategy used to allocate tasks. I looked at that when Jolt was first released and IIRC in that test with 16 available threads we only spawn 8 collision tasks, so indeed for some parts of the system 8 or 16 available threads makes no difference.

That is not because "PhysX doesn't scale", that's because the scene is too small and the system doesn't bother using up more of the available resources (sometimes it's better to be friendly with the other sub-systems running in parallel) :) If you make the scene larger (like I did in "Jolt Performance Test 2") PhysX starts using up more of the available threads. This is a side effect of the task allocation strategy. Look for "gUseNewTaskAllocationScheme" in the PhysX 5 source code if you're interested in the details.

[Pierre-Terdiman]

Alright check this out. I was wrong, we can still learn something from this test.

This is the same as the last post above but now I also disabled the "stabilization" feature from PhysX (it's not sleeping exactly but it also does bypass some computations here and there).

Neat how these curves match now.

[jrouwe]

Cool! Thanks for all the investigations!

[Pierre-Terdiman]

I also found today that the PxSceneDesc::solverBatchSize parameter in PhysX had a measurable impact on performance in this scene. The default is 128 but I'm getting slightly better performance with 32. That's probably because the scene is full of small islands, and PhysX merges these islands together when the number of bodies is below solverBatchSize. Reducing that number seems to help a bit in this test (although not in the general case / other scenes).

[Pierre-Terdiman]

Related: https://twitter.com/rajetic/status/1590670754047148033?s=20&t=hR6ISULs_KiDEd7NMnlBRw