Do you use a garbage collector?

[Mirek Fidler]

No it didn't. g++ and vc9 are at least three times slower in this
case, even if I use -Xms75m (which is appropriate for this case). I
have a choice to increase -Xms value and make it 8 times faster.

Well, I guess you are doing it again - finetuning conditions to
achieve "victory".

I could do equivalent (introducing better algorithm, custom allocator,
more parameters), but that would hardly prove anything, as I have a
little use of such tricks in my regular code. Normal code has to deal
with datasets of any size using as little memory as possible.

The final truth is that generally (that means, before you start to
change conditions to fit your case), optimal manual memory management
is faster and wastes significantly less memory than GC.

Mirek

 

[Juha Nieminen]

#include <gc_cpp.h>

what else do I need to do? Can you post the version that would use
Boehm Collector and command line to compile and link it.

Never heard. I have no idea.

 

[Jerry Coffin]

[ ... ]

In practice (and I speak here from experience), using garbage
collection in C++ doesn't impact style that much. (And with the
exception of a few people like you and Jerry Collins, many of
those worried about its impact on style really do need to change
their style.)

Is this Jerry Collins anything like a Tom Collins? Personally in mixed
drinks, I prefer a Cape Cod (though I really prefer a good red Bordeaux
over almost any mixed drink).

Even with garbage collection, the "default" mode
in C++ is values, not references or pointers (call them whatever
you want), with true local variables, on the stack, and not
dynamically allocated memory. As far as I know, there's never
been the slightest suggestion that this should be changed.

I sure hope not -- changing that seems like it would change the
fundamental character of the language almost completely. Improving C++
is one thing, but changing its character is quite another. Trying to
make C++ into another Java doesn't strike me as a particularly useful
exercise.

 

[Jerry Coffin]

[ ... ]

Are you sure about the "most-likely" part? From what little
I've seen, most C runtime libraries simply threw in a few locks
to make their 30 or 40 year old malloc thread safe, and didn't
bother with more. Since most of the marketing benchmarks don't
use malloc, there's no point in optimizing it. I suspect that
you're describing best practice, and not most likely. (But I'd
be pleased to learn differently.)

The malloc's I've looked at aren't nearly that old. At least the last
time I looked, libg++ used Doug Lea's allocator from around 2000 or so.

Microsoft rewrote their allocator for VC++ 5. At that point, the
implemented two separate heaps, one for small blocks and another for
large blocks. In VC++ 6, they tweaked it a bit, such as changing the
dividing line between "large" and "small".

OTOH, the multithreading support is pretty much as you've described --
lock the heap during critical sections, but not much more than that.

 

[Ian Collins]

[ ... ]

In practice (and I speak here from experience), using garbage
collection in C++ doesn't impact style that much. (And with the
exception of a few people like you and Jerry Collins, many of
those worried about its impact on style really do need to change
their style.)

Is this Jerry Collins anything like a Tom Collins? Personally in mixed
drinks, I prefer a Cape Cod (though I really prefer a good red Bordeaux
over almost any mixed drink).

He's a well known (at least in these parts) All Black ruby player.

Maybe Jame was referring to me? If he was, then yes, my style does not
suit GC. I do a lot of real time embedded work where memory is a
precious resource to be free as soon as possible. I started programming
in C and later C++ in days of old before GC when leaking memory was a
mortal sin. I still have to stop myself deleting objects when I'm
writing JavaScript!

 

[Mike Schilling]

Yes, but we are speaking about "application is terminated" situation
here...

Oh. Yeah, arguing that an OS would treat C++ and Java different
during application cleanup is (what's the polite word again? Oh,
right.) questionable.

 

[Mike Schilling]

Heap compaction is nothing all that special. Its certainly not tied
to a GC. Not at all.

Good thing I neither said nor implied that it is, then. However,
all Java VMs that I know of support it. for the obvious reason that
GCs which don't compact would fail pretty quickly with heap
fragmentation [1]. Most C++ implementations don't support it, because
their pointers are implemented as machine addresses.and they lack a
mechanism to fix up the pointers after a compaction.

1. Plus the fact that if you have enough information to do GC, you
have more than enough to make compaction work.

 

[Bo Persson]

