On Friday, December 2, 2011 8:59:50 PM UTC-5, kirk wrote: > > 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. >
Unfortunately this is only true if, when the GC is triggered, most objects in the young-gen are dead. But GC will rarely coincide with these ideal times, unless you call System.gc() in the right places, which is viable only for single-threaded apps. If you're unlucky and GC happens when you're in the middle of some massive task and there's a ton of live short-lived objects, then GC has a relatively high cost. And that's still best-case wrt the old-gen; the real perf problem comes to apps that produce a continuous (even if small) stream of medium-lived objects, which are promoted to the old-gen but will eventually die, requiring some full-GCs. This is extremely common, so there's a ton of effort to make full-GC faster with incremental and concurrent collectors etc. Of course, microbenchmarks that apparently shows that GC is faster than manual allocation, never have these problems, they're usually programs with excellent generational behavior and completely stable old-space. In summary, YMMV a lot with app behavior. > 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 > Notice that I'm a strong Java advocate too :) so I'm not denigrating anything, but also I don't think that exaggerating Java's real-world performance serves any good purpose either. I also worked with everything from ASM/C/C++ to Java, so I'm well informed about what is possible to do in lower-level languages. You are correct that these languages will lose in aspects like time-to-market, and also, the convenience of JIT compilation is great for apps that have to be installed in many different systems... on the "C/C++ can easily beat Java", I was discussing CPU+memory-intensive applications, not apps that spend most time waiting for a database or some other I/O. Or have many concurrent users (heavy multithreading means that CPU caches are wiped out all the time due to task switching - so the much superior memory locality of native apps with manual memory management is less win.) But these two sentences describe >90% of all software projects these days, so yeah a native language will not be "easily faster" and this certainly contributes to the success of Java. A+ Osvaldo > 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 view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/IYRKaWnRgpMJ. 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.
