[Question] Simulation speed gap between the Factory (Forge) tasks and Manipulation tasks

[pumfish]

Question

Hello,
I am currently testing the RSL-RL PPO algorithm on Isaac Lab tasks. Initially, I trained on the manager-based manipulation tasks, and everything worked normally—training 3000 iterations took only around 2 hours.（num_envs=2048）

However, when I added the RSL-RL configuration to the direct Factory (Forge) tasks, the problem appeared: training the same 3000 iterations took much longer(num_envs=128). After checking, I found that the collection time of each iteration in the Forge tasks is around 20–50 seconds, which is far slower than the manager-based manipulation tasks.

I also tried using the officially provided RL-Games training scripts, and the simulation speed of the Forge tasks was still significantly slower than the manager-based tasks. This makes me think the issue is not related to the algorithm itself.

I checked the configuration differences between the two task types (such as decimation, episode_length, sim.physx settings, etc.), but I still could not identify the source of the simulation speed gap.

Could you please clarify what causes such a large performance difference between Manager-Based tasks and Factory (Forge) tasks in Isaac Lab?

Thank you!

Build Info

Describe the versions that you are currently using:

• Isaac Lab Version: [2.3.0]
• Isaac Sim Version: [5.0.0`]

[RandomOakForest]

Thank you for posting this. The large performance difference in simulation speed between Manager-Based manipulation tasks and Factory (Forge) tasks in Isaac Lab, as you describe, is most likely caused by significant differences in simulation scene complexity, physics fidelity requirements, and parallelization efficiency, rather than the RL algorithm or hyperparameters themselves.

Main Reasons for Simulation Speed Gap

• Scene Complexity and Asset Count:
  Factory (Forge) tasks are typically far more complex—they often involve many more objects, detailed meshes, more articulated robots (or robot arms), and richer physical interactions, compared to the simpler, more streamlined environments in manager-based manipulation tasks. Each additional asset (even passive objects) adds overhead for collision, contact resolution, and step computation in the physics engine.
• Physics Simulation Fidelity:
  Forge tasks may require higher simulation accuracy for contacts, friction, or kinematics (e.g., more detailed friction models or continuous collision detection). This increases the computational cost per timestep. PhysX settings such as solver iteration counts, contact offset tuning, and visualization parameters can drastically affect the speed if set higher in Forge task configs.
• Parallelization and Environment Design:
  Manager-based tasks often support a higher number of concurrent environments (e.g., num_envs=2048), utilizing GPU parallelization very efficiently. Factory tasks frequently use a smaller number (e.g., num_envs=128) because of larger per-environment resource consumption and scene constraints, resulting in poorer scaling for throughput even when more GPU resources are available. The environment setup might also induce more context switching or memory bottlenecks.
• Task Episode Length and Synchronization:
  Episode length (steps per rollout) and how episodes are synchronized can matter. If Factory tasks have longer episodes or force synchronization across environments, overall simulation speed may decrease.
• Sensor Configuration and Output:
  Forge tasks might have more sensor modalities enabled (e.g., cameras, depth maps, segmentation), which add significant data transfer and computation overhead per step.

Steps to Diagnose and Improve Speed

• Profile Physics and Scene Cost:
  Use Isaac Lab's built-in profilers and PhysX stats to log step times per environment, collision pair count, and any excessive mesh complexity. Simplifying meshes and reducing collision complexity can help.
• Reduce Sensor Demand:
  Disable sensors not needed for your RL experiment, especially those that output images or point clouds.
• Tune Sim.Physx Settings:
  Lower solver iteration counts, consider disabling continuous collision detection, and review other fidelity settings in the simulation config. Some parameters dramatically increase physx step computation. See NVIDIA Isaac Lab documentation for best practices on simulation parameter tuning.
• Batch Environment Sizes:
  Try scaling up num_envs gradually for Forge tasks to see how far you can push parallelization without running into GPU memory limits.
• Compare Episode Length and Decimation:
  Confirm if the step decimation (frame skip) and episode length match between tasks, as these directly impact rollout and simulation speed.

[pumfish]

Thank you very much for your prompt and comprehensive response.
It greatly helps me understand the simulation speed differences in Isaac Lab. I will follow your suggestions and examine the relevant parts of the code.