Using D for a real-time application?

Question

I am considering using d for my current graphics engine. The only thing that turns me on is the GC.

I am still a young programmer, and I probably have a lot of misconceptions regarding the GC, and I hope you can clarify some issues.

I strive for low latency, and time in general is critical. From what I know, it’s that the GC is quite unpredictable, for example, my application could display a frame every 16.6 ms, and when the GK turned to it, it could rise to any number, such as 30 ms, because it not determined correctly?

I read that you can disable GC in D, but then you cannot use most of the standard D library, and GC is not completely off. it's true?

Do you think it makes sense to use D in an urgent application?

Answer 1

Short answer : it requires a lot of customization and can be very difficult if you are not an experienced D. developer.

The list of problems :

Memory management is not a big problem. In real-time applications, you never want to allocate memory in the main loop. Having pre-allocated memory pools for all master data is pretty much de facto standard for such applications. In this sense, D is no different - you still call C malloc directly to get a bunch for your pools, and this memory will not be managed by GC, it won’t even know about it.

However, some language features and large parts of Phobos do use GC automatically. For example, you cannot merge fragments without any form of automatic control. And Phobos simply did not have a strong policy on this for quite some time.

The few language-related releases alone will not be a problem, since most of the memory used is managed through pools anyway. However, there is a problem with the killer for real-time software in warehouse D: the default garbage collector D is the stop world. Even if there is almost no garbage, your entire program will fall into a latent spike when you start the collection cycle, since all threads are blocked.

What can be done:

1) Use GC.disable(); to disable data collection cycles. This will solve the stop-world problem, but now your program will start a memory leak in some cases, since GC-based allocations still work.

2) Reset hidden GC allocations. There was a transfer request for the -vgc switch, which I cannot find right now, but in its absence you can compile your own version of druntime, which prints a backtrace when you call gc_malloc() . You can run this as part of an automatic test suite.

3) Avoid Phobos completely and use something like https://bitbucket.org/timosi/minlibd as an alternative.

Doing all of this should be sufficient to orientate the soft real-time requirements of the game dev, but, as you can see, this is far from simple and requires getting out of the distribution D.

Future Alternative:

Once Leandro Lucarella sends its parallel garbage collector to D2 (which is planned but not planned), the situation will become much easier. A small amount of managed GC-compatible memory + parallel implementation will satisfy the requirements in real time even without disconnecting the GC. Even Phobos can be used after it is devoid of the most annoying distributions. But I do not think that this will happen in the near future.

But what about hard real time?

Better not to try. But this is another story to tell.

Answer 2

If you do not like GC - turn it off.

Here's how:

 import core.memory; void main(string[] args) { GC.disable; // your code here } 

Naturally, then you will need to manage the memory. This is doable, and there are several articles about it. It is also discussed here, I just do not remember the thread.

dlang.org also has helpful information about this. This article, http://dlang.org/memory.html , deals with the topic of real-time programming, and you should read it.

Another good article: http://3d.benjamin-thaut.de/?p=20 .