We can banter about all day on the cost of memory management in Java vs. C++. At the end of the day there is no practical way to measure it and it's not why we moved to garbage collection anyways. That said, object allocation in generational space based heaps has proven to be a huge performance win. You talk about cheap allocation. The reason we have cheap allocation is that generational spaces makes fast-path allocations possible. And for the same reasons, generational spaces makes reclamation almost free. In the spirit of "there is no free lunch", the cost of generational spaces comes when you need to move things from one memory pool to another. But again, this cost is generally smallish in most systems because most data is discarded after a few machine cycles. One or two Java specific instructions on the processor would allow the JVM to ensure that many of the dead objects that are still in the processor's cache lines wouldn't never see the light of RAM. This optimization is *only* possible in runtimes that rely on garbage collection. Ok, i could be possible in C++ also but only at a huge complexity cost.
> But in the average, Java is faster simply because 90% of the responsibility > for memory management is on the shoulders of the runtime; so a mediocre > programmer (or just a good programmer who has too much stuff to do to waste > time in optimization) will easily write a program that has good memory > management performance. This is harder in the case of C/C++, where, for > memory-intensive systems, you can easily beat Java's performance but you need > either a quite good programmer, or lots of time to burn in optimization - > preferably both. You know, I was in an interview with a company that was proto=typing in C++ because they believed in some of the arguments put forth here.and I think that demegrating Java developers is just down right wrong. I used to work in Smalltalk, C, C++ and various forms of assembler when needed. I spent today looking at some C++ code that I need to port to OSX so that I might get a better view of chip level counters. I wasn't the only Java developer looking at this stuff. Why are all these C++ guys working with Java? It's because I want to solve interesting problems and while mucking about with pointers is a nice recreational programming sport for some, it's no longer interesting.for me. The C++ bigotry that existed in the company that interviewed me also brought that company down. Their clever C++ guys could have easily as been working in Java and they might have made it to market before their funding ran out. (I declined the offer). You're statement that one can easily beat a Java programmer isn't so true in a general sense. The JVM can optimize to instruction sets that are specific to single rev's of a specific chip. GCC isn't going to do that for you unless you build a different binary for every different version of every single chip out there. It's impractical and so one builds to the common instruction set leaving some nice performance optimizations on o the table. NUMA is one example where your application doesn't need to be recompiled to take advantage of different chip architectures. Some of the optimizations provided my the JVM produce non-obvious native code that I doubt that even the best optimizing C++ compilers could provide. Try looking at the assembler dumped from a fast debug version of the JVM and ask the question, could I have hand rolled that? Ok, in some cases the answer will be yes but there will be just as many where the answer was no. Regards, Kirk > > A+ > Osvaldo > > On Thursday, December 1, 2011 7:36:04 AM UTC-5, KWright wrote: > Sure you can. The so-called "placement new"[1] allows you exact control over > where you stick your objects. > There are also various implementations available, such as pool[2], from the > Boost libraries > > There's a limit to how far you can take this though. C++ still forces you to > make a lot of it far more explicit, so there's a cognitive overhead to how > far you can take it in an ever-growing system. > It also makes for some real fun and games when debugging & profiling > > [1] http://stackoverflow.com/questions/222557/cs-placement-new > [2] > http://www.boost.org/doc/libs/1_48_0/libs/pool/doc/html/boost_pool/pool/introduction.html > > > On 1 December 2011 11:04, Ricky Clarkson <[email protected]> wrote: > I imagine that implementations of malloc/free exist or could be written that > preallocate. Thus this advantage can be achieved in C. > From: Kevin Wright <[email protected]> > Sender: [email protected] > Date: Thu, 1 Dec 2011 11:46:34 +0000 > To: <[email protected]> > ReplyTo: [email protected] > Subject: Re: [The Java Posse] Non biased performance comparison between Java > and Objective-C on GNUStep > > Actually, one of the main performance benefits Java has is pre-allocating > memory. > > C/C++/etc will often grab their (non-stack) memory on demand via malloc/free, > which is what default invocations of new and delete will actually do behind > the scenes. > Java grabs a big lump up front, "allocation" is then reduced to moving a > pointer up and down this pre-allocated heap space. > > malloc is slow, sometimes very slow, it all depends on your OS, virtual > memory, paging, etc, etc. > Moving a pointer is very very fast. > > Other JVM optimisations aside, this one difference alone can make Java > programs significantly faster that C/C++/Obj-C equivalents. > > > > On 1 December 2011 11:35, Carl Jokl <[email protected]> wrote: > This is not any kind of flame bait thread. > > I am hoping to get some unbiased information on the relative > performance difference between Java and Objective-C. > > More specifically using up to date versions of the Java 6 JRE and > using an up to date GNUStep implementation of Objective-C both running > on Linux. > > I can find quite a few articles with people comparing Java vs C++ but > I suppose Objective-C is more niche and tends not to be used in > comparisons. > > I know that the opinion still prevails in many circles that Java is > slower and/or significantly slower than code written in C/C++. There > have been articles more recently stating that Java was capable of > outperforming C++ these days. > > I am cautious with benchmarks because obviously if someone is trying > to prove a point, that person can be selective about using benchmarks > which support their case. > > I know for example that Java has performance limits doing lots of > heavy floating point operations or trigonometry due to not using > native acceleration where it would cause the values to be less > accurate than required by the specifications (Though I believe this > was being addressed). > > That used case may only apply to applications that use a lot of > floating point calculations. Many business web based or enterprise > applications may do very little floating point number crunching. > > For the sake of context I am in a company that has a system where Java > is used with Servlets to provide a web front end to a system the core > of which is written in Objective-C running on GNUStep. > > Considering the dates in some of the Java source I know the system > must have existed at least as long ago as the year 2000. > Back then the versions of Java would have been a lot slower. Java 6 > included a big performance increase. It would have made sense back > then to argue that the Objective-C code was going to probably perform > better than Java. Now I don't think the difference would be as big. It > would be within my margin of error that Java may outperform Objective- > C due to compile time optimisation that can be done in Java that > cannot be done in Objective-C that is more geared towards dynamic, > runtime behaviour. In that case I would expect C++ to be faster than > Objective-C generally speaking. > > I am hoping to get some feedback from the community to sanitise my > assumptions here. > > I don't want to end up looking like an idiot if Objective-C > significantly outperforms Java. > > The JNI overhead of having Java talk to Objective-C could cancel out > or more than cancel out any performance gains in Objective-C if the > difference is only slight. This depends also whether the cross > communication comprises of many small JNI calls vs few calls that do a > lot of processing before the call returns. > > Any performance information / experience would be helpful. > > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/javaposse/-/5XaYGBOmjx4J. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
