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

Discussion in 'Java' started by Arne Vajhøj, Apr 11, 2008.

  1. Arne Vajhøj

    Arne Vajhøj Guest

    Razii wrote:
    > Let's test this about the keyword "new" and tight loops. Because in
    > most cases Java allocates new memory blocks on it's internal heap and
    > bypasses memory allocation mechanisms of the underlying OS, the
    > keyword "new" doesn't mean the same thing that it does in C++, where
    > each "new" allocation request is sent to the operating system, which
    > is very slow.


    I can not imagine any C++ runtime that makes an operating system
    call for each new.

    The runtime allocates huge chunks from the OS and then manage
    it internally.

    Arne
     
    Arne Vajhøj, Apr 11, 2008
    #1
    1. Advertising

  2. "Razii" <> wrote in message
    news:...
    > On Thu, 10 Apr 2008 21:43:45 -0400, Arne Vajhøj <>
    > wrote:
    >
    >>I can not imagine any C++ runtime that makes an operating system
    >>call for each new.
    >>
    >>The runtime allocates huge chunks from the OS and then manage
    >>it internally.

    >
    > Testing the keyword "new"
    >
    > Time: 2125 ms (C++)
    > Time: 328 ms (java)
    >
    > Explain that.


    The C++ allocator is less efficient. There's a big difference between that
    and "makes an OS call for each allocation". In fact, given how highly
    optimized Java allocators are these days, the fact that C++ is taking less
    than 7 times as long proves that it's *not* making an OS call.
     
    Mike Schilling, Apr 11, 2008
    #2
    1. Advertising

  3. Arne Vajhøj

    Arne Vajhøj Guest

    Razii wrote:
    > On Thu, 10 Apr 2008 21:43:45 -0400, Arne Vajhøj <>
    > wrote:
    >> I can not imagine any C++ runtime that makes an operating system
    >> call for each new.
    >>
    >> The runtime allocates huge chunks from the OS and then manage
    >> it internally.

    >
    > Testing the keyword "new"
    >
    > Time: 2125 ms (C++)
    > Time: 328 ms (java)
    >
    > Explain that. What I am doing different in java than in c++? Code
    > below..


    If you can prove that the only way to write inefficient code is to make
    OS calls, then you have made your point.

    But as everyone knows it is not, so your argument is completely bogus.

    Arne
     
    Arne Vajhøj, Apr 11, 2008
    #3
  4. "Razii" <> wrote in message
    news:...
    > On Fri, 11 Apr 2008 02:04:18 GMT, "Mike Schilling"
    > <> wrote:
    >
    >> In fact, given how highly
    >>optimized Java allocators are these days, the fact that C++ is
    >>taking less
    >>than 7 times as long proves that it's *not* making an OS call.

    >
    > with java -server it's 12 times slower...
    >
    > Time: 2125 ms (g++)
    > Time: 172 ms (java - server)


    Which doesn't change the conclusion.
     
    Mike Schilling, Apr 11, 2008
    #4
  5. "Razii" <> wrote in message
    news:...
    > On Thu, 10 Apr 2008 22:24:34 -0400, Arne Vajhøj <>
    > wrote:
    >
    >>But as everyone knows it is not, so your argument is completely
    >>bogus.

    >
    > What argument is bogus? My point was that the keyword 'new' is much
    > faster in java because JVM allocates new memory blocks on it's
    > internal heap and bypasses memory allocation mechanisms of the
    > underlying OS.


    And you're wrong, as has been demonstrated repeatedly. There's no
    point trying to explain this any further.
     
    Mike Schilling, Apr 11, 2008
    #5
  6. Arne Vajhøj

    Ian Collins Guest

    Razii wrote:
    > On Thu, 10 Apr 2008 21:29:44 -0500, Sam <> wrote:
    >
    >> See how well /that/ benchmarks against Java :)

    >
    >
    > That is not the topic. The topic is how the keyword "new" behaves.
    >

    The change was fair, it compares idiomatic language use.

    Anyhow, a if you are looking at the keyword new, as simple change to the
    Test class,

    class Test
    {
    static const unsigned nItems(10000001);

    public:
    Test (int c = 0) : count(c) {}
    int count;
    void*

    operator new( size_t n ) throw( std::bad_alloc )
    {
    static Test* items = static_cast<Test*>(malloc(sizeof *items * nItems));
    static unsigned next(0);

    if( next >= nItems ) throw std::bad_alloc();

    return &items[next++];
    }

    void operator delete( void* v ) throw() {}
    };

    runs in 90mS on my box (compared to ~940mS with default new).

    As other's have said, something that's idiomatic Java isn't necessarily
    idiomatic C++. Sam pointed you to the idiomatic C++ code, my example
    shows what a C++ programmer can do when forced to use an unnatural idiom.

    --
    Ian Collins.
     
    Ian Collins, Apr 11, 2008
    #6
  7. Arne Vajhøj

    Ian Collins Guest

    Razii wrote:
    > On Fri, 11 Apr 2008 15:39:36 +1200, Ian Collins <>
    > wrote:
    >
    >> runs in 90mS on my box (compared to ~940mS with default new).

    >
    > Doesn't compile..
    >

    #include <new>

    --
    Ian Collins.
     
    Ian Collins, Apr 11, 2008
    #7
  8. Arne Vajhøj

    Ian Collins Guest

    Razii wrote:

    >
    > Time: 78 ms
    >
    > pretty fast...
    >
    > however, if I change the loop to 10000003, the class has to change as
    > well.
    >

    That's not the point. The example was merely an illustration of how
    object allocation can be optimised if required.

    Custom allocators are a common optimisation in C++ where many small
    objects are dynamically allocated.

    --
    Ian Collins.
     
    Ian Collins, Apr 11, 2008
    #8
  9. "Razii" <> wrote in message
    news:...
    > On Fri, 11 Apr 2008 03:35:53 GMT, "Mike Schilling"
    > <> wrote:
    >
    >>And you're wrong, as has been demonstrated repeatedly. There's no
    >>point trying to explain this any further.

    >
    > There was nothing wrong with my basic premise that creating objects
    > with on heap is much faster in java than in c++.


    Your premise was that each C++ "new" does a system call.. That's
    nonsense, as what you quote below demonstrates.

    >
    >
    > ---- quote---------
    > Creating heap objects in C++ is typically much slower because it's
    > based on the C concept of a heap as a big pool of memory that (and
    > this is essential) must be recycled. When you call delete in C++ the
    > released memory leaves a hole in the heap, so when you call new, the
    > storage allocation mechanism must go seeking to try to fit the
    > storage
    > for your object into any existing holes in the heap or else you'll
    > rapidly run out of heap storage. Searching for available pieces of
    > memory is the reason that allocating heap storage has such a
    > performance impact in C++, so it's far faster to create stack-based
    > objects.
    >
    > Again, because so much of C++ is based on doing everything at
    > compile-time, this makes sense. But in Java there are certain places
    > where things happen more dynamically and it changes the model. When
    > it
    > comes to creating objects, it turns out that the garbage collector
    > can
    > have a significant impact on increasing the speed of object
    > creation.
    > This might sound a bit odd at first - that storage release affects
    > storage allocation - but it's the way some JVMs work and it means
    > that
    > allocating storage for heap objects in Java can be nearly as fast as
    > creating storage on the stack in C++.
    >
    > [...] In some JVMs, the Java heap is quite different; it's more like
    > a
    > conveyor belt that moves forward every time you allocate a new
    > object.
    > This means that object storage allocation is remarkably rapid. The
    > "heap pointer" is simply moved forward into virgin territory, so
    > it's
    > effectively the same as C++'s stack allocation. (Of course, there's
    > a
    > little extra overhead for bookkeeping but it's nothing like
    > searching
    > for storage.)
    >
    > Now you might observe that the heap isn't in fact a conveyor belt,
    > and
    > if you treat it that way you'll eventually start paging memory a lot
    > (which is a big performance hit) and later run out. The trick is
    > that
    > the garbage collector steps in and while it collects the garbage it
    > compacts all the objects in the heap so that you've effectively
    > moved
    > the "heap pointer" closer to the beginning of the conveyor belt and
    > further away from a page fault. The garbage collector rearranges
    > things and makes it possible for the high-speed, infinite-free-heap
    > model to be used while allocating storage.
    >
     
    Mike Schilling, Apr 11, 2008
    #9
  10. Arne Vajhøj

    Ian Collins Guest

    Razii wrote:
    > On Fri, 11 Apr 2008 17:26:01 +1200, Ian Collins <>
    > wrote:
    >
    >> That's not the point. The example was merely an illustration of how
    >> object allocation can be optimised if required.

    >
    > Where are these objects deleted .. does the time includes that? As I
    > showed in the loop, in the case of java GC collects most of these
    > objects in the loop.
    >

    As I pointed out earlier, you are leaking memory. Didn't you realise
    that? Do you read peoples responses?

    --
    Ian Collins.
     
    Ian Collins, Apr 11, 2008
    #10
  11. Razii wrote:
    > On Fri, 11 Apr 2008 03:35:53 GMT, "Mike Schilling"
    > <> wrote:
    >
    >> And you're wrong, as has been demonstrated repeatedly. There's no
    >> point trying to explain this any further.

    >
    > There was nothing wrong with my basic premise that creating objects
    > with on heap is much faster in java than in c++. Google search
    > confirms..


    Your quote confirms that your claim that each 'new' causes an OS call
    is false.
     
    Juha Nieminen, Apr 11, 2008
    #11
  12. Razii wrote:
    > That is not the topic. The topic is how the keyword "new" behaves.


    You just don't get it, do you. Your original claim was that "new" in
    C++ is slow "because each new calls the OS". That's just false. Each
    "new" does *not* call the OS.
     
    Juha Nieminen, Apr 11, 2008
    #12
  13. Arne Vajhøj

    REH Guest

    On Apr 10, 9:58 pm, Razii <> wrote:
    > On Thu, 10 Apr 2008 21:43:45 -0400, Arne Vajhøj <>
    > wrote:
    >
    > >I can not imagine any C++ runtime that makes an operating system
    > >call for each new.

    >
    > >The runtime allocates huge chunks from the OS and then manage
    > >it internally.

    >
    > Testing the keyword "new"
    >
    > Time: 2125 ms (C++)
    > Time: 328 ms (java)
    >
    > Explain that. What I am doing different in java than in c++? Code
    > below..


    What you are doing differently is not freeing the memory. Since you
    are allocating gobs of memory, and not releasing it, the C++ version
    will incur the cost of page faults, virtual memory access, disk
    thrashing, etc. You are timing a lot more than just memory
    allocation. Of course a lot of people use contrived examples like
    this to prove their pet language is faster than another. What a waste
    of time...

    REH
     
    REH, Apr 13, 2008
    #13
    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. Ian Collins
    Replies:
    0
    Views:
    572
    Ian Collins
    Apr 11, 2008
  2. Roedy Green
    Replies:
    14
    Views:
    1,208
    Mirek Fidler
    Apr 14, 2008
  3. asterisc
    Replies:
    6
    Views:
    498
    Mark Space
    Apr 12, 2008
  4. Ian Collins
    Replies:
    2
    Views:
    547
    Matthias Buelow
    Apr 11, 2008
  5. Juha Nieminen
    Replies:
    10
    Views:
    583
    Mike Schilling
    Apr 13, 2008
Loading...

Share This Page