SuperDex vs Newton

Two engines that disagree about what a time step is for.

Newton's bet is that a manipulation policy needs billions of cheap samples, so the unit of work is a substep across thousands of GPU worlds. SuperDex's bet is that a manipulation policy needs samples that are right, so the unit of work is a converged implicit solve of one scene at a 16.7 ms step. Both bets are defensible. They are not the same product, and the benchmark that flatters one buries the other.

SuperDex is four products; only one of them is a physics engine.

It is a variational implicit integrator solved by Newton–Raphson. Not LCP, not PGS, not XPBD, not TGS.

Every physical term — inertia, gravity, stress, contact, constraints, tendons — contributes an objective, residual and d-residual triple to a per-island system of nonlinear equations. One Newton solve per stage advances the step. Introspecting the shipped wheel prints the whole design in one screen:

>>> from superdex import physics as sp

IntegrationMethod:   BACKWARD_EULER (default), BDF2, BDF3,
                     DIRK22, DIRK23, DIRK33, SYMPLECTIC_DIRK12, SYMPLECTIC_DIRK22
NonLinearSolverType: NEWTON (default), BFGS, SR1
LineSearchType:      RESIDUAL_NORM (default), ARMIJO, WOLFE_WEAK, WOLFE_STRONG, ...
PsdProjectionMode:   ALWAYS (default), NEVER, IF_FAIL_RETRY, IF_FAIL_ALWAYS
LinearSolverType:    AUTO (default), CG, GMRES, MINRES, LDLT, LU, AUGMENTED_CG,
                     PARALLEL_CG, ASYNC_CG, CUDA_CG, CUDA_GMRES, ...
PreconditionerType:  PER_ACTOR (default), AMG, IC0, ILU0, SSOR, BLOCK_JACOBI, ...
LinearToleranceStrategy: EISENSTAT_WALKER2 (default)   # inexact-Newton forcing terms
ActorType:           RIGID, ARTICULATED, SOFT, SHELL, ROD
SoftMaterialType:    NEO_HOOKEAN, ST_VENANT_KIRCHHOFF, ARAP, LINEAR_ELASTIC,
                     ACTIVE_NEO_HOOKEAN, ACTIVE_SHAPE_TARGETING_ARAP
CoulombFrictionModel: C1_REGULARIZED (default), CINF_REGULARIZED

Three things in that listing are unusual for a robotics engine and worth dwelling on.

The defaults that decide the character of the engine

SuperDex, MuJoCo, VBD/AVBD and Kamino are four different answers to “what is a contact?”

These are not four points on a quality axis. They are four different mathematical objects, and each one buys a property the others cannot express.

No GJK, no EPA, no convex decomposition. Surface quadrature points against a signed distance field.

SuperDex's narrow phase is not feature-pair generation. The colliding actor emits sample points — three per boundary triangle by default, configurable up to sixteen — and the collider answers each with an SDF value and gradient. Grepping the whole tree for gjk or epa returns nothing.

The friction model is IPC's, verbatim

C1_REGULARIZED is the Incremental Potential Contact mollifier — the header cites Li et al. 2020 and reproduces the C¹ interpolant of the unit step. Friction is an isotropic cone, not a pyramid, and it enters the Newton system as an energy with a saturating Hessian. Newton's VBD solver uses the same mollifier, with one difference the Newton source is explicit about:

# Different from IPC, we treat the contact normal as constant
#  this significantly improves the stability

SuperDex makes the same simplification through explicitNormals, and in fact requires it for differentiable scenes.

On one scene, SuperDex beats a GPU until the scene reaches 48 bodies.

The same experiment in both engines: N unit-density 10 cm boxes stacked in a cube lattice, dropped onto a ground plane, stepped at 16.7 ms, timed after settling. SuperDex single-threaded on one EPYC core; Newton on the GPU slice with the whole step in a captured CUDA graph.

SuperDex's cost grows as roughly N^1.6 — superlinear, as you would expect from a sparse factorisation and a broad phase that both scale with contact count, and as the AUTO heuristic flips from dense LDLT to CG past 50 DoFs.

And then the batch axis appears, and the comparison stops being close.

