Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: benchmarks? java vs .net (binarytrees)

Reply
Thread Tools

Re: benchmarks? java vs .net (binarytrees)

 
 
Rudy Velthuis
Guest
Posts: n/a
 
      06-08-2008
Razii wrote:

> Consider what happens when you do a new/malloc: a) the allocator looks
> for an empty slot of the right size, then returns you a pointer.


Modern allocators have several arrays of slots of suitable sizes, and
can therefore easily find one in the right size. The next allocation of
that size will also be immediately adjacent. Only rather large sizes
require another approach, but I assume these are pretty rare in both
kinds of environments, and I guess that programs tend to hang on to
such large objects much longer as well. Deallocation of objects is
immediate, which often means that memory consumption is lower and not
dependent on when a GC might finally run. Also, no heaps of memory are
moved around in non-GC memory management.

IOW, there are arguments for both approaches. The GC one has the big
advantage that one big cause of errors, all errors regarding memory
use, are more or less completely eliminated. But I doubt I would call
speed one of the main factors to choose a GC.
--
Rudy Velthuis http://rvelthuis.de

"My last cow just died, so I won't need your bull anymore."
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      06-09-2008
Rudy Velthuis wrote:
> Razii wrote:
>> Consider what happens when you do a new/malloc: a) the allocator looks
>> for an empty slot of the right size, then returns you a pointer.

>
> Modern allocators have several arrays of slots of suitable sizes, and
> can therefore easily find one in the right size. The next allocation of
> that size will also be immediately adjacent. Only rather large sizes
> require another approach, but I assume these are pretty rare in both
> kinds of environments, and I guess that programs tend to hang on to
> such large objects much longer as well. Deallocation of objects is
> immediate, which often means that memory consumption is lower and not
> dependent on when a GC might finally run. Also, no heaps of memory are
> moved around in non-GC memory management.
>
> IOW, there are arguments for both approaches. The GC one has the big
> advantage that one big cause of errors, all errors regarding memory
> use, are more or less completely eliminated. But I doubt I would call
> speed one of the main factors to choose a GC.


Actually GC speed is very good.

The problem people complain over is the non deterministic
aspect of it.

Arne
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      06-09-2008
Jon Harrop wrote:
> Lew wrote:
>> Rudy Velthuis wrote:
>>> Modern allocators have several arrays of slots of suitable sizes, and
>>> can therefore easily find one in the right size. The next allocation of
>>> that size will also be immediately adjacent. Only rather large sizes
>>> require another approach, but I assume these are pretty rare in both
>>> kinds of environments, and I guess that programs tend to hang on to
>>> such large objects much longer as well. Deallocation of objects is
>>> immediate, which often means that memory consumption is lower and not
>>> dependent on when a GC might finally run. Also, no heaps of memory are
>>> moved around in non-GC memory management.

>> Deallocation of young objects in Java takes no time at all...

>
> You are ignoring all of the overheads of a GC, like thread synchronization,
> stack walking and limitations placed upon the code generator required to
> keep the GC happy.


I would expect non-GC solutions to need more thread synchronization
than GC because it will need it many more times.

> If you compare generically and assume infinite development time then
> lower-level languages will surely win in terms of raw performance. The
> reason the world moved on to GC'd languages is that they allow more
> complicated programs to be written more robustly and efficiently in a given
> amount of development time, i.e. they are more cost effective.


I agree with that part.

Arne
 
Reply With Quote
 
Rudy Velthuis
Guest
Posts: n/a
 
      06-09-2008
Arne Vajh°j wrote:

> > IOW, there are arguments for both approaches. The GC one has the big
> > advantage that one big cause of errors, all errors regarding memory
> > use, are more or less completely eliminated. But I doubt I would
> > call speed one of the main factors to choose a GC.

>
> Actually GC speed is very good.
>
> The problem people complain over is the non deterministic
> aspect of it.


People also complained about messaging and the non-linear aspect of it
when they moved from DOS to Windows. I guess, to many, this is a
similar issue, i.e. they sense a loss of control. <g>


--
Rudy Velthuis http://rvelthuis.de

"We don't make mistakes, we just have happy little accidents."
-- Bob Ross, "The Joy of Painting"
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      06-17-2008
Rudy Velthuis wrote:
> Arne Vajh°j wrote:
>>> IOW, there are arguments for both approaches. The GC one has the big
>>> advantage that one big cause of errors, all errors regarding memory
>>> use, are more or less completely eliminated. But I doubt I would
>>> call speed one of the main factors to choose a GC.

>> Actually GC speed is very good.
>>
>> The problem people complain over is the non deterministic
>> aspect of it.

>
> People also complained about messaging and the non-linear aspect of it
> when they moved from DOS to Windows. I guess, to many, this is a
> similar issue, i.e. they sense a loss of control. <g>


That is most certainly something that causes a lot of C++ programmers
going to Java or C# to feel uncomfortable.

Arne
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      06-17-2008
Jon Harrop wrote:
> Arne Vajh°j wrote:
>> Jon Harrop wrote:
>>> You are ignoring all of the overheads of a GC, like thread
>>> synchronization, stack walking and limitations placed upon the code
>>> generator required to keep the GC happy.

>> I would expect non-GC solutions to need more thread synchronization
>> than GC because it will need it many more times.

>
> That is just more unfounded speculation.


Since it contains an argument then you can hardly call it unfounded.

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hot Requirements: 1.Sr Java Developer,2.Java Developer (Java with EJB) Isaac Java 0 01-20-2011 08:41 PM
hey i am just started java,, can anyone tell me the use ,application, why java , importance of java.. manish sahu Java 3 02-14-2008 12:00 AM
[JAVA] [EVALUATION] - The Java Failure (Sorry: The Java(tm) Failure) Ilias Lazaridis Java 0 02-01-2005 10:32 AM
JAVA VIRTUAL MUCHINE OR SUN JAVA Fernando Kohan Firefox 1 11-14-2004 02:04 AM
Job to convert Java App 1.3.1 to Java Newest of Java Michael Kintner Java 0 11-30-2003 04:42 AM



Advertisments