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