On Tue, Mar 6, 2012 at 5:27 AM, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On 26 February 2012 00:55, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 2/25/2012 2:08 PM, Paulo Pinto wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Most standard compiler malloc()/free() implementations are actually slower than<br>
most advanced GC algorithms.<br>
</blockquote>
<br></div>
Most straight up GC vs malloc/free benchmarks miss something crucial. A GC allows one to do substantially *fewer* allocations. It's a lot faster to not allocate than to allocate.<br></blockquote><div><br></div></div>
<div>Do you really think that's true? Are there any statistics to support that?</div>
<div>I'm extremely sceptical of this claim.</div><div><br></div><div>I would have surely thought using a GC leads to a significant <b>increase</b> in allocations for a few reasons:</div><div> It's easy to allocate, ie, nothing to discourage you</div>
<div> It's easy to clean up - you don't have to worry about cleanup problems, makes it simpler to use in many situations</div><div> Dynamic arrays are easy - many C++ users will avoid dynamic arrays because the explicit allocation/clean up implies complexity, one will always use the stack, or a fixed array where they can get away with it</div>
<div> Slicing, concatenation, etc performs bucket loads of implicit GC allocations</div><div> Strings... - C coders who reject the stl will almost always have a separate string heap with very particular allocation patterns, and almost always refcounted</div>
<div> Phobos/druntine allocate liberally - the CRT almost never allocates</div><div><br></div><div>This is my single biggest fear in D. I have explicit control within my own code, but I wonder if many D libraries will be sloppy and over-allocate all over the place, and be generally unusable in many applications.</div>
<div>If D is another language like C where the majority of libraries (including the standard libraries I fear) are unusable in various contexts, then that kinda defeats the purpose. D's module system is one of its biggest selling points.</div>
<div><br></div><div>I think there should be strict phobos allocation policies, and ideally, druntime should NEVER allocate if it can help it.</div><div class="im"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Consider C strings. You need to keep track of ownership of it. That often means creating extra copies, rather than sharing a single copy.<br></blockquote><div><br></div></div><div>Rubbish, strings are almost always either refcounted or on the stack for dynamic strings, or have fixed memory allocated within structures. I don't think I've ever seen someone duplicating strings into separate allocations liberally.</div>
<div class="im">
<div><br></div></div></div></blockquote><div><br></div><div>Many STL implementers have abandoned COW (MSVC/Dinkumware, Clang's libc++, STLPort) and are instead using short-string-optimization. Reference counted strings are seen as an anti-optimization in multithreaded code (especially since rvalue references were added making SSO even faster). [1]</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Enter C++'s shared_ptr. But that works by, for each object, allocating a *second* chunk of memory to hold the reference count. Right off the bat, you've got twice as many allocations & frees with shared_ptr than a GC would have.<br>
</blockquote></div></div><br><div>Who actually uses shared_ptr? Talking about the stl is misleading... an overwhelming number of C/C++ programmers avoid the stl like the plague (for these exact reasons). Performance oriented programmers rarely use STL out of the box, and that's what we're talking about here right? If you're not performance oriented, then who cares about the GC either?</div>
</blockquote></div><div><br></div><div>That's certainly true, from what I hear, in the games industry but STL is heavily used outside of games.</div><div><br></div><div>Regards,</div><div>Brad Anderson</div><div><br>
</div><div>[1] <a href="http://www.gotw.ca/publications/optimizations.htm">http://www.gotw.ca/publications/optimizations.htm</a></div>