Oh sure, it’s just from:
- Fast
- Small
- Concurrent
- Good cache policy
I want all of the above ![]()
The idea with thread-local storage is batching access time updates, rather than cache presence. So there shouldn’t be any spurious cache misses.
Oh sure, it’s just from:
I want all of the above ![]()
The idea with thread-local storage is batching access time updates, rather than cache presence. So there shouldn’t be any spurious cache misses.
Thanks for the answer. I understand that your planned implementation would provide this, but I am also interested in the answer in general.
That is, if eg I used a dictionary created from OhMyThreads.TaskLocalValue, how can I avoid switches like the one described above? Or is that not a concern?
Unless I’m misunderstanding you, I think the underwhelming answer is you simply need some form of thread synchronisation to make a shared concurrent cache work.
Did you really mean thread-local as opposed to task-local? Usually talking about threads in Julia is somewhat problematic since we don’t have access to them directly.
If you meant to say task-local then your concern about migrations between threads is moot ![]()
It is probably apparent that I don’t know much about these things ![]()
To make the example concrete: suppose the sketch of the computation is
using OhMyThreads
Base.@kwdef struct Foo{C}
cache::C = TaskLocalStorage{D}(() -> make_foo_dict()) # assume types are figure out
...
end
let foo = Foo(...)
tmap(_ -> do_computation(foo), 1:5) # mcmc
end
then each cache is task local so the issue is moot?
Yes I think so
Julia’s concurrency is generally build around Tasks and which thread runs a Task is somewhat of an implementation detail. That’s basically the bottomline of the (in)famous