May 18, 2021

On Monday, 17 May 2021 at 08:32:16 UTC, sighoya wrote:

>

Just a question, is anything about the GC part of the language spec of D?
Is it possible to introduce a task local GC to D in another compiler without to touch the D language?

The spec assumes GC exists if you use some features - new, arr1 ~ arr2 or associative arrays.

However, the GC is implemented in DRuntime. At least in theory, you could take another garbage collector and recompile DRuntime so it uses the foreign collector instead.

However, if write barriers are needed, you probably need to use some sort of bytecode tool to insert them to an already compiled object file, and that means malloced memory access also gets write barriers. Regular D code considers manually allocated code, static buffers and gc-allocated memory to be all the same type, handled with the same functions.

May 18, 2021

On Tuesday, 18 May 2021 at 00:09:19 UTC, zjh wrote:

>

The real enemy of the D language is there is too many people misleading.

I kept wondering if they were undercover agents from other languages.

Deliberately, to lead D language astray.

I've also thought about this

May 18, 2021

On Sunday, 16 May 2021 at 16:33:32 UTC, Ola Fosheim Grostad wrote:

>

My MAIN POINT was however that D does not have a system level management option if it does not have an option that deemed good enough for DMD. And that would be the default.

Calling free manually isnt it, because that is manual management that nobody wants to do, and not calling free is even worse.

See? Walter picked the worse option on your scale. So he has different priorities for DMD than you think he should, perhaps rightfully so.

You're asserting that if you gave Walter a good system level management option, he would use it in place of malloc/exit.

How can you know he would do that, when he already makes the "wrong" choice malloc/exit versus malloc/free?

In my opinion, DMD allocation strategy shows nothing about D, it shows something only about Walter's priorities.

May 18, 2021

On Tuesday, 18 May 2021 at 08:37:57 UTC, Dukc wrote:

>

In my opinion, DMD allocation strategy shows nothing about D, it shows something only about Walter's priorities.

Maybe so, but even then it does not change the fact that for small languages seasoned programmers will look at how the language is used in the compiler. The assumption being, it is big enough to show if the language scales well and if the language designers cannot make good use of the language features then nobody can... It is an important showcase. I've done this several times.

Second point is that language designers cannot make good language design decisions if they dont use the feature set on a larger project.

Isn't this obvious!?

May 18, 2021

I totally agree with you.

May 18, 2021

On Tuesday, 18 May 2021 at 09:10:49 UTC, Ola Fosheim Grostad wrote:

>

Maybe so, but even then it does not change the fact that for small languages seasoned programmers will look at how the language is used in the compiler.

Second point is that language designers cannot make good language design decisions if they dont use the feature set on a larger project.

Isn't this obvious!?

For the first point, no. Since you investigate the compiler of a language you're learning, I presume you're not the only one and some indeed do that.

It's not obvious for me that it's the majority of seasoned programmers, though. Compilers may be a bit too advanced for someone new to the language, one could also opt for investigating a simpler project instead, to have a quicker start.

As for the second point, why do you suspect it isn't obvious? Phobos and DUB are much more iDiomatic than DMD, so the language designers are using the whole feature set of D regardless of DMD implementation.

May 18, 2021

On Tuesday, 18 May 2021 at 09:43:08 UTC, Dukc wrote:

>

As for the second point, why do you suspect it isn't obvious? Phobos and DUB are much more iDiomatic than DMD, so the language designers are using the whole feature set of D regardless of DMD implementation.

Well, what I said is considered a norm in academic circles. So the belief that compilers is a show case is not uncommon.

I would never judge a standard library as they tend to be affected by issues related to code gen and OS. The standard library is kinda part of the compiler backend and runtime. It is common for standard libs to be unidiomatic.

May 18, 2021

On Tuesday, 18 May 2021 at 09:47:45 UTC, Ola Fosheim Grostad wrote:

>

Well, what I said is considered a norm in academic circles. So the belief that compilers is a show case is not uncommon.

I would never judge a standard library as they tend to be affected by issues related to code gen and OS. The standard library is kinda part of the compiler backend and runtime. It is common for standard libs to be unidiomatic.

So, if I understood right you're criticizing DMD implementation, not D memory management options?

May 18, 2021

On Tuesday, 18 May 2021 at 10:11:10 UTC, Dukc wrote:

>

On Tuesday, 18 May 2021 at 09:47:45 UTC, Ola Fosheim Grostad wrote:

>

Well, what I said is considered a norm in academic circles. So the belief that compilers is a show case is not uncommon.

I would never judge a standard library as they tend to be affected by issues related to code gen and OS. The standard library is kinda part of the compiler backend and runtime. It is common for standard libs to be unidiomatic.

So, if I understood right you're criticizing DMD implementation, not D memory management options?

There should be other options, but if you have a solution for DMD then it would be expexted to be enabled by default. If it isn't, how can you expect pergformance conscious system level programmers to think there is an good solution available? Show not tell...

May 18, 2021

On Tuesday, 18 May 2021 at 10:29:24 UTC, Ola Fosheim Grostad wrote:

>

On Tuesday, 18 May 2021 at 10:11:10 UTC, Dukc wrote:

>

On Tuesday, 18 May 2021 at 09:47:45 UTC, Ola Fosheim Grostad wrote:

>

Well, what I said is considered a norm in academic circles. So the belief that compilers is a show case is not uncommon.

I would never judge a standard library as they tend to be affected by issues related to code gen and OS. The standard library is kinda part of the compiler backend and runtime. It is common for standard libs to be unidiomatic.

So, if I understood right you're criticizing DMD implementation, not D memory management options?

There should be other options, but if you have a solution for DMD then it would be expexted to be enabled by default. If it isn't, how can you expect pergformance conscious system level programmers to think there is an good solution available? Show not tell...

And to avoid any misunderstanding I think that a GC ought to be good enough for a single threaded batch compiler, but you would need to measure using stress tests to find when performance deteriorates and by how much.