我正在考虑将d用于我正在进行的图形引擎。让我失望的一件事是GC。将D用于实时应用程序?
我还是一个年轻的程序员,我可能对GC有很多误解,希望你能澄清一些问题。
我的目标是低延迟和一般的时间是至关重要的。从我所知道的GC是非常不可预测的,例如我的应用程序可以每16.6ms渲染一帧,并且GC的任何时间可以上升到30ms等任何数字,因为它不是确定性的吗?
我读到你可以关闭D中的GC,但是你不能使用D的大部分标准库,并且GC没有完全关闭。这是真的?
您认为在时间关键型应用程序中使用D是否合理?
我正在考虑将d用于我正在进行的图形引擎。让我失望的一件事是GC。将D用于实时应用程序?
我还是一个年轻的程序员,我可能对GC有很多误解,希望你能澄清一些问题。
我的目标是低延迟和一般的时间是至关重要的。从我所知道的GC是非常不可预测的,例如我的应用程序可以每16.6ms渲染一帧,并且GC的任何时间可以上升到30ms等任何数字,因为它不是确定性的吗?
我读到你可以关闭D中的GC,但是你不能使用D的大部分标准库,并且GC没有完全关闭。这是真的?
您认为在时间关键型应用程序中使用D是否合理?
简短回答:它需要大量的定制,如果您不是经验丰富的D开发人员,可能会非常困难。问题
列表:
内存管理本身不是大问题。在实时应用程序中,您永远都不想在主循环中分配内存。为所有主要数据预先分配内存池是实现这种应用程序的实际标准方式。从这个意义上说,D没有什么不同 - 你仍然直接调用C malloc来为你的池获取一些堆,而这个内存不会被GC管理,它甚至不会知道它。
但是,某些语言功能和Phobos的大部分使用GC自动地。例如,如果没有某种形式的自动管理分配,就无法真正连接切片。很长一段时间里,火卫一直没有一个强有力的政策。
很少有语言触发的分配本身不会成为问题,因为大多数使用的内存都是通过池管理的。然而,股票D:中的实时软件存在一个杀手问题,默认D垃圾收集器是停止世界。即使几乎没有垃圾,当收集周期运行时,整个程序都会遇到延迟峰值,因为所有线程都会被阻塞。
可以做什么:
1)使用GC.disable();
关掉回收周期。它将解决世界各地的问题,但是现在您的程序会在某些情况下开始泄漏内存,因为基于GC的分配仍然有效。
2)转储隐藏的GC分配。有一个-vgc
交换机的请求,我现在找不到,但是如果没有,你可以编译你自己的druntime版本,打电话回拨gc_malloc()
。您可能希望将其作为自动测试套件的一部分运行。
3)完全避免火卫一,并使用https://bitbucket.org/timosi/minlibd等东西作为替代。
做所有这些应该足以满足游戏开发者典型的软实时需求,但正如你所看到的,它并不简单,并且需要逐步缺货D分布。
未来的选择:
一旦莱昂德罗Lucarella港口他concurrent garbage collector到D2(这是计划,但尚未安排),局面将变得更加简单。少量GC管理的内存+并行实施将允许即使不禁用GC也能满足软实时要求。即使Phobos在从最烦人的分配中剥离后也可以使用。但我认为这不会很快发生。
但是硬实时呢?
你最好别尝试。但这是另一个故事要讲的。
如果你不喜欢GC - 禁用它。
方法如下:
import core.memory;
void main(string[] args) {
GC.disable;
// your code here
}
自然,那么你将不得不做内存管理自己。这是可行的,并且有几篇关于它的文章。这里也讨论过,我只是不记得这个主题。
dlang.org也有关于此的有用信息。这篇文章,http://dlang.org/memory.html,触及了实时编程的主题,您应该阅读它。
从我所知道的是GC仍然会运行,即使它被禁用。你能否确认或否认这一点?如果我禁用了GC,我仍然无法使用std库的90%? –
它不会运行,因为收集周期永远不会运行,但它仍然存在,并在需要时分配内存。出于这个原因,你将能够使用std库与禁用GC,但它会泄漏地狱。 –
显然有现在是一个并发GC能极大地减少停顿和用于需要“低延迟”系统:http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ – delnan
这是利用研究项目D1;这在这里并没有什么帮助。虽然,一些讨论是相关的。 –
一个建议,因为你在学习:专注于首先完成所有事情,然后再以它的速度完成 - 前者很难独立完成! (imho,使用D有意义无论如何) – vines