On Monday, 27 March 2023 at 08:44:41 UTC, wjoe wrote:
> e.g.: It used to be faster to ...
>
> - pre-calculate sin/cos tables, now the memory look up cost more cycles than the calculation itself
>
...
> - only redraw the parts of the screen that changed, now the branching is slower than to  redraw everything

Good to know, thanks.

> another example is sorting - Alexei wrote a blog post about how a stupid and slow sorting algorithm now performs better in multi threading. Maybe someone remembers the title/url of the post ?

Not sure, but that reminds me of Andrei's blog on partitioning (for quicksort):
https://dlang.org/blog/2020/05/14/lomutos-comeback/

The algorithm traditionally considered slower can be faster because it can be optimized to work better with branch prediction.

On Friday, 31 March 2023 at 10:32:53 UTC, Nick Treleaven wrote:
> On Sunday, 26 March 2023 at 20:36:37 UTC, ryuukk_ wrote:
>> Golang doesn't even have thread local storage, yet they do very well
>
> Go doesn't have a solution to preventing data races at compile time, they just say don't share memory. But what if you accidentally share memory? That is *very* easy to do in Go. You and your users are out of luck. All you can do is run the race detector and pray that you happen to test all the code paths with it that might have data races:
>
>> The race detector only finds races that happen at runtime, so it can't find races in code paths that are not executed
>
> https://go.dev/doc/articles/race_detector

If you want TLS in GO, you specify that you need a TLS variable, just like every sane languages

Go went the smart route on top of having goroutines, making it superior to what ever D offer

On Sunday, 26 March 2023 at 18:25:54 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Having TLS by default is actually quite desirable if you like your code to be safe without having to do anything extra.
>
> As soon as you go into global to the process memory, you are responsible for synchronization. Ensuring that the state is what you want it to be.
>
> Keep in mind that threads didn't exist when C was created. They could not change their approach without breaking everyone's code. So what they do is totally irrelevant unless its 1980.
>
> I think its the correct way around. You can't accidentally cause memory safety issues. You must explicitly opt-into the ability to mess up your programs state.

I think "safe" BS is going too far. Normally you don't use global variables at all but if you do the most usual is to use normal global variables with perhaps some kind of synchronization primitive. TLS is quite unusual and having TLS by default might even introduce bugs as the programmer believes that the value can be set by all threads while they are independent.

Regardless, __gshared in front of the variable isn't a huge deal but it shows that the memory model in D is a leaking bucket. Some compilers enforce synchronization primitives for global variables and are "safe" that way. However, sometimes you don't need them like in small systems that only has one thread and it just gets in the way.

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.

On Sunday, 26 March 2023 at 18:25:54 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Having TLS by default is actually quite desirable if you like your code to be safe without having to do anything extra.
>
> As soon as you go into global to the process memory, you are responsible for synchronization. Ensuring that the state is what you want it to be.
>
> Keep in mind that threads didn't exist when C was created. They could not change their approach without breaking everyone's code. So what they do is totally irrelevant unless its 1980.
>
> I think its the correct way around. You can't accidentally cause memory safety issues. You must explicitly opt-into the ability to mess up your programs state.

I think "safe" BS is going too far. Normally you don't use global variables at all but if you do the most usual is to use normal global variables with perhaps some kind of synchronization primitive. TLS is quite unusual and having TLS by default might even introduce bugs as the programmer believes that the value can be set by all threads while they are independent.

Regardless, __gshared in front of the variable isn't a huge deal but it shows that the memory model in D is a leaking bucket. Some compilers enforce synchronization primitives for global variables and are "safe" that way. However, sometimes you don't need them like in small systems that only has one thread and it just gets in the way.

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.