The previous plot is the only regime where SuperDex competes on speed. Newton's design point is not one scene — it is thousands of identical worlds in one kernel launch, which is what an RL rollout actually needs.

The dotted line deserves scepticism, and it is drawn only to be argued with. It assumes 192 independent SuperDex processes scale linearly, which ignores memory bandwidth, and it credits SuperDex with hardware that costs far more than the GPU slice it is being compared against. Even granting all of it, one seventh of a Blackwell running Newton lands within a factor of ~6 of an entire 192-core EPYC running SuperDex — and the GPU number is throttled by a partition, not by the algorithm.

The MuJoCo line is included because it is a useful reminder that solver choice dominates engine choice. On this scene — eight free-floating boxes with no articulation, which is the worst possible shape for a generalized-coordinate engine — SolverMuJoCo manages 863 env-steps/s at 16 worlds, 66× slower than XPBD, before failing outright at 64. Quoting “Newton” a single throughput number is meaningless; quoting SuperDex one is at least well-defined, because it only has one solver.

The time-step claim is true. The contact-softness claim is the price.

SuperDex's examples repeat one claim verbatim: “fully-implicit integration, enabling substantially larger stable time steps than explicit or semi-implicit methods … 10–25 ms steps remain robust.” A single box dropped from 1 m and left to settle for 3 s tests it directly.

That is a genuinely strong result and it is the engine's best feature. But the flip side is the number itself: the box rests 0.308 mm inside the floor, and where it rests is a pure function of load ÷ stiffness.

Threading helps to four workers, then actively hurts.

SuperDex's only scaling lever is initialize(num_worker_threads=N). The docstring promises that “for scenes with a large number of DoFs … running with multiple threads will improve performance.” On a 192-core EPYC, with 1 899-tet FEM ducks — precisely the high-DoF case the docs point at — it does not hold up.

The mechanism is visible in the source. Parallelism is task-graph over simulation islands, not data-parallel over the state vector: islands are scheduled as concurrent tasks on a Google marl fibre scheduler, collision detection overlaps with articulated-Jacobian updates, and small islands explicitly opt out via island::ShouldRunSingleThreaded. A scene with one duck has one island, so there is nothing to overlap — only threads to synchronise.

The CUDA solvers are in the API and cannot run.

LinearSolverType advertises CUDA_CG, CUDA_GMRES and three experimental cuSPARSE factorisations. Eight .cu files ship in the tree. It is reasonable to read all that as a GPU engine. It is not one.

CUDA_CG                            FAIL  Error: mochi_scene.cpp(423):
                                         CUDA solvers require building with CUDA.
CUDA_GMRES                         FAIL  (same)
EXPERIMENTAL_CUDA_SPARSE_CHOLESKY  FAIL  (same)
EXPERIMENTAL_CUDA_SPARSE_LDLT      FAIL  (same)
PARALLEL_CG                        OK    ConvergenceStatus.CONVERGED
CG                                 OK    ConvergenceStatus.CONVERGED

And it cannot be fixed by rebuilding from the public source: MOCHI_USE_CUDA defaults to 0, and grepping every CMakeLists.txt and .cmake in the repo for it returns nothing. There is no CMake option, no find_package(CUDAToolkit), no enable_language(CUDA). The CMake preamble sets MOCHI_INTERNAL OFF … FORCE with the comment “Only external builds are supported with CMake” — CUDA is wired up in Meta's internal Buck build, which was not released.

One detail cuts the other way and is worth flagging as a hint about intent. The SIMD emulator header says:

// Emulate 32 16-byte SIMD registers. A common use case for SIMD emulation is NVIDIA GPUs, where
// each thread has access to 255 32-bit registers.

Somebody has thought about running these kernels on a GPU. It has not shipped.

Where SuperDex is ahead: one solver for five body types, and tendons that are actually modelled.

SuperDex differentiates through contact analytically. This is the least expected thing in the release.

There is a superdex.physics.diffsim module, and it is not a stub. It implements adjoint differentiation of the implicit step via the implicit function theorem, with an inner adjoint solve and a full set of vector-Jacobian products.

make_scene_differentiable(scene)
prepare_back_propagate(scene, state_new, state_old)
back_propagate(scene)
get_step_jacobian(scene, state_new, state_curr, state_old) -> (jac_curr, jac_old)

