make `n_jobs=-1` as default instead of `n_jobs=None`?

[akshitasure12]

In tournament.is_reachable() under nx_parallel, the call to Parallel() does not explicitly pass the n_jobs parameter.

n_jobs = nxp.get_n_jobs()

return all(
	Parallel()(delayed(two_neighborhood_close)(G, chunk) for chunk in node_chunks)
)

By default, this will use n_jobs=None, which as per the joblib documentation, is interpreted as n_jobs=1 unless overridden by a parallel_config() context manager.

Expected Behavior :

n_jobs = nxp.get_n_jobs()

return all(
        Parallel(n_jobs=n_jobs)(delayed(two_neighborhood_close)(G, chunk) for chunk in node_chunks)
    )

Also, in the current implementation of get_n_jobs(), when n_jobs is not explicitly set (n_jobs=None), the following logic is used:

if n_jobs is None:
        if nx.config.backends.parallel.active:
            n_jobs = nx.config.backends.parallel.n_jobs
        else:
            from joblib.parallel import get_active_backend
            
            n_jobs = get_active_backend()[1]

    if n_jobs is None:
        return 1

Wouldn't it be more logical to automatically set n_jobs=-1 when get_active_backend()[1] gives none and nx.config.backends.parallel.active is false? Otherwise, the current behavior defaults n_jobs to 1, causing the task to run sequentially.

[Schefflera-Arboricola]

In tournament.is_reachable() under nx_parallel, the call to Parallel() does not explicitly pass the n_jobs parameter.

This is intentional. The @nxp._configure_if_nx_active() decorator wraps the internal Parallel call in a joblib.parallel_config() context manager, which either applies config settings from nx.config.backends.parallel (if nx.config.backends.parallel.active=True) or uses the parameter values in joblib.parallel_config() (if active=False). There's no need to pass n_jobs explicitly here.

Wouldn't it be more logical to automatically set n_jobs=-1 when get_active_backend()[1] gives none and nx.config.backends.parallel.active is false? Otherwise, the current behavior defaults n_jobs to 1, causing the task to run sequentially.

if the "get_active_backend()[1] gives none and nx.config.backends.parallel.active is false" that means the user wants to use the joblib's configs i.e. n_jobs=None(here)-- this could be set explicitly by the user or this could have been the default-- we don't have a way to tell.

We did discuss this previously(in PR #75) when we were setting the config system in nx-parallel, if we wanted to keep nx-parallel's defaults same as joblib's defaults or should we change only one parameter's (i.e. n_jobs's) default to -1 instead of None. Then we settled to go on with joblib's default-- but it does seem more convenient for networkx and nx-parallel users to have n_jobs=-1 by default-- because then they wouldn't have to get into the configs part of nx-parallel to speed up their code-- just adding backend="parallel" would use all of the CPU cores by default. @akshitasure12 @dschult thoughts-- should we change the default n_jobs=None to n_jobs=-1?

[akshitasure12]

This is intentional. The @nxp._configure_if_nx_active() decorator wraps the internal Parallel call in a joblib.parallel_config() context manager, which either applies config settings from nx.config.backends.parallel (if nx.config.backends.parallel.active=True) or uses the parameter values in joblib.parallel_config() (if active=False). There's no need to pass n_jobs explicitly here.

Thanks for the clarification! I went back and carefully reviewed config.md again -- it's much clearer to me now!