April 02

On Monday, 1 April 2024 at 20:45:25 UTC, Adam Wilson wrote:

>

We need to accept a fact that I learned at DConf 2017, the no-GC crowd will not be silenced until the GC is removed from the language. However, Walter has said the GC is here to stay. Therefore, the no-GC crowd will never be silenced. We've given them a plethora of tools to work without the GC. It is time that we stopped giving them so much our time. We have bigger problems to solve.

The problem is viewing people using @nogc as doing out of performance fetish, when really it makes no performance difference meaningfully (2x memory consupmtion usually "ok").

Instead the Mir library, Dplug, Hipreme Engine and soon Inochi2D are doing it simply for portability because the regular druntime has insane requirements, which the C standard library doesn't have. We went "@nogc" when druntime wouldn't even start in some macOS in shared library form, not because some kind of performance reason.

If you want to use GC and be portable, then (currently in D today) you have to write your own D runtime. Of which there is 3 or 4 custom ones!

The solution is of course to lower the requirements of druntime so that it can run anywhere, be in WebASM, on the Playstation Vita, on the Dreamcast, what people are doing nowadays (and may need or not @nogc).

April 02

Perhaps I misunderstood GP post, indeed now there are many many tools to work with the GC better, profile it, avoid it, and it has gone faster in silent ways even.

April 03
On 03/04/2024 2:23 AM, Guillaume Piolat wrote:
> If you want to use GC and be portable, then (currently in D today) you have to write your own D runtime. Of which there is 3 or 4 custom ones!

And worse still they each have to implement the compiler hooks, when all they really need to implement is stuff like allocation of memory!

Locking people into a specific compiler version makes peoples lives harder than it needs to be.

Split the hooks out, into a compiler adjacent library with a well defined API for runtimes to implement will make custom runtime writers lives a lot easier.

It'll also mean faster builds since less stuff is in object.d so lots of wins here.
April 02
On Wed, Apr 03, 2024 at 03:50:19AM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 03/04/2024 2:23 AM, Guillaume Piolat wrote:
> > If you want to use GC and be portable, then (currently in D today) you have to write your own D runtime. Of which there is 3 or 4 custom ones!
> 
> And worse still they each have to implement the compiler hooks, when all they really need to implement is stuff like allocation of memory!
> 
> Locking people into a specific compiler version makes peoples lives harder than it needs to be.
> 
> Split the hooks out, into a compiler adjacent library with a well defined API for runtimes to implement will make custom runtime writers lives a lot easier.

Yes, undocumented compiler hooks are a big barrier to adaptability. This needs to be refactored.  Right now there are tons of undocumented conventions and hooks that you basically have to do trial-and-error to discover.  This needs to be documented and refactored to a proper API instead.


> It'll also mean faster builds since less stuff is in object.d so lots of wins here.

Yeah while getting my D code to run in wasm, I discovered that there's a lot of stuff in object.d that actually only matters to druntime backend code. Would be nice to get rid of this stuff.

Though tbh you probably won't see very much improvement in build times here; object.d is pretty low down on the list of druntime/phobos modules that hog compile time. The gains probably won't be noticeable in non-trivial projects.


T

-- 
Two wrongs don't make a right; but three rights do make a left...
April 02

On Tuesday, 2 April 2024 at 15:31:25 UTC, H. S. Teoh wrote:

>

Though tbh you probably won't see very much improvement in build times here; object.d is pretty low down on the list of druntime/phobos modules that hog compile time. The gains probably won't be noticeable in non-trivial projects.

cd /usr/include/dlang/dmd
time dmd -o- object.d
dmd -o- object.d  0.03s user 0.00s system 98% cpu 0.030 total

There's only 30 ms to save here.

April 03
On 03/04/2024 8:54 AM, Dennis wrote:
> On Tuesday, 2 April 2024 at 15:31:25 UTC, H. S. Teoh wrote:
>> Though tbh you probably won't see very much improvement in build times here; object.d is pretty low down on the list of druntime/phobos modules that hog compile time. The gains probably won't be noticeable in non-trivial projects.
> 
> 
> ```
> cd /usr/include/dlang/dmd
> time dmd -o- object.d
> dmd -o- object.d  0.03s user 0.00s system 98% cpu 0.030 total
> ```
> 
> There's only 30 ms to save here.

That is not what is of interest.

Its symbol lookup of other modules falling back on object.d.
April 03
On Tuesday, 2 April 2024 at 14:50:19 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 03/04/2024 2:23 AM, Guillaume Piolat wrote:
>> If you want to use GC and be portable, then (currently in D today) you have to write your own D runtime. Of which there is 3 or 4 custom ones!
>
> And worse still they each have to implement the compiler hooks, when all they really need to implement is stuff like allocation of memory!
>

Is this the reason why there is no D for Arduino?

(Which would be a big + in terms of popularity).

