Microsoft working on new systems language

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Fri Jan 3 23:28:58 PST 2014


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).


More information about the Digitalmars-d mailing list