Parallel simulation refactoring

[bmalezieux]

This PR refactors the simulation utilities to improve parallel execution efficiency and modularity.

• New parallelize_simulator decorator/function: introduces a tool that wraps any simulator to enable parallel execution using joblib.

• New simulate_from_thetas utility: added a lightweight wrapper around parallelize_simulator that directly executes simulations for a given set of parameters (thetas).

• Refactored simulate_for_sbi (backward compatibility): updated the internal implementation of simulate_for_sbi to leverage the new simulate_from_thetas backend.

[janfb]

Awesome, looks very good already.

I was wondering whether we would also need to refactor process_simulator accordingly? e.g., we can likely drop the internal torch wrapping and accept numpy simulators (because we wrap to numpy as again). Would have to look into it in detail but I think we can simplify the function a bit.

[tomMoral]

A few comments.

A question: is it possible to use a return type which is str? It is unclear to me where this would go in the current sbi

[tomMoral]

Shouldn't it be:

Suggested change

	) -> Tuple[Tensor, Tensor | List[str] | str]:
	) -> Tuple[Theta, X]:

[rsvr76]

Yes, using the already-defined Theta and X type aliases here would be more consistent and readable, since they already capture all the possible return types.

[tomMoral]

Why? In this context, we could use the batch parameter of joblib (useful if initialization of the simulator is slow)

[rsvr76]

Good point. Using joblib's batch parameter would be more efficient here, especially when simulator initialization is expensive. The current loop adds unnecessary overhead.

[tomMoral]

Unclear why not keep batches = thetas? The current solution duplicates the theta in memory, which can be a large overhead for large number of simulation (probably for later version, right now everything needs to fit in memory).

[rsvr76]

Agreed. The list comprehension duplicates theta in memory unnecessarily. batches = thetas would avoid that overhead entirely, which becomes significant for large simulation counts.

[tomMoral]

I would use a iterator if possible, once again to avoid filling the memory and duplicating. in particular if this is a tensor, use split?

[rsvr76]

Using torch.split(thetas, simulation_batch_size) would return views rather than copying data, keeping peak memory constant regardless of dataset size. This is especially important for large-scale workflows.

[tomMoral]

We need to be able to seed this part no?

[rsvr76]

Agreed, the seed for generating batch_seeds should itself be derived from the user-provided seed argument to ensure full reproducibility. Currently if a user passes seed=42 the batch seed generation is still non-deterministic.

[tomMoral]

Suggested change

	context = parallel_config(n_jobs=num_workers)
	with context:
	with parallel_config(n_jobs=num_workers):

[tomMoral]

Why not use simple_simulator_torch which is the same?

[rsvr76]

Good catch. Reusing simple_simulator_torch here would reduce duplication in the test suite and make it clearer that the decorator test is testing the wrapping behaviour rather than a specific simulator implementation.