Congratulations! :) Looking forward to watching your presentation at DConf... ;)

On 5/8/22 14:32, Andrea Fontana wrote:

> Every request is processed by a worker running in an isolated process,
> no fibers/threads, sorry (or thanks?)

That effectively uses multiple GCs. I always suspected that approach would provide better latency.

> sending opened file descriptors between processes thru sockets

Sweet!

Ali

On Sunday, 8 May 2022 at 22:09:37 UTC, Ali Çehreli wrote:
> Congratulations! :) Looking forward to watching your presentation at DConf... ;)

I wish I was able to speak publicly in English in front of an audience :)

>
> On 5/8/22 14:32, Andrea Fontana wrote:
>
> > Every request is processed by a worker running in an isolated
> process,
> > no fibers/threads, sorry (or thanks?)
>
> That effectively uses multiple GCs. I always suspected that approach would provide better latency.

I think it depends on what your server is doing, anyway.

>
> > sending opened file descriptors between processes thru sockets

I sent a pull request (merged!) for druntime to make this work on macOS too!

>
> Sweet!
>
> Ali

On Sunday, 8 May 2022 at 22:09:37 UTC, Ali Çehreli wrote:
> That effectively uses multiple GCs. I always suspected that approach would provide better latency.

My cgi.d has used some fork approaches for a very long time since it is a very simple way to spread this out, it works quite well.

On 5/8/22 16:10, Adam Ruppe wrote:
> On Sunday, 8 May 2022 at 22:09:37 UTC, Ali Çehreli wrote:
>> That effectively uses multiple GCs. I always suspected that approach
>> would provide better latency.
>
> My cgi.d has used some fork approaches for a very long time since it is
> a very simple way to spread this out, it works quite well.

While we are on topic :) and as I finally understood what generational GC is[1], are there any fundamental issues with D to not use one?

Ali

[1] Translating from what I wrote in the Turkish forum, here is my current understanding: Let's not waste time checking all allocated memory at every GC cycle. Instead, let's be smarter and assume that memory that survived through this GC cycle will survive the next cycle as well.

Let's put those memory blocks aside to be reconsidered only when we really have to. This effectively makes the GC only play with short-lived objects, reducing the amount of memory touched. This would make some objects live forever, but GC never promises that all finalizers will be executed.

On 09/05/2022 11:44 AM, Ali Çehreli wrote:
> While we are on topic :) and as I finally understood what generational GC is[1], are there any fundamental issues with D to not use one?

This is not a D issue, its an implementation one.

We don't have write barriers, that's it.

Make them opt-in and we can have more advanced GC's.

Oh and book recommendation for the subject: https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795

On Mon, May 09, 2022 at 12:10:53PM +1200, rikki cattermole via Digitalmars-d-announce wrote:
> On 09/05/2022 11:44 AM, Ali Çehreli wrote:
> > While we are on topic :) and as I finally understood what generational GC is[1], are there any fundamental issues with D to not use one?
> 
> This is not a D issue, its an implementation one.
> 
> We don't have write barriers, that's it.
> 
> Make them opt-in and we can have more advanced GC's.
[...]

In the past, the argument was that write barriers represented an unacceptable performance hit to D code.  But I don't think this has ever actually been measured. (Or has it?)  Maybe somebody should make a dmd fork that introduces write barriers, plus a generational GC (even if it's a toy, proof-of-concept-only implementation) to see if the performance hit is really as bad as believed to be.


T

-- 
The best way to destroy a cause is to defend it poorly.

On 5/8/22 17:25, H. S. Teoh wrote:

> somebody should make a dmd
> fork that introduces write barriers, plus a generational GC (even if
> it's a toy, proof-of-concept-only implementation) to see if the
> performance hit is really as bad as believed to be.

Ooh! DConf is getting even more interesting. :o)

Ali