On Saturday, 4 January 2014 at 07:00:28 UTC, 1100110 wrote:
But in fact it's a very small subset. Hell, it's small enough to be a *special case*.
No, real time applications are not a very small subset. Hard real-time applications are in a smaller subset, although most audio-applications for performance fall into this category.
It is however THE subset where you need the kind of low-level control that C/C++ provides and which D is supposed to provide. For non-real-time applications you can usually get acceptable performance with higher level languages, if you pick the right language for the task.
Awesome. So now to run a real-time application, you can't have any program that uses a GC running on the same machine.
Depends on the characteristics of the GC, if it is cache friendly, how many cache lines it touches per iteration and the real-time application. If you tune a tabular audio-application to full load on a single core and L3 cache size, then fast mark-sweep on a large dataset, frequent cache invalidation in the other threads and high memory-bus activity on the remaining cores is most certainly not desirable.
But yes, running multiple high-load programs in parallel is indeed problematic for most high-load real-time applications (games, audio software). And to work around that you need lots of extra logic (such as running with approximations on missed frames where possible or doing buffering based on heuristics).
