On Tue, Mar 6, 2012 at 5:27 AM, Manu <turkey...@gmail.com> wrote: > On 26 February 2012 00:55, Walter Bright <newshou...@digitalmars.com>wrote: > >> On 2/25/2012 2:08 PM, Paulo Pinto wrote: >> >>> Most standard compiler malloc()/free() implementations are actually >>> slower than >>> most advanced GC algorithms. >>> >> >> 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. >> > > Do you really think that's true? Are there any statistics to support that? > I'm extremely sceptical of this claim. > > I would have surely thought using a GC leads to a significant *increase*in > allocations for a few reasons: > It's easy to allocate, ie, nothing to discourage you > It's easy to clean up - you don't have to worry about cleanup problems, > makes it simpler to use in many situations > 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 > Slicing, concatenation, etc performs bucket loads of implicit GC > allocations > Strings... - C coders who reject the stl will almost always have a > separate string heap with very particular allocation patterns, and almost > always refcounted > Phobos/druntine allocate liberally - the CRT almost never allocates > > 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. > 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. > > I think there should be strict phobos allocation policies, and ideally, > druntime should NEVER allocate if it can help it. > > > Consider C strings. You need to keep track of ownership of it. That often >> means creating extra copies, rather than sharing a single copy. >> > > 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. > > 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]
> > >> 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. >> > > 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? > That's certainly true, from what I hear, in the games industry but STL is heavily used outside of games. Regards, Brad Anderson [1] http://www.gotw.ca/publications/optimizations.htm