What about in the case of some kind of tree structure?

How would you do the following in c++?

#include <ctime>
#include <iostream>


struct Tree {
Tree *left;
Tree *right;
};

This is a tree with empty nodes. Why would I want to build that?


Bo Persson

 

[Bo Persson]

The only disadvantage of GC seems to be it needs more RAM (though I
was able to fix it. See below). On the positive side, it has the big
advantages too. In manual management, you can delete the memory but
still has the pointer pointing at it, i.e dangling pointer. Or you
can forget to free it and have memory leak. Both of these are not
possible with GC.

Or you can put the delete statement in the desctructor of the class
owning the pointer. That way you cannot forget to use it.


Bo Persson

 

[Bo Persson]

The "new" operator is as horrible as anything in both g++ and VC9,
as conclusively proven in the other thread.

Here is a C++ version to benchmark the operator "new"

http://pastebin.com/f6bfa4d78 (C++ version)

28422 ms (g++)
26750 ms (vc++)

U++, that overwrites the default new, can execute the same program
in 4500 ms, 6.3 times faster than g++.

However, the fastest is java...

http://pastebin.com/f3f559ae2 (java )

(make sure to run it with these flags)
java -server -Xmx86m -Xms86m -Xmn85m Test

1800 ms, 15 times faster than g++.

And operator new isn't used much at all in C++, except when
benchmarking against Java. Wonder why?


Bo Persson

 

[Erik Wikström]

Old OSes could not reclaim unused memory from applications simply
because it lacked the functionality. On OSes which can it is just a
question about whether the allocator used will return unused memory or
not, which means that on some platform it might just as well be the JVM
that does not return memory while the C++ app does.

How about mobile and embedded devices that don't have sophisticated
memory management? If a C++ application is leaking memory, the memory
might never be returned even after the application is terminated.
This is more dangerous than memory leak in Java application, where,
after the application is terminated, all memory is returned by VM.

On all OSes which uses virtual memory all memory used by an application
is returned on termination since the OS unmaps those pages used by the
application. If no virtual memory is used you will not be able to
retrieve leaked memory, on the other hand most programs running in such
environments are heavily profiled to find memory leaks.

 

[Erik Wikström]

Howeever, Java allocates new memory blocks on it's internal heap
(which is allocated in huge chunks from the OS). In this way, in most
of the cases it bypasses memory allocation mechanisms of the
underlying OS and is very fast. In C++, each "new" allocation request
will be sent to the operating system, which is slow.

You would find that fewer people would regard you as a troll if you did
not post things like this. Anyone with at least a little bit of
knowledge of OSes and memory allocation knows that this is wrong. When
an application needs more memory it uses brk(), sbrk(), or mmap() (or
something equivalent) and adds the new memory to its internal heap, just
like in Java. Note that using mmap makes it much easier to return memory
to the OS than using brk/sbrk().

 

[Juha Nieminen]

huh? That's pretty silly statement. The operator new is used to
dynamically allocated memory. It has nothing to do with benchmarking
with Java. You need to dynamically allocate memory in most large C++
programs, such as simulators, where the designer can never safely set
an upper limit on application size.

In many applications memory is allocated as arrays instead of
individual elements.

Granted, there are situations where there's no way around allocating
individual elements, but in those cases a custom allocator can be used
for considerable speedups. (And yes, it's hard to find such allocators,
but eg. I have made one, if anyone is interested.)

 

[peter koch]

huh? That's pretty silly statement.   The operator new is used to
dynamically allocated memory. It has nothing to do with benchmarking
with Java. You need to dynamically allocate memory in most large C++
programs, such as simulators,  where the designer can never safely set
an upper limit on application size.

This is of course true, but in most C++ projects the new is quite
rare. This is opposed to Java where you have to use new every time you
create an object.

/Peter

 

[peter koch]

[ ... ]

In practice (and I speak here from experience), using garbage
collection in C++ doesn't impact style that much.  (And with the
exception of a few people like you and Jerry Collins, many of
those worried about its impact on style really do need to change
their style.)

Is this Jerry Collins anything like a Tom Collins? Personally in mixed
drinks, I prefer a Cape Cod (though I really prefer a good red Bordeaux
over almost any mixed drink).

