Re: benchmarks? java vs .net (binarytrees)
 

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."

Re: benchmarks? java vs .net (binarytrees)
 

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

Re: benchmarks? java vs .net (binarytrees)
 

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

Re: benchmarks? java vs .net (binarytrees)
 

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"

Re: benchmarks? java vs .net (binarytrees)
 

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

Re: benchmarks? java vs .net (binarytrees)
 

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