Nick Sabalausky Wrote:

> "Tony" <tonytech08@gmail.com> wrote in message news:gflkav$8rc$1@digitalmars.com...
> >
> > "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gf5r4l$2kt9$1@digitalmars.com...
> >>
> >> 1. GC programs can be faster
> >>
> >> 2. GC programs can use less memory
> >>
> >> 3. GC programs can be guaranteed to be memory safe
> >>
> >> 4. GC programs are faster to develop and have fewer bugs
> >
> > None of which "sell me" on GC.
> 
> Why not? They sound like pretty darn good reasons to me. What are you expecting out of a memory manager, the secret of the universe?
> 
> If you have reason to disagree that the items on that list are true, then ok, I can understand. But if you're saying that those aren't good enough reasons, then it sounds like you have unrealistic expectations.
> 
> > As an independent developer, I have to keep my cards close to my chest about some of (one?) the reasons why I thing "my way" is compelling (in the true sense of the word).
> 
> I'm an independent developer too, but I have to say, this is a clear indication that your system isn't nearly as special as you think it is.
> 
> There are only three types of people who ever have a non-standard solution and think it's actually worth bothering with such secrecy: 1. Industry-renowned full-time tech researchers who actually do create good stuff (and then make it publicly known by the time their research is done), 2. Suits and managers, who don't know a damn thing about the technical side of anything, including code, and 3. Novices.

4. beneficiaries of da sayin' "on the internet nobody knows ur a dog".

> I'm not saying this to try to convince you to tell us, or to insult you, but as a cautionary tale. You need to take a good hard look at your system, be as objective as you can possibly be, and make sure it really is the that special. Because anytime you tell yourself "This is so good that nobody else has thought of it and it's the ace up my sleeve", that should raise a giant red flag in your mind saying that no, in fact, it's extremely doubtful that it's anything special at all.

nice words my friend. but somethin' tells me yer wasting yer breath.

Tony:
> Walter Bright:
> > 1. GC programs can be faster
> > 2. GC programs can use less memory
> > 3. GC programs can be guaranteed to be memory safe
> > 4. GC programs are faster to develop and have fewer bugs
> 
> None of which "sell me" on GC.

Generally a program that uses GC uses more RAM (2-12 times) than a manually memory managed one. I have also read various articles that say the same thing.

They also say that GC-managed programs can be almost as fast as manually managed ones only of you give them 2-6 the RAM you give un-GC-managed ones.

It can be right only if you count memory leaks too: they make programs that manage memory manually to use unbound amounts of memory. On the other hand a GC doesn't prevents you all memory leaks, because you can leave around references, etc.

So even taking into account that Walter's experience on such topics is far greater than mine (I've never written a GC for C++, for example), I'd risk say that in general point 2 is wrong.
Said that, most of the times using a GC is better (especially if you use a modern GC, like the HotSpot one, etc), and often today RAM isn't a scarce resource anymore, so I like D to have a built-in GC activated by default, plus a C heap to manage things manually :-)

Bye,
bearophile

Nick Sabalausky wrote:
> I'm not saying this to try to convince you to tell us, or to insult you, but as a cautionary tale. You need to take a good hard look at your system, be as objective as you can possibly be, and make sure it really is the that special. Because anytime you tell yourself "This is so good that nobody else has thought of it and it's the ace up my sleeve", that should raise a giant red flag in your mind saying that no, in fact, it's extremely doubtful that it's anything special at all.

If it really is that special, ask yourself: why isn't your whole business centered on this one thing?

If your business actually is centered on that, then make sure you have good marketing, because just having special code or algorithms won't suffice.

On Fri, 14 Nov 2008 22:48:41 -0600, Tony wrote:
> breakers for some (a lot?) of software. That's why I think GC should be an opt-in rather than an opt-out choice. That's a key characteristic of C++: opt-in. And I really, really like that level of creative freedom.

That's not necessarily good. There are now multiple commonly-used methods for pointing to instances in C++: plain pointers, references, and smart pointers, all with different usage and semantics. It's a burden for library writers and library users. An opt-in GC only makes the burden heavier.

