Microsoft working on new systems language

1100110 0b1100110 at gmail.com
Fri Jan 3 23:00:24 PST 2014


On 12/29/2013 02:47 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Sunday, 29 December 2013 at 20:36:27 UTC, Walter Bright wrote:
>> I'll reiterate that the GC will NEVER EVER pause your program unless
>> you are actually calling the GC to allocate memory. A loop that does
>> not GC allocate WILL NEVER PAUSE.
>
> That's fine, except when you have real-time threads.
>
I'm always astounded how often real-time anything gets thrown around.

Yeah sure, some programs are under time constraints.  But from the way 
everyone freaked out you'd think *all* programs are real-time.

But in fact it's a very small subset.  Hell, it's small enough to be a 
*special case*.

> So unless you use non-temporal load/save in your GC traversal (e.g. on
> x86 you have SSE instructions that bypass the cache), your GC might
> trash the cache for other cores that run real-time threads which are
> initiated as call-backs from the OS.

Awesome.  So now to run a real-time application, you can't have any 
program that uses a GC running on the same machine.
Somehow I don't think that is grounded in reality.


> These callbacks might happen 120+ times per seconds and your runtime
> cannot control those, they have the highest user-level priority.
>
> Granted, the latest CPUs have a fair amount of level 3 cache, and the
> most expensive ones might have a big level 4 cache, but I still think it
> is a concern. Level 1 and 2 caches are small: 64KB/128KB.




More information about the Digitalmars-d mailing list