On 29/10/2022 11:13 PM, Imperatorn wrote:
> It's more like a challenge 😎

It's dangerous to go alone! Take this.

https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795

https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508

On Saturday, 29 October 2022 at 10:17:28 UTC, rikki cattermole wrote:
> On 29/10/2022 11:13 PM, Imperatorn wrote:
>> It's more like a challenge 😎
>
> It's dangerous to go alone! Take this.
>
> https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795
>
> https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508

Thanks, I'll look into those

On 10/29/2022 3:04 AM, IGotD- wrote:
> No they can't because D doesn't have a built in managed pointer type and they are limited to a subset of GC algorithms (even limited among the tracing GC ones).
> 
> It is possible to use a library custom GC type but then runtime/phobos don't use these so replacing the GC in the entire program isn't possible.
> 
> Many have tried to explain this numerous times but you just ignore this obvious fact.

I didn't ignore it.

I've pointed out the problems with two hierarchies of pointers many times. I lived with it for years in the DOS world. It's a mess, and was only used on DOS out of desperation.

I know about C++/CLI. No thanks.

On Saturday, 29 October 2022 at 10:25:20 UTC, Imperatorn wrote:
> On Saturday, 29 October 2022 at 10:17:28 UTC, rikki cattermole wrote:
>> On 29/10/2022 11:13 PM, Imperatorn wrote:
>>> It's more like a challenge 😎
>>
>> It's dangerous to go alone! Take this.
>>
>> https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795
>>
>> https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508
>
> Thanks, I'll look into those

https://libgen.rs

Matheus.

On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:
>
> 2. Choice is nice. For example, I prefer to use the GC for initialization work, and the inner loop gets manual allocation. I get the best of both.

Yes.

I've been working on fast programs all my professional life.
Say you want top performance.
You would go ASICs.
But it's impractical so you could go FPGA.
But it's impractical so you could go GPGPU.
But it's impractical so you decide to go native.

One already traded a lot of speed for convenience, and THEN decide one need every last performance bit. This is a _common_ scenario, though not necessarily a reasonable one.

So let's say you were tasked to make one program as fast as possible, native on the CPU.

Seen from afar, this GC thing will be a tiny blip on the radar of everything that could make your program a bit slower: disk caches, network, memory bandwidth, maxing threading, compiler bugs... and of course the much larger risk of breaking the program with failed optimizations.

It is easy to make things fast even with the D GC. You just have to optimize if it is a problem, move it out of GC. Grow buffers, use realloc(), etc. It is the same you would have done in other native languages. This doesn't just rule out the stdlib, it also rules out almost any other library not written with the performance goal.

Thankfully we have @nogc, -betterC, -profile=gc, and whatnot. AFAIK people of D are using to push the boundaries and have fast things. I would wager it's not the biggest challenge of all to deal with the GC - or to avoid it. Perhaps harder in a team?

The GC is an extension that allows programs that can afford a GC (most) to be written faster.

It is the default, because most programs don't begin their lives with a need to be fast, or correct, but mostly to be written quickly! always-has-been.gif

Write gates are inherently "not-native", like integer overflow checks and boundscheck that you can't remove. It is one more invariant to maintain for the system programmer, for something that would couple things way beyond the druntime it was made for. It is surprising it is pushed so often with zero use cases.

On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:
>
> I didn't ignore it.
>
> I've pointed out the problems with two hierarchies of pointers many times. I lived with it for years in the DOS world. It's a mess, and was only used on DOS out of desperation.
>
> I know about C++/CLI. No thanks.

Your analogy with bizarre addressing modes and HW limitation of early x86 processors doesn't make any sense. Also, the design with far/near pointers in those compilers is questionable and further fuels the point that pointers need to be opaque and the compiler should deal with such mess.

None the less the argument with far/near to totally irrelevant today has nothing to do with the managed/raw pointer separation. You fail to understand that this limits the usage of the D language and thusly fails to become a general purpose system language that can suit different needs. This is one of the problems with the D project that you limit further evolution of the language using obvious flawed arguments. The results of that is clear, that D doesn't in increase in popularity.

On Saturday, 29 October 2022 at 11:10:20 UTC, matheus wrote:
> On Saturday, 29 October 2022 at 10:25:20 UTC, Imperatorn wrote:
>> On Saturday, 29 October 2022 at 10:17:28 UTC, rikki cattermole wrote:
>>> On 29/10/2022 11:13 PM, Imperatorn wrote:
>>>> It's more like a challenge 😎
>>>
>>> It's dangerous to go alone! Take this.
>>>
>>> https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795
>>>
>>> https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508
>>
>> Thanks, I'll look into those
>
> https://libgen.rs
>
> Matheus.

❤️

On Saturday, 29 October 2022 at 11:39:14 UTC, IGotD- wrote:
> On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:
>> [...]
>
> Your analogy with bizarre addressing modes and HW limitation of early x86 processors doesn't make any sense. Also, the design with far/near pointers in those compilers is questionable and further fuels the point that pointers need to be opaque and the compiler should deal with such mess.
>
> [...]

What solution do you propose?

On Saturday, 29 October 2022 at 11:59:24 UTC, Imperatorn wrote:
>>
>> Your analogy with bizarre addressing modes and HW limitation of early x86 processors doesn't make any sense. Also, the design with far/near pointers in those compilers is questionable and further fuels the point that pointers need to be opaque and the compiler should deal with such mess.
>>
>> [...]
>
> What solution do you propose?

For D or ancient C compilers?

On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:
> I've pointed out the problems with two hierarchies of pointers many times.

D already has several kinds of pointers. T*, const(T)*, shared(T)*. I don't see how unmanaged(T*) is any different.

In fact, I sketched up some thoughts i might put in the blog monday but the short of it is you could:

* -ptrcheck=[none|barrier] argument to the compiler, similar to how -checkaction and -boundscheck can be modified.

* all pointer writes assumed to be barriered except ones marked raw/unmanaged/whatever, which is a qualifier similar to const and shared

* the raw pointer would essentially be struct raw(T) { T it; alias it this; void opAssign(T rhs) { barrier(); it = rhs; } }

* possible optimizations would be eliding the barrier in cases like `a = a[1 .. $]` because you know - thanks to the bounds check - that this refers to the same memory block anyway and is thus irrelevant to the GC wrt marking. I guess it can be trouble if it wants to move tings in the middle of the slice operation though.


I'm not convinced this is impossible.

(btw im also not convinced it is necessary, i think D's gc is good enough as it is.)