On 3/26/23 13:41, ryuukk_ wrote:
> C, C++, Rust, Zig, Go doesn't do TLS by default for example
C doesn't do because there was no such concept when it was conceived.
C++ doesn't do because they built on top of C.
(D does because it has always been innovative.)
Go doesn't do because it had no innovations anyway.
Does anyone have documentation on why Rust and Zip does not do thread
local by default? I wonder what experience it was based on.
Speaking of experience, I used to be a C++ programmer. We made use of
thread-local storage precisely zero times. I think it's because the
luminaries of the time did not even talk about it.
With D, I take good advantage of thread-local storage. Interestingly, I
do that *only* for fast code.
void foo(int arg) {
static int[] workArea;
if (workArea.length < nededFor(arg)) {
// increase length
}
// Use workArea
}
Now I can use any number of threads using foo and they will have their
independent work areas. Work area grows in amortized fashion for each
thread.
I find the code above to be clean and beautiful. It is very fast because
there are no synchronization primitives needed because no work area is
shared between threads.
Finding one example to the contrary does not make TLS a bad idea.
Engineering is full of compromises. I agree with D's TLS by-default idea.
Since I am here, I want to touch on something that may give the wrong
idea to newer D programmers: D does not have globals. Every symbol
belongs to a module.
And copying an earlier comment of yours:
> It's common knowledge that accessing tls global is slow
> http://david-grs.github.io/tls_performance_overhead_cost_linux/
"TLS global is slow" would be misleading because even the article you
linked explains right at the top, in the TL;DR are that "TLS may be slow".
Ali
