I have a 6 Core MacBook Pro running Ventura (OS X 13) and when I launch Julia directly from the command line I have access to all 12 CPU threads for multithreading. When I launch Julia in VS Code, I can only get up to 6 threads… I have attached some screen shots to show the differences. Am I missing something obvious?
1 Like
What is your threads value in the VSCode settings?
Or how do you start each Julia instance?
I’ve set the number of threads in the Julia extension to 12 and auto as well as used Julia -t 12 and julia -t auto, doesn’t seem to make a difference. I installed the Julia cask using homebrew and from the command line start by just typing julia. In VS Code I have tried starting it using the Julia extension as well as opening a standard terminal and again typing julia. In the screenshots I posted, I did not specify the number of threads when launching julia.
And have you checked if it is not a VSCode thing? Like checking in plain terminal what the number of cores/threads is available?
If I’m not mistaken, VSCode has it’s own terminal emulation, maybe that is causing problems and limits what Julia sees?
Yeah, I just checked that using sysctl -n hw.ncpu and python -c 'import multiprocessing as mp; print(mp.cpu_count())' in the VS Code terminal, both returned 12. Happy to check using other methods as well, if you have any suggestions
So I grabbed my old Macbook (with 2-core Intel i5, iOS 12.6) and can confirm that in VSCode Julia reports 2 threads, while outside it is 4 (Sys.CPU_THREADS).
However, the threading module (Threads.nthreads())shows 4 threads when I start Julia with the proper parameter.
Maybe there is something off with the Sys module?
Do you have some code to test how many threads Julia is actually using?
So I first started investigating because Threads.nthreads() was showing the correct number of threads (i.e if I set it to 12 Threads.nthreads() returned 12). But when I was actually running the code and inspecting the CPU usage via htop I noticed that it never used more than 6… Granted my check was kind of crude, but the julia process topped out at ~580% CPU usage and only 6 “cores” ever showed elevated usage in the charts
Is this happening for all Julia sessions opened within VS Code, or only those in the integrated REPL?
It seems to be all of them. It doesn’t matter if I launch julia using the julia extension or the terminal within VS Code. I might be misunderstanding your question though…?
I share this exact issue, but with Julia v. 1.7.2 on a much older quadcore MacBook running Monterrey.
Anybody with this problem find a solution? I have tried “ignored settings” from
here and it can confirm this did not work. I have no idea what to do. Threads.nthreads() is 8, but I use Sys.CPU_THREADS is 4 and the CPU usage rarely breaks 400%. when I Threads.@threads 
How many cores does your machine have? If it’s 4, then the other 4 reported threads come from hyperthreading/SMT and aren’t going to be adding much. That may explain why you can’t go beyond 400% (not just in Julia, but any program).
Yeah, this seems like this would generally be the better default.
When for instance Julia is ||-compiling things in the terminal, it maxes things out and the fans blare and I hit 800%, and Threads.threads in VS code is much easier on the chip and I often don’t break 300%.
Maybe it’s heavy allocs in computations limiting the hyper-threading? I’ll see if I can get a clearer MWE. Sorry for the lazy post.
By “the terminal” I presume you mean a separate REPL and not the one integrated with VS Code? One thing to try is running your code in a non-VS Code REPL and checking the usage there. I’d also recommend posting the output of versioninfo() here because it shows your processor model + the number of virtual cores.
Thanks for the hint. Here’s a little function for testing ||-ism and the central limit theorem
function test_parallel(n)
out = zeros(n)
Threads.@threads for ii in 1:n
for jj in 1:10^8
out[ii] += rand()
end
end
return sum(out)
end
you can see what happens when I run in my terminal with 8 threads. CPU running hot.
now from vs code
Sure its only 5% slower for this case, I guess the hyperthreading really is overrated Intel marketing, but you are right the versioninfo is different: 4 virtual cores from VScode. That’s quite mysterious to me. I hope this helps.
If it’s actually better to use half the threads (likely), then shouldn’t that be the case outside of VS Code with julia -t auto too (at least you could override with, for you, -t 8)?
I don’t really mind too much what the default is, if it’s the better default (for most cases). Still could it in some cases be better to have access to all threads? Might it be best for -t auto to allocate as many threads as virtual cores, then still limit you to half of them by default (and you could optionally in code ask for the dormat hyperthreads to be used too?).
I’m just thinking if you’re limited to half by default, then currently there’s no easy way to add more at runtime. On master there’s a new option to add “foreign threads” (from C), so seemingly a workaround…
If you mean (full) 8 threads, then compiling forks n single-threaded processes, in effect that (or in general Distributed) is an exception, but unclear to me it should use as many, or also be limited to the non-hyperthreads.