Re: benchmarks? java vs .net (binarytrees)

Discussion in 'C++' started by Rudy Velthuis, Jun 8, 2008.

  1. 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."
     
    Rudy Velthuis, Jun 8, 2008
    #1
    1. Advertising

  2. Rudy Velthuis

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jun 9, 2008
    #2
    1. Advertising

  3. Rudy Velthuis

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jun 9, 2008
    #3
  4. 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"
     
    Rudy Velthuis, Jun 9, 2008
    #4
  5. Rudy Velthuis

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jun 17, 2008
    #5
  6. Rudy Velthuis

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jun 17, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Thornton

    Re: benchmarks? java vs .net

    Mark Thornton, Jun 3, 2008, in forum: Java
    Replies:
    35
    Views:
    908
    Arne Vajhøj
    Jun 9, 2008
  2. Rudy Velthuis
    Replies:
    5
    Views:
    264
    Arne Vajhøj
    Jun 17, 2008
  3. Arne Vajhøj
    Replies:
    1
    Views:
    303
    Arne Vajhøj
    Jun 8, 2008
  4. Jon Skeet [C# MVP]

    Re: benchmarks? java vs .net (binarytrees)

    Jon Skeet [C# MVP], Jun 9, 2008, in forum: Java
    Replies:
    4
    Views:
    288
    Jon Skeet [C# MVP]
    Jun 17, 2008
  5. kwikius
    Replies:
    2
    Views:
    264
    kwikius
    Jun 10, 2008
Loading...

Share This Page