Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

export JULIA_NUM_THREADS=X sets nthreads(:interactive)=0 #50084

Open
oscardssmith opened this issue Jun 6, 2023 · 6 comments
Open

export JULIA_NUM_THREADS=X sets nthreads(:interactive)=0 #50084

oscardssmith opened this issue Jun 6, 2023 · 6 comments
Labels
multithreading Base.Threads and related functionality

Comments

@oscardssmith
Copy link
Member

A lot of people have an exported value for JULIA_NUM_THREADS that doesn't specify a second number (because they set this up prior to 1.9). Julia 1.9 added interactive threads, but they are disabled by this line unless JULIA_NUM_THREADS manually sets a number of interactive threads. This isn't exactly a bug, but I think the better behavior would be to default to 1 interactive thread unless JULIA_NUM_THREADS=X,0 is used.

@oscardssmith oscardssmith added the multithreading Base.Threads and related functionality label Jun 6, 2023
@oscardssmith
Copy link
Member Author

(cc @kpamnany)

@kpamnany
Copy link
Contributor

kpamnany commented Jun 6, 2023

What if JULIA_NUM_THREADS is not defined? Right now, Julia will start 1 default thread and no interactive threads. Should this change?

What about the folks who have no need for interactive threads? Right now, Julia will start the number of threads they specified. With the suggested change, an interactive thread will be started when previously it wasn't and they'd have to change their setting to X,0 to get back the old behavior.

Not arguing, just pointing out that such changes will force somebody or other to make a change.

@oscardssmith
Copy link
Member Author

IMO if JULIA_NUM_THREADS isn't defined Julia should start with 1 interactive thread. The reasoning for both of these suggested changes is that the cost of having an interactive thread that you don't want (IIUC) is a couple kb of memory, while the cost of not having one when you want one is a lot more noticable.

@robsmith11
Copy link
Contributor

robsmith11 commented Jul 5, 2023

The current default behavior could be made more clear IMO.

Reading the command line docs, I had incorrectly assumed that omitting the number of interactive threads would result in 1 interactive thread being used, but apparently that's only the case if --threads *,auto is passed. What's even the point of auto for interactive threads if its synonymous with 1?

 -t, --threads {auto|N[,auto|M]}
                           Enable N[+M] threads; N threads are assigned to the `default`
                           threadpool, and if M is specified, M threads are assigned to the
                           `interactive` threadpool; "auto" tries to infer a useful
                           default number of threads to use but the exact behavior might change
                           in the future. Currently sets N to the number of CPUs assigned to
                           this Julia process based on the OS-specific affinity assignment
                           interface if supported (Linux and Windows) or to the number of CPU
                           threads if not supported (MacOS) or if process affinity is not
                           configured, and sets M to 1.

Getting slightly off topic, but it was also confusing to me that when started with --threads 8,1 the following would only use 1 thread:

julia> Threads.@threads for _ in 1:8
        while true
        end
       end

But starting with --threads 8 would use all 8 threads. Apparently because @threads will use the default pool when there are no interactive threads, but only use the interactive pool when called from the REPL. It would help if this were explained in the docs.
So I don't think 1 interactive thread would be a good default for most people.

@oscardssmith
Copy link
Member Author

I think that might be a bug in @threads

@robsmith11
Copy link
Contributor

I think that might be a bug in @threads

I've filed a separate issue: #50438

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
multithreading Base.Threads and related functionality
Projects
None yet
Development

No branches or pull requests

3 participants