In contrast, most GC-ed languages make life simpler not requiring a plethora of alternate management/lifetime schemes.

Take care,
Daniel

== Quote from Daniel de Kok (daniel@nowhere.nospam)'s article
> On Fri, 14 Nov 2008 22:48:41 -0600, Tony wrote:
> > breakers for some (a lot?) of software. That's why I think GC should be an opt-in rather than an opt-out choice. That's a key characteristic of C++: opt-in. And I really, really like that level of creative freedom.
> That's not necessarily good. There are now multiple commonly-used methods
> for pointing to instances in C++: plain pointers, references, and smart
> pointers, all with different usage and semantics. It's a burden for
> library writers and library users. An opt-in GC only makes the burden
> heavier.
> In contrast, most GC-ed languages make life simpler not requiring a
> plethora of alternate management/lifetime schemes.
> Take care,
> Daniel

Agreed.  Also, whether or not GC is the default in a language deeply affects the
de facto standard way of doing things.  For example, in C++, you don't have nice
slice syntax in STL because STL is designed for use with manual memory management.
 Also, from what I've seen and heard, you tend to lose a lot of the theoretical
efficiency of manual memory management when you replace it with ref counting
(read:  poor man's GC), or lots of copying to make every object have a clear
owner.  I translated a small but computationally intensive machine learning
program from C++ to D a few months ago, and the D version was drastically faster
because it avoided lots of excess copying.  Granted, the C++ version *could* have
been more optimized, but in the real world, people don't have forever to optimize
all this stuff away.

Another interesting thing about D that I don't think people give enough notice to is how cleanly you can mix manual and automatic memory management to get the best of both.  GC is fast (compared to manual memory management) when you have large amounts of small objects with non-trivial lifetimes.  It is slow when you have a few large objects with trivial lifetimes.  The way I usually write my code, which is generally number crunching type stuff that can require lots of scratch space, is to use GC for all the small objects and objects where the lifetime is non-trivial, and free things like scratch arrays that can be large and are only used within one function manually.

bearophile wrote:
> Tony:
>> Walter Bright:
>>> 1. GC programs can be faster 2. GC programs can use less memory 3. GC programs can be guaranteed to be memory safe 4. GC programs
>>> are faster to develop and have fewer bugs
> So even taking into account that Walter's experience on such topics
> is far greater than mine (I've never written a GC for C++, for
> example), I'd risk say that in general point 2 is wrong.

When people do benchmarks comparing the same code in explicit allocation and GC, the GC uses more memory. However, and this is a big however, the existence of GC means you can structure your algorithm to need far fewer allocations. Kris Bell's talk on that at the last D conference was a prime example of that.

For example, with GC you can slice an existing string. With manual mm, you have to allocate memory and copy it.

dsimcha wrote:
> Agreed.  Also, whether or not GC is the default in a language deeply affects the
> de facto standard way of doing things.  For example, in C++, you don't have nice
> slice syntax in STL because STL is designed for use with manual memory management.
>  Also, from what I've seen and heard, you tend to lose a lot of the theoretical
> efficiency of manual memory management when you replace it with ref counting
> (read:  poor man's GC), or lots of copying to make every object have a clear
> owner.  I translated a small but computationally intensive machine learning
> program from C++ to D a few months ago, and the D version was drastically faster
> because it avoided lots of excess copying.  Granted, the C++ version *could* have
> been more optimized, but in the real world, people don't have forever to optimize
> all this stuff away.

Modern C++ practices (as best as I can tell) make extensive use of ref-counting memory management, i.e. shared_ptr<>. This requires TWO allocations for each use, not just one. The second allocation is for the reference counting management.

Next, every time you copy a pointer (like pass it to a function, return it, etc.) you have to increment, then decrement, the reference count. If you've got multithreading on, this requires a mutex or the usual memory syncing primitives which are 100x slower than regular memory access.

You can escape the inc/dec overhead by converting the shared ptr to a regular pointer, but then you lose all the safety guarantees.