Hi,

It's common knowledge that accessing tls global is slow http://david-grs.github.io/tls_performance_overhead_cost_linux/

What i do not understand is the reasoning behind choosing tls global by default in D

What i find even more weird is writing fast code is ugly in D

Look at this ugly code

__gshared int fast_code_ugly;

It should be the opposite

Slow code ugly
Fast code beautiful

What can be done about it?

Renaming __gshared

shared is even more ugly since everything must be shared afterwards

I would have prefered if i had to manually set things to tls

@tls int slow_code_ugly;

Even C does it better: https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html

Perhaps in -betterC tls vars should be annotated with @tls, and the default is not tls just like in C?

With -betterC it's broken for 3 years btw:

https://issues.dlang.org/show_bug.cgi?id=20737

On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:

__gshared int fast_code_ugly;

Because it should be rare that __gshared is used. And if you need it, you won't be worried about how the storage class looks because you'll be concentrating on if your design is thread-safe.

Then by default, @safe code can not access global variables and there can easily be accidental races between threads.

On 3/26/23 2:07 PM, ryuukk_ wrote:

If you know a variable is not shared, then you know it can only be accessed from the current thread. This has huge implications for thread access.

However, one problem that D has no good solution is passing thread-local data to another thread (to be owned by the new thread, and no access in the current thread). That's typically the most common use case for "shared data".

-Steve

On Sunday, 26 March 2023 at 18:29:17 UTC, Nick Treleaven wrote:

__gshared int fast_code_ugly;

I don't understand this argument, if my code doesn't do threads, why should i put my variable into TLS?

If i want fast code, why should i make use of ugly syntax?

On Sunday, 26 March 2023 at 19:08:32 UTC, Steven Schveighoffer wrote:

I haven't explored this use case, that must explain why i find it surprising, however, i read about other languages too, and they seem to be explicit whenever they make use of TLS

C, C++, Rust, Zig, Go doesn't do TLS by default for example

On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:

The limitations of shared can be bypassed with a "function" that removes type qualifiers. return *cast(Unqual!T*) &foo(example, doesn't work as is for arrays.)

This way shared symbols can be used with functions that cannot be made compatible with both shared and non-shared.(by cannot the exact reasons seem obscure, it may be that a called function would support shared parameters but calls a function with the parameter that does not, ime this is painfully apparent with structs' member functions)

Naturally there's the risk of concurrency issues because this isn't the language documentation-recommended way of doing things, but D's library has these problems covered.