On Saturday, 1 April 2023 at 08:47:54 UTC, IGotD- wrote:
>
> TLS by default is mistake in my opinion and it doesn't really help. TLS should be discouraged as much as possible as it is complicated and slows down thread creation.

It looks like a mistake if we consider none of the D-inspired languages have stolen TLS-by-default.

On Saturday, 1 April 2023 at 13:11:46 UTC, Guillaume Piolat wrote:
> TLS could be explicit and we wouldn't need a -vtls flag.

Yeah, I think what we should do is make each thing be explicitly marked.

When I want tls, I tend to comment that it was intentional anyway to make it clear I didn't just forget to put a shared note on the static.

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

On 4/1/23 17:02, Ali Çehreli wrote:
> 
> Does anyone have documentation on why Rust and Zip does not do thread local by default?

Rust just does not do mutable globals except in unsafe code.

On Saturday, 1 April 2023 at 15:02:12 UTC, Ali Çehreli wrote:
>
> Does anyone have documentation on why Rust and Zip does not do thread local by default? I wonder what experience it was based on.
>

I think that would hard to get documentation on the rationale for that decision. Maybe you can get an answer in their forums but I doubt it. For Rust I think they based it on that globals should have some kind of synchronization which is enforced at compile time. Therefore TLS becomes second citizen.

> 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.
>

Yes, that's "normal" programming that you more or less never use TLS.

> 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.
>

There is nothing beautiful with it other than the clean syntax. Why not just use a stack variable which is thread local as well. TLS is often allocated on the stack in many systems anyway. Accessing TLS variables can slower compared to stack variables. The complexity of TLS doesn't pay for its usefulness.

>
> > 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".

This depends how it is implemented. TLS is really a forest and can be implemented in many ways and it also depends where it is being accessed (shared libraries, executable etc.). In general TLS on x86 is accessed by fs:[-offset_to_variable] this isn't that slow but the complexity to get there is high. Keep in mind the TLS area must be initialized for every thread creation which isn't ideal. fs:[] isn't always possible and a function call is required similar to a DLL symbol look up. TLS is a turd which shouldn't have been created. They should have stopped with key/value pair which languages then could build on if they wanted. Now TLS are in the executable standards and it is a mess. x86 has now two ways of TLS (normal and TLS_DESC) just to make things even more complicated. A programmer never see this mess but as systems programmer I see this and it is horrible.