# vector-Jacobian products, including through contact:
get_contact_force_world_backward(...)
get_contact_force_from_actor_world_backward(...)
get_articulated_pose_backward(...)
set_articulated_target_pose_backward(...)
set_external_forces_on_dofs_backward(...)
# plus Lie <-> quaternion <-> rotation-vector gradient converters

The comparison is genuinely close, and it is the one axis where SuperDex's architecture pays an unambiguous dividend: differentiating an implicit solve is a linear solve you already did, whereas differentiating an explicit substep chain is a tape that grows with substep count. If SHAC-style short-horizon actor-critic on contact-rich manipulation is the goal, SuperDex's formulation is the more principled starting point — on a CPU, for one environment, with finite-difference Hvps.

Imperative scene graph with handles, versus a builder that finalises to device arrays.

physics.initialize(num_worker_threads=0)
scene = physics.create_scene("Rigid Bodies Scene")
scene.set_gravity([0, -9.8, 0])          # Y-up!

plane  = physics.create_plane_shape(normal=[0,1,0], distance=-1.0)
sphere = physics.load_shape_from_file(
    file_path=str(resolve_asset("sphere/icosphere_3subdiv.1.mochi.json")),
    bake_scale=[0.2, 0.2, 0.2])

a = scene.create_rigid_actor(
    name="sphere", shape=sphere, density=1000.0,
    world_from_local=physics.TransformRT(translation=[-0.5, 0.2, 0]),
    collider_type=physics.ColliderType.SPHERE)
scene.create_rigid_actor(name="ground", shape=plane, is_static=True)

physics.prefab.add_to_scene(prefab_path=..., root_path=..., scene=scene,
    params=physics.prefab.PrefabParams(name="tablePrefab"))

while True:
    scene.step(1/60)
    T = a.get_root_transform()
    f = a.get_contact_force_world()

quadruped = newton.ModelBuilder()
quadruped.default_joint_cfg.armature = 0.01
quadruped.add_urdf(path, xform=..., floating=True)

scene = newton.ModelBuilder()
scene.replicate(quadruped, world_count=100)      # <-- the batch axis
scene.add_ground_plane()
model = scene.finalize()                          # -> device arrays

solver = newton.solvers.SolverXPBD(model)
state_0, state_1 = model.state(), model.state()
control, contacts = model.control(), model.contacts()

with wp.ScopedCapture() as cap:                   # whole step in one graph
    for _ in range(sim_substeps):
        state_0.clear_forces()
        model.collide(state_0, contacts)
        solver.step(state_0, state_1, control, contacts, sim_dt)
        state_0, state_1 = state_1, state_0
graph = cap.graph

for frame in range(N):
    wp.capture_launch(graph)

Assets

They are not competitors. Pick by whether your bottleneck is samples or fidelity.

Everything here runs from four scripts.

# SuperDex — wheels only, no build needed
git clone --branch stable https://github.com/facebookresearch/project_superdex
cd project_superdex && uv venv --python 3.12 .venv
uv pip install --python .venv/bin/python superdex
export SUPERDEX_ASSETS_PATH=$PWD/superdex_physics/assets

# Newton
cd newton && uv sync

# 1. single-scene crossover
.venv/bin/python scripts/sdx_bench.py    rigid 0     # SuperDex, N = 1..216 bodies
.venv/bin/python scripts/newton_bench.py single      # Newton, all solvers, same scene

# 2. batch scaling
.venv/bin/python scripts/newton_bench.py scale       # 1..4096 worlds

# 3. accuracy: penetration, time step, determinism
for m in dt penalty mass iters determinism; do
    .venv/bin/python scripts/sdx_accuracy.py $m | grep '^{'
done

# 4. thread scaling
for t in 0 2 4 8 16; do .venv/bin/python scripts/sdx_threads.py $t; done

Scripts are in scripts/, raw JSONL in data/. Two cautions if you re-run: run one benchmark process at a time — an early pass with three concurrent processes on the same MIG slice reported XPBD at 4.15 ms where the clean number is 0.237 ms, a 17× error — and filter stdout with grep '^{', because mochi's solver warnings and Warp's module-load messages both go to stdout and will corrupt a JSONL parse.