Re: Do you use a garbage collector (java vs c++ difference in "new") - Java

On Sat, 12 Apr 2008 03:41:41 -0500, Razii
<DONTwhatevere3e@hotmail.com> wrote:

>forgot to post the time with these
>
>Time: 3875 ms (that's twice faster than U++)

this time keeps improving if I keep increasing Xms

java -verbose:gc -server -Xms1024m -Xmx1024m Test

[GC 93184K->11199K(1036928K), 0.0734596 secs]
[GC 104383K->6078K(1036928K), 0.0387792 secs]
[GC 99262K->957K(1036928K), 0.0051831 secs]
[GC 94141K->12220K(1036928K), 0.0761963 secs]
[GC 105404K->7564K(1036928K), 0.0435248 secs]
[GC 100748K->2442K(1036928K), 0.0114260 secs]
[GC 95626K->13705K(1036928K), 0.0820523 secs]
[GC 106889K->10070K(1036928K), 0.0493448 secs]
[GC 103254K->4949K(1036928K), 0.0178042 secs]
[GC 98133K->16211K(1036928K), 0.0885911 secs]
[GC 109395K->13597K(1036928K), 0.0561415 secs]
[GC 106781K->8475K(1036928K), 0.0239692 secs]
[GC 101659K->19738K(1036928K), 0.0960955 secs]
[GC 112922K->18144K(1036928K), 0.0621244 secs]
[GC 111328K->13023K(1036928K), 0.0303754 secs]
[GC 106207K->24286K(1036928K), 0.1060395 secs]
[GC 117470K->23712K(1036928K), 0.0688886 secs]
Time: 2850 ms

GC ran only 17 times. Witout any flags it runs 779 times. with output
that looks like

[GC 25857K->25856K(28460K), 0.0182224 secs]
[Full GC 25856K->9472K(28460K), 0.0949867 secs]
[GC 12032K->12031K(26924K), 0.0171254 secs]
[GC 14591K->14590K(26924K), 0.0176701 secs]
[GC 17150K->17150K(26924K), 0.0178316 secs]
[GC 19710K->19709K(26924K), 0.0177715 secs]
[GC 22269K->22268K(26924K), 0.0178945 secs]
[GC 24828K->24827K(27436K), 0.0181017 secs]
[Full GC 24827K->8443K(27436K), 0.0864060 secs]
(snip)

> GC ran only 17 times. Witout any flags it runs 779 times. with output
> that looks like

Obviously, less times GC runs, faster the code is.

But we can now stop pretending that GC is faster than manual
management, can we?

Of course, if there is no live memory involved, it can be as fast as
manual. But that proves nothing.

(And, BTW, we are still actually using the heap. Of course, in C++,
you allocated much less items there).

Mirek

On Fri, 11 Apr 2008 21:56:03 -0700 (PDT), Mirek Fidler
<cxl@ntllib.org> wrote:

>#include <Core/Core.h>
>
>using namespace Upp;
>
>struct Tree {
> Tree *left;
> Tree *right;
>};
>
>Tree *CreateTree(int n)
>{
> if(n <= 0)
> return NULL;
> Tree *t = new Tree;
> t->left = CreateTree(n - 1);
> t->right = CreateTree(n - 1);
> return t;
>}
>
>void DeleteTree(Tree *t)
>{
> if(t) {
> DeleteTree(t->left);
> DeleteTree(t->right);
> delete t;
> }
>}
>
>CONSOLE_APP_MAIN
>{
> RTIMING("Tree new/delete");
> for(int i = 0; i < 100; i++)
> DeleteTree(CreateTree(20));
>}


Running this version on VC++ and g++: 43718 ms and g++ 46890 ms

that is 5 to 6 times slowe than in U++

On Sat, 12 Apr 2008 02:47:26 -0700 (PDT), Mirek Fidler
<cxl@ntllib.org> wrote:

>(And, BTW, we are still actually using the heap. Of course, in C++,
>you allocated much less items there).

If there is not enough memory on stack, you don't have a choice. You
have to dynamically allocate memory sometimes.

I changed the loop to

for(int i = 0; i < 15; i++)
DeleteTree(CreateTree(22));

Now you don't have a choice, or do you?

this requires at least 68 MB on U++

Time: 4562 ms (U++)
Time: 27781 ms (g++)

java -server -Xms1024m -Xmx1024m

Time: 3578 ms (max memory I saw was on 300 M -- but at least it
finished 7 times faster than g++ ...

with -Xms75m -Xmx100m the time is around: 9969 ms

On Jet, 2344 ms (wow, that was fast but memory peak was 600 MB!)

Razii wrote:
> On Thu, 10 Apr 2008 20:37:59 -0500, Razii
> <DONTwhatevere3e@hotmail.com> wrote:
>
>> int main(int argc, char *argv[]) {
>>
>> clock_t start=clock();
>> for (int i=0; i<=10000000; i++) {
>> Test *test = new Test(i);
>> if (i % 5000000 == 0)
>> cout << test;
>> }
>
> If I add delete test; to this loop it gets faster. huh? what the
> exaplanation for this?
>
> 2156 ms
>
> and after I add delete test; to the loop
>
> 1781 ms
>
> why is that?
>
>

Because new in C++ does NOT directly call an OS allocation function. C++
internally uses something similar to malloc/free from C which are memory
management functions that use OS allocation functions as its base but
keeps a self-maintained heap of, allocated at the OS level but
unallocated at the application level, free blocks.

If you keep allocating with new without using delete the OS allocations
have to be done. If you use delete the block goes into the free-blocks
heap and is probably returned immediately with the next new call. You
probably see the same memory address each time through the loop.

Regards,

Silvio Bierman

On Apr 12, 1:23 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Sat, 12 Apr 2008 02:47:26 -0700 (PDT), Mirek Fidler
>
> <c...@ntllib.org> wrote:
> >(And, BTW, we are still actually using the heap. Of course, in C++,
> >you allocated much less items there).
>
> If there is not enough memory on stack, you don't have a choice.

Is is not about stack only.

E.g. Vector<String> in U++ allocates single block of memory for all
Strings (as long as they are short enough).

> You
> have to dynamically allocate memory sometimes.

Yes, but much less

> I changed the loop to
>
> for(int i = 0; i < 15; i++)
> DeleteTree(CreateTree(22));
>
> Now you don't have a choice, or do you?
>
> this requires at least 68 MB on U++
>
> Time: 4562 ms (U++)
> Time: 27781 ms (g++)
>
> java -server -Xms1024m -Xmx1024m
>
> Time: 3578 ms (max memory I saw was on 300 M -- but at least it
> finished 7 times faster than g++ ...
>
> with -Xms75m -Xmx100m the time is around: 9969 ms
>
> On Jet, 2344 ms (wow, that was fast but memory peak was 600 MB!)

IMO, manual management still wins...

Mirek

On Apr 12, 12:06 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Fri, 11 Apr 2008 21:56:03 -0700 (PDT), Mirek Fidler
>
>
>
> <c...@ntllib.org> wrote:
> >#include <Core/Core.h>
>
> >using namespace Upp;
>
> >struct Tree {
> > Tree *left;
> > Tree *right;
> >};
>
> >Tree *CreateTree(int n)
> >{
> > if(n <= 0)
> > return NULL;
> > Tree *t = new Tree;
> > t->left = CreateTree(n - 1);
> > t->right = CreateTree(n - 1);
> > return t;
> >}
>
> >void DeleteTree(Tree *t)
> >{
> > if(t) {
> > DeleteTree(t->left);
> > DeleteTree(t->right);
> > delete t;
> > }
> >}
>
> >CONSOLE_APP_MAIN
> >{
> > RTIMING("Tree new/delete");
> > for(int i = 0; i < 100; i++)
> > DeleteTree(CreateTree(20));
> >}
>
> Running this version on VC++ and g++: 43718 ms and g++ 46890 ms
>
> that is 5 to 6 times slowe than in U++

Well, that actually proves my point, does not it?

(The one about average implementation of standard C++ library being
the crap and about zero effort invested into manual allocators).

Mirek

It's so unfair!

Razii $B<LF;!'(B
> On Fri, 11 Apr 2008 03:35:27 +0300, Juha Nieminen
> <nospam@thanks.invalid> wrote:
>
> >Razii wrote:
> >> In C++, each "new" allocation request
> >> will be sent to the operating system, which is slow.
> >
> > That's blatantly false.
>
> Well, my friend, I have proven you wrong. Razi has been victorious
> once again
>
>
> Time: 2125 ms (C++)
> Time: 328 ms (java)
>
>
> --- c++--
>
> #include <ctime>
> #include <cstdlib>
> #include <iostream>
>
> using namespace std;
>
> class Test {
> public:
> Test (int c) {count = c;}
This is assignment after initialization.
It should be like this:
Test(int c) : count(c) {}
> virtual ~Test() { }
> int count;
> };
>
> int main(int argc, char *argv[]) {
>
> clock_t start=clock();
> for (int i=0; i<=10000000; i++) {
> Test *test = new Test(i);
> if (i % 5000000 == 0)
> cout << test;
The memory you allocated is not released, so every new() is actually a
allocation operation to libc.
When the heap is empty, a new page of memory is allocated from OS.
> }
> clock_t endt=clock();
> std::cout <<"Time: " <<
> double(endt-start)/CLOCKS_PER_SEC * 1000 << " ms\n";
> }
>
> -- java ---
>
> import java.util.*;
>
> class Test {
> Test (int c) {count = c;}
> int count;
>
> public static void main(String[] arg) {
>
> long start = System.currentTimeMillis();
>
> for (int i=0; i<=10000000; i++) {
> Test test = new Test(i);
> if (i % 5000000 == 0)
> System.out.println (test);
After this and assign a new object to the 'test', the 'test' is no
longer ref to the older object.
So the older object is free to release.
Once the java VM's heap is empty, a gc() is called and done. The
memory for the older objects is free for allocation again.
In this example, the java VM calls OS' memory page allocation once and
then never need to alloc again.
> }
> long end = System.currentTimeMillis();
> System.out.println("Time: " + (end - start) + " ms");
>
> }
> }

"Razii" <DONTwhatevere3e@hotmail.com> wrote in message
news:1rn004phqk0q1ek7hu48kjerbjq2qti3cu@4ax.com...
> On Fri, 11 Apr 2008 21:44:48 -0700 (PDT), Mirek Fidler
> <cxl@ntllib.org> wrote:
>
>>Anyway, with numbers like this, I would say we can put "superior GC
>>memory management performance over manual new/delete" to the rest, can
>>we?
>
> The common claim is that GC is much slower than manual new/delete.
[...]

The common claim is false. The main difference is that GC is totally
non-deterministic and its not available everywhere. Sometimes, its not the
right choice for a given job. Act... BTW, how does GC get rid of all forms
of memory management? How do you create an efficient dynamic cache under a
environment controlled by a GC? I know the answer, and it involves a form of
manual memory management indeed...