<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 April 2014 23:17, via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thursday, 17 April 2014 at 12:20:06 UTC, Manu via Digitalmars-d wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
See, I just don't find managed memory incompatible with 'low level' realtime or embedded code, even on tiny microcontrollers in principle.<br>
</blockquote>
<br></div>
RC isn't incompatible with realtime, since the overhead is O(1).<br>
<br>
But it is slower than the alternatives where you want maximum performance. E.g. raytracing.<br></blockquote><div><br></div><div>You would never allocate in a ray tracing loop. If you need a temp, you would use some pre-allocation strategy. This is a tiny, self-contained, and highly specialised loop, that will always have a highly specialised allocation strategy.</div>
<div>You also don't make library calls inside a raytrace loop.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And it is slower and less more "safe" than GC for long running servers that have uneven loads. E.g. web services.<br></blockquote><div><br></div><div>Hey? I don't know what you mean.</div><div><br></div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it would be useful to discuss real scenarios when discussing performance:<br>
<br>
1. Web server request that can be handled instantly (no database lookup): small memory requirements and everything is released immediately.<br>
<br>
Best strategy might be to use a release pool (allocate incrementally and free all upon return in one go).<br></blockquote><div><br></div><div>Strings are the likely source of allocation. I don't think this suggests a preference from GC or ARC either way. A high-frequency webserver would use something more specialised in this case I imagine.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Web server, cached content-objects: lots of cycles, shared across threads.<br>
<br>
Best strategy is global GC.<br></blockquote><div><br></div><div>You can't have web servers locking up for 10s-100s of ms at random intervals... that's completely unacceptable.<br></div><div>Or if there is no realtime allocation, then management strategy is irrelevant.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Non-maskable interrupt: can cut into any running code at any time. No deallocation must happen and can only touch code that is consistent after atomic single instruction CPU operations.<br>
<br>
Best strategy is preallocation and single instruction atomic communication.</blockquote><div><br></div><div>Right, interrupts wouldn't go allocating from the master heap.</div><div><br></div><div><br></div><div>I don't think these scenarios are particularly relevant.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ARC would be fine in low level code, assuming the language supported it to<br>
the fullest of it's abilities.<br>
</blockquote>
<br></div>
Yes, but that requires whole program optimization, since function calls cross compilation unit boundaries frequently.</blockquote><div><br></div><div>D doesn't usually have compilation unit boundaries. And even if you do, assuming the source is available, it can still inline if it wants to, since the source of imported modules is available while compiling a single unit.</div>
<div>I don't think WPO is as critical as you say.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No. It misses basically everything that compels the change. Strings, '~',<br>
closures. D largely depends on it's memory management.<br>
</blockquote>
<br></div>
And that is the problem. Strings can usually be owned objects.<br></blockquote><div><br></div><div>I find strings are often highly shared objects.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

What benefits most from GC are the big complex objects that have lots of links to other objects, so you get many circular references.<br>
<br>
You usually have fewer of those.<br></blockquote><div><br></div><div>These tend not to change much at runtime.</div><div>Transient/temporary allocations on the other hand are very unlikely to contain circular references.</div>
<div><br></div><div>Also, I would mark weak references explicitly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Take this seriously. I want to see ARC absolutely killed dead rather than dismissed.<br>
</blockquote>
<br></div>
Why is that? I can see ARC in D3 with whole program optimization. I cannot see how D2 could be extended with ARC given all the other challenges.</blockquote><div><br></div><div>Well it's still not clear to me what all the challenges are... that's my point. If it's not possible, I want to know WHY.</div>
</div></div></div>