Julia: Feature Request: Command Line Option for Number of Threads

[iwelch]

I like the environment variable JULIA_NUM_THREADS, but it should be overridable with a -t(hreads) choice. If -p works, -t could reasonably do this, too.

[GregPlowman]

I sometimes want to be able to change the number of threads within a REPL session, or programmatically within Julia. So something like addthreads() or setnumthreads() might be useful too.
(Although I suspect the number of threads needs to be set at Julia startup?)

[mattcbro]

I second the programmatical option within Julia. In some cases distributing julia code to cross platform users who know nothing about Julia, would require additional steps that should be transparent to them. Setting the number of threads is one such step.

[biluohc]

I agree with JULIA_NUM_THREADS as julia's command line option.
Setting environment variables is more troublesome because of various platforms and shell may be different.

[StefanKarpinski]

I agree that we should have this and -t seems like a good name. It's used for "taint warnings" in Perl and Ruby and for tab warnings in Python. I don't see us ever needing either of those things.

[StefanKarpinski]

There is a slight ambiguity of what -t n would mean in the presence of -p m: is it the number of threads per process started or the number of total threads? Either meaning makes sense. Of course JULIA_NUM_THREADS already effectively has the meaning of threads per process, so if we wanted to match that, then -t n would dictate the number of threads per process and there would be m*n threads total. Which, of course then interacts with passing -p and/or -t without arguments. Passing -p by without a number value starts as many Julia processes as the local machine has cores. Presumably julia -t without a number would start Julia with as many threads as the machine has cores as well. Running julia -t -p seems ambiguous: where do you want the balance between threads and cores to be? So that should be an error. If -t or -p are passed with a number, however, we could figure out the other number by implication if there are 2 processes, then there should be half as many threads per process as the machine has cores. Also, what if we pass a machine file and -t? That should probably start as many threads on each machine as it has cores and maybe be smart by splitting the cores if there's more than one process per machine in the machine file. Again, we can ask if -t n gives the number of threads per process or the number of threads per machine.

[biluohc]

@StefanKarpinski

Usually, if you use multiple processes, you won't use multiple threads, because there are so many cpu cores.
Therefore, I suggest using a thread by default, and -t simply specifies the number of threads in a process, and the balance between the number of threads and the number of processes should be selected by the user, rather than julia's calculation and trade-off result using the values of core number, -n and -p, which is not conducive to user understanding

[hearnsj]

"Usually, if you use multiple processes, you won't use multiple threads"
I completely agree with the use of Usually here.
It is worth pointing out that 'mixed mode' parallel processing is done, for example in the ABAQUS code and others.
OpenMP is used withing a single compute node(threads) and MPI between nodes (processes)

[DilumAluthge]

Bump. Any update on this?