He's a well known (at least in these parts) All Black ruby player.

But ruby is off topic here - as well as java! ;-)

/Peter

 

[Bo Persson]

huh? That's pretty silly statement. The operator new is used to
dynamically allocated memory.

But you don't do that directly in C++ code. Most often you put your
data in a container, and let it handle the allocation.

It has nothing to do with benchmarking
with Java.

It does very much so. Dynamically allocating a huge number of very
small objects is perhaps something you do in Java, but you don't do
that in real C++ code. Especially not in a loop.

That might be one reason why C++ implementors haven't spent much
effort optimizing this.

You need to dynamically allocate memory in most large C++
programs, such as simulators, where the designer can never safely
set an upper limit on application size.

I can have a std::vector<item> or a std::deque<item> and don't have to
use new in my code. The container can grow as needed.



Bo Persson

 

[James Kanze]

[ ... ]

In practice (and I speak here from experience), using garbage
collection in C++ doesn't impact style that much. (And with the
exception of a few people like you and Jerry Collins, many of
those worried about its impact on style really do need to change
their style.)

Is this Jerry Collins anything like a Tom Collins?

Hmmm. I don't know how my fingers found l's instead of
f's---they're not even on the same hand. (On the other hand,
they do look vaguely similar in the font I'm using, if I don't
look too hard.)

Personally in mixed drinks, I prefer a Cape Cod (though I
really prefer a good red Bordeaux over almost any mixed
drink).

I definitely prefer wine to mixed drinks as well, although if
it's just as an aperitif, rather than with a meal, it will
generally be white. (About the only "mixed drink" I drink is a
Schorle---half white wine, half mineral water, and then only
when it's very hot.)

I sure hope not -- changing that seems like it would change the
fundamental character of the language almost completely. Improving C++
is one thing, but changing its character is quite another. Trying to
make C++ into another Java doesn't strike me as a particularly useful
exercise.

Agreed. The goal is simply to add functionality for those for
whom it would be useful, not to change the character of the
language.

 

[James Kanze]

[...]

It does very much so. Dynamically allocating a huge number of very
small objects is perhaps something you do in Java, but you don't do
that in real C++ code. Especially not in a loop.

This also holds with regards to Peter Koch's comment "new is
quite rare": it depends. You're certainly not forced to use new
for everything (nor should you), but there are specific
applications where you might end up with such allocation
patterns.

That might be one reason why C++ implementors haven't spent
much effort optimizing this.

Some have, actually, and there are implementations of
malloc/free which handle a lot of small allocations gracefully.

I can have a std::vector<item> or a std::deque<item> and don't
have to use new in my code. The container can grow as needed.

Up until that point, the same holds true in Java. The
difference is that in Java, when you have a vector of item, what
you really have is a vector of pointers to item, and each item
has to be allocated individually. If my goal were to write a
benchmark proving C++ were faster than Java, I'd certainly start
by defining a small class, like Point (two or three double) or
Complex (two double), then start deap copying vectors of them.
Java memory allocation can be very fast, but not as fast as 0.
(If I really wanted Java to look bad, I'd also arrange things so
that the garbage collector pool space was almost full, almost
all of the time, so that the garbage collector had to run often,
on a lot of allocated memory.)

Of course, if I wanted to prove Java faster, I'd choose
something else. Never trust a benchmark you having falsified
yourself.

 

[Erik Wikström]

No problems. I have a thick skin ..


As I said, I read this on a web site. What about VirtualAlloc? When is
that called?

Not quite sure, seems to be something like mmap, perhaps you can use it
to allocate memory for a heap, but there are other functions available
to manage heaps in Windows.

 

[Jerry Coffin]

[ ... "Jerry Collins" ]

Maybe Jame was referring to me? If he was, then yes, my style does not
suit GC. I do a lot of real time embedded work where memory is a
precious resource to be free as soon as possible. I started programming
in C and later C++ in days of old before GC when leaking memory was a
mortal sin. I still have to stop myself deleting objects when I'm
writing JavaScript!

Perhaps he's come up with one of those conspiracy theories. Maybe we're
really the same person -- after all, I'm pretty sure nobody's ever seen
both of us at the same time...