In the general case, in C/C++ you cannot have the same allocation efficiency of Java or other modern garbage-collected systems - these include not just "new is just ptr++", but other important things like multithreaded allocation without synchronization, or automatic NUMA optimizations. The problem is that all these nice tricks rely on the ability to eventually move objects to other addresses, e.g. in order to defragment the heap (to make bump-point allocation possible). And you cannot do that in a non-GC-safe language.
Sure you can program special C++ allocators that can be used in very restricted scenarios, but it's never the same thing, and adds even more to the complexity of memory management. On the other hand, it's also way too simplistic to declare Java superior because of that. Allocation is faster, but deallocation (GC) is the problem. Some programs can exhibit extremely superior performance in deallocation too - basically, programs that make generational collectors happy - but this is not always possible, and there are other problems like cache and paging efficiency, and also other traits of Java (limited typesystem without structs and other "lightweight" constructs) that cause disadvantages but are completely unrelated to manual vs. automatic memory management. 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. 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.
