<div dir="ltr">On 10 April 2013 21:18, Paulo Pinto <span dir="ltr"><<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wednesday, 10 April 2013 at 09:15:26 UTC, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 10 April 2013 19:07, Dicebot <<a href="mailto:m.strashun@gmail.com" target="_blank">m.strashun@gmail.com</a>> wrote:<br>
<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday, 10 April 2013 at 08:57:55 UTC, Manu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That sounds horribly non-deterministic. What if you have 256mb of ram, and<br>
no pagefile, and you fill it up till you have 1mb headroom spare?<br>
<br>
</blockquote>
<br>
It is Erlang, it is not meant to be run on 256Mb RAM ;) It kind of solves<br>
the issue of response latency for GC-enabled software on powerful<br>
enterprise servers. Because with stop-the-world GC you can't do it, does<br>
not matter how powerful your hardware is.<br>
<br>
Does not help game dev and small-scale embedded though, that for sure ;)<br>
<br>
</blockquote>
<br></div></div><div class="im">
Well there's always the standing question though, why is JVM and C# so much<br>
faster than D?<br>
They produce a squillion times more garbage than D, yet they're much much<br>
faster. I have come to accept the C# GC in less-intensive realtime<br>
software, it's not so bad.<br>
</div></blockquote>
<br>
First of all they require the use of safe references. Pointer manipulation is reserved to unsafe regions, which allows for more aggressive GC algorithms.<br>
<br>
Secondly you have years of GC research invested into those runtimes.<br>
<br>
Finally they don't offer a single GC, but tunable versions.<br>
<br>
Additionally the garbage might be less than what you think, because you may use "new" but the JIT will actually do a stack allocation if it sees the object will be dead at the end of scope.<br></blockquote><div>
<br></div><div style>Good point. It'd be really great if D implemented optimisations of this sort too one of these days. There's a lot of such opportunities waiting for some attention. I'd be very interested to see what sort of practical difference they make.</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">
Some Java related information,<br>
<a href="http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html" target="_blank">http://www.oracle.com/<u></u>technetwork/java/javase/tech/<u></u>g1-intro-jsp-135488.html</a><br>
<a href="http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html" target="_blank">http://docs.oracle.com/javase/<u></u>7/docs/technotes/guides/vm/<u></u>performance-enhancements-7.<u></u>html</a><br>
</blockquote></div></div></div>