The Future of D Runtime

[Dmitry Olshansky]

On Tuesday, 11 June 2024 at 09:25:15 UTC, Adam Wilson wrote:
> On Monday, 10 June 2024 at 09:36:14 UTC, Dmitry Olshansky wrote:
>> And on Posix libc is the systems API.
>
> For some things yes, but if you want to do anything with Async 
> I/O you're going to switch over to something like `select` or 
> `io_uring`.

Select is a system call so libc. io_uring is a system call with a 
dedicated library.

>>> Or kludges like Photon. (Don't get me wrong, Photon is a very 
>>> cool piece of work, but the nature of it's implementation 
>>> means that it suffers from the inherent limitations and 
>>> drawbacks of fibers, and does so in a highly obfuscated way.)
>>
>> I find critique of stackful coroutines really weak to be 
>> honest. Implementing n:m or 1:n threads is kernel doesn’t 
>> scale, but  combining async io with user-space fibers works 
>> beautifully. The only problem I see is stack sizes, and even 
>> there we can just reserve a lot more on x64 it’s not a problem 
>> at all.
>>
>> Java after all these years is putting lots of effort to 
>> support virtual threads,  that would be introduced along side 
>> with normal threads.
>> Go is highly popular and doing just fine without even having 
>> normal threads.
>
> That strikes me as more of an opinion than objective fact. I 
> led a detailed discussion of this topic on Discord. The end 
> result was that the stack size issue ends up being catastrophic 
> in non-trivial workloads. Vibe went with a 16MB stack size for 
> precisely this reason, which means that to handle 65536 
> simultaneous connections, I need a server with *1TB* of RAM.

Full stop right there. Virtual memory was designed precisely to 
handle cases like this, small allocations that may sometimes 
balloon to large in size. Reservation is not commit and detection 
of going out of range is quite possible on all OSes.

> The reason for that is that due to performance concerns, we 
> turn off over-commit and thus allocating 16MB per stack means 
> that you are fully committing 16MB of physical RAM.

We can allocate virtual memory lazily even with overcommit 
disabled, in such a case you would use page fault handler to 
commit memory on as faulted basis.

> Go/Java/.NET, can all handle 10x that number of connections on 
> a server with 128GB of RAM, so that's the bar we have to meet.

No problem with _reserving_ terabytes and using fraction of that. 
If the only problem is that you see memory as commited I’d be 
willing to look into why that is the case.

> No other language suffers this problem, not even Go. The reason 
> is that all languages that successfully use Fibers, use 
> dynamically expanding stacks, but this means using a precise 
> stack-scanning moving GC.

Far as I can tell Go dropped segmented stacks I cannot tell if 
they copy the stack around.

> Something that D, so long as Walter is among the living, will 
> never have.
>
> Stackless coroutines also do not suffer this problem, which is 
> why .NET and Rust use them.

The effort to introduce stackless coroutines together with 
rewriting the world to use them is enormous. The only reason 
behind Photon going as syscall wrapper is that we do not have 
resources to rewrite every C client library in say vibe.d sockets.

>> Being a system language D it allows anyone to use system APIs, 
>> meaning it’s easy to step on the toes of DRT if it uses lots 
>> of them.
>
> Can you explain what you mean? I am not sure how we'd step on 
> DRT's toes if applications use a lot of System API's?

Easy - using the same signal number for something internal or 
segfault handler.

—
Dmitry Olshansky
CEO @ [Glow labs](https://glow-labs.pro)
https://olshansky.me