April 04

On Monday, 1 April 2024 at 20:45:25 UTC, Adam Wilson wrote:

>

The discourse around the GC has gotten so ridiculous that I have seriously considered asking Walter to declare that "If you want to create an OS or Video Game, consider a different language."

OS/Games is actually a fairly uncommon use of D, if you look at what the people who aren't whining endlessly about the GC are actually doing with it.

Personally, I blame the OS/Game crowd for single-handedly keeping D out of the web service space for the past decade because, instead of improving the GC to the point that long-running processes are possible, we've built a mountain of (mis)features designed to assuage their demands. I maintain that this was probably the second biggest mistake in D's history.

"We'd have the programming Utopia if only all the goddamn users stopped getting in the way!"

Seriously though, what an asinine opinion. Excluding an entire market, to satisfy your religious opinions on memory management. Nobody has stopped anyone from improving the GC. By all means, please improve the GC. I develop commercial games in D, I have come to avoid the GC much of the time, and I'm pretty sure I haven't spent any of the past 10 years of my workload getting in your way of making the GC the best it could be. I simply haven't been using it. Oh no, someone exposed GC.free and __delete as a hacky temporary stopgap? Gosh, that 30 seconds of work sure did get in the way of a decade of someone else making that thing I want better.

In my opinion, a language that can't handle modern 60+ fps (144-240+ nowadays) gaming or graphical simulations is nothing more than a hobbyist piece of crap and not fit for business. But that's just my opinion... I don't try to force it on anyone else ;) I'm aware other industries exist and we can all graze on our respective farms in peace.

Fortunately, there's numerous ways to get around the problems of stop-the-world GC skips, even working within the GC. It takes a tiny bit of thought, and a document was drafted to suggest these techniques to newcomers, though nobody strained themselves with effort over this since, naturally, the doc wants to sell you his favorite pills. Fair enough. Even so, it is the natural philosophy and developmental style of many to simply avoid the GC. You can either react to this with "different strokes", or you can go full zealot and start holding inquisitions for all the blasphemers.

It actually takes very little effort to please the detmem crowd by just giving them the basic tools they want, compared to trying to sell them on broad spectrum cure-all GC liniment when the seller's approach is "Just use it! Just use it already damnit stop asking questions! No refunds!" and is brazenly ignorant of how much of an issue naive GC use can be for particular situations. D actually HAS gone and given them the tools they need, albeit they don't come in the same nice shiny box as the GC. They're just kind of handed out in plastic baggies. But hey, that's how Ultima sold 50,000 copies before Richard's net worth clapped $1.5B.

In a world where the gold standard of technology is "It Just Works", D's GC... doesn't Just Work. Oh, It DOES Work. It just Works With Effort. And that's a problem you've had 10 years to do something about. What has been done besides paint the church and hand out a lot of fliers?

April 04

On Tuesday, 2 April 2024 at 13:23:48 UTC, Guillaume Piolat wrote:

>

Instead the Mir library, Dplug, Hipreme Engine and soon Inochi2D are doing it simply for portability because the regular druntime has insane requirements, which the C standard library doesn't have. We went "@nogc" when druntime wouldn't even start in some macOS in shared library form, not because some kind of performance reason.

If you want to use GC and be portable, then (currently in D today) you have to write your own D runtime. Of which there is 3 or 4 custom ones!

The solution is of course to lower the requirements of druntime so that it can run anywhere, be in WebASM, on the Playstation Vita, on the Dreamcast, what people are doing nowadays (and may need or not @nogc).

This is a very reasonable take, and I can understand how supporting different platforms might result in needing to abandon features that rely on DRT, especially given the difficultly in porting. And I would generally agree with DIP's and PR's that move us in that direction. Rikki has some ideas there.

In general though, I think it is reasonable for us to say that if you expect D to work fully on a new platform, that you're going to have to fully port DRT.

And I don't have a problem with the existing no-GC features. I just think that we need to deprioritize no-GC so that our precious few resources can be spent addressing the problems we have with the GC and open-up new markets for D.

April 04
On 03/04/2024 10:28 PM, rkompass wrote:
> On Tuesday, 2 April 2024 at 14:50:19 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 03/04/2024 2:23 AM, Guillaume Piolat wrote:
>>> If you want to use GC and be portable, then (currently in D today) you have to write your own D runtime. Of which there is 3 or 4 custom ones!
>>
>> And worse still they each have to implement the compiler hooks, when all they really need to implement is stuff like allocation of memory!
>>
> 
> Is this the reason why there is no D for Arduino?
> 
> (Which would be a big + in terms of popularity).

No. Although it hasn't helped.

Micro's tend to be on the small size, all the extra metadata you need for D code like ModuleInfo and TypeInfo could easily exceed that budget or bump you up into one of the more expensive micros killing D off as a possible language.

About the max you'd want here is -betterC which already works.