After reading the WIP blogpost https://github.com/JuliaLang/www.julialang.org/pull/1904 , I’m trying to adapt to the new recommended approach to multithreading, now that tasks can migrate between threads. I would like to get some confirmation that I’m understanding the new recommendation correctly. A…

For completeness, this would be the type of Channel-based solution suggested by @lmiq in the other thread function build_solvers(nsolvers = nthreads()) solvers = Channel{Solver}(nsolvers) for _ in 1:nsolvers put!(solvers, Solver()) end return solvers end function solve(solvers, inputs; numbe…

Thanks! Very useful, I just replied over there too. It would seem that your suggestion of using a Channel with the desired number of solvers would be ideal… as long as taking and putting them back into the channel does not have a huge overhead. It seems to be only like 91 ns in my computer.

The use of Iterators.partition is not ideal for this task, because it may partition in uneven number of tasks per chunk, for example: julia> length.(Iterators.partition(1:10,4)) 3-element Vector{Int64}: 4 4 2 which is why I wrote the (simple but convenient) ChunkSplitters package, which will re…

[image] pablosanjose: Question 1: If number_of_chunks = nthreads(), aren’t the two approaches equivalent? If number_of_chunks > nthreads() we should get some degree of load balancing with the second approach, which is nice. However we also increase the number of Solver() copies, which is not so…

[image] pablosanjose: For completeness, this would be the type of Channel-based solution suggested by @lmiq in the other thread function build_solvers(nsolvers = nthreads()) solvers = Channel{Solver}(nsolvers) for _ in 1:nsolvers put!(solvers, Solver()) end return solvers end function so…

[image] Mason: I’d be interested to hear if anyone explores the relative tradeoffs. There is a small test here: FLoops @init allocate only once - #13 by lmiq Channels have a small, but noticeable, overhead, which may or may not be important depending on the application. (although that is not…

[image] lmiq: (You could do the same with @sync and @spawn, but there would be no advantage here. To improve load balancing you can simply increase the number of chunks (or use the :scatter chunking option if there is a correlation between the index of the task and its cost) Note that @thread…

That comment specially refers to spawning tasks for a limited number of chunks, defined manually (or using ChunkSplitters). If the number of chunks is equal to the number of available threads, there will be no difference between using @threads or @spawn. To gain some load balancing we need to have m…

How to use many (non-sticky) tasks while maximizing local storage reuse?

General Usage

lmiq June 13, 2023, 12:16pm 2

I think you can get all alternatives here: Multithreading with shared memory caches

1 Like

Topic		Replies	Views
No more threadid indexing? [thread-local storage] Performance multithreading , threads	36	1371	August 15, 2025
Multithreading with shared memory caches Performance question , performance , multithreading	27	2133	June 13, 2023
Question on TaskLocalValue Performance multithreading	10	401	March 4, 2024
Behavior of threads General Usage multithreading	33	1920	March 24, 2023
How to spawn persistent threads and reuse them? Performance parallel , multithreading , sparse	16	372	February 17, 2025

How to use many (non-sticky) tasks while maximizing local storage reuse?

Related topics