Re: What about Java?
% Comparing to debug build shows that Java
> is well within the same ballpark as C.
No, it doesn't - it's apples to oranges. It's akin to comparing bytecode to JIT for Java, because the debug build is basically built to be interpreted by the debugging system. Sun's jdb debugs the *bytecode*, not the native code put out by the runtime - there's a more direct comparison.
> In Java you don't have separate "debug
> builds" or build for specific
> processors. Java generates processor
Yes, and that is one of the downfalls of trying to debug Java apps. That's why Java's turned from "Write once run anywhere" to "Write once, debug everywhere and then tweak for OS X. Oh and while you're at it, try a different runtime and fiddle with the runtime switches too."
> Those numbers compare Microsoft's VC++
> to Java, and Java is doing array bounds
> checking. And the IBM JVM seems to be
> ~1.8x faster than Sun's for this type of
> computation, making it very close in
> speed to a C++ compiler were LOTS of
> resources have been put into maximum
IBM is throwing everything they've got at their Java runtimes and also for the sake of clarity,
those numbers compare VC++ 6, not 7 or 7.1, the Intel compiler or GCC 3.3. Can't say for sure about GCC 3.3, but I know the latest iterations of the MS and Intel compilers produce faster code than their predecessors, in most benchmarks at least. Your test was done with JRE 1.3 which post-dates Microsoft VC 7. And the Sun JRE 1.3 is actually faster than Sun JRE 1.4 for most of the benchmarks I've seen and done myself - same with IBM 1.3 vs. 1.4 on Linux. I'm sure the new StrictMath requirements for Java have something to do with the slowdown, but also I think (and have picked up elsewhere) it's because the earlier Java optimizers were optimizing away valid code in some cases.
> If 1.2x or even 2x slower is not an
> acceptable performance loss for getting
> an easy to use, safe language with huge,
> quality class library for programs that
> spend most of their time idle waiting
> for user input then what's the point in
> logic and reasoning? You have to use
Like I said in my previous post, I'd be foolish to ignore all that and I'm not, but I would have to qualify "easy-to-use" and "quality" a bit: Most of the C++ GUI toolkits in this article are as straight-forward to use as Swing and are certainly as high in quality. Which brings me back to the original reason I posted - It would be equally foolish to stop using and improving C++ or C++ tools just because Java is out there.
> You should read up more on hotspot and
> runtime optimizations.
If Hotspot is so technologically superior, why is IBM taking it to the cleaners on a lot of numerical stuff? :-) I have read-up on Hotspot to try and figure out if the marketing hype was blowing smoke and sure enough they were IMHO. Once again, the static C/C++ compilers will have almost of the same info. available at compile time as Hotspot will at runtime wrt inline opimizations, except for some program flow and mem. info. Plus, the C/C++ binary will not be continuously using system resources at runtime to accomplish it's optimizations.
Re: What about Java?
> Check out some benchmark results:
> benchmark results
> I ported these micro-benchmarks from C
> to Java. These show unoptimized C
> speeds for Java, and there was a
Thanks - I took a close look and two things jump out: One is that it seems you and the benchmark post are drawing some conclusions comparing de-optimized C code to other runtime systems. This is not valid because the added debug symbols and forced-order execution of the debug binaries, etc., etc. are both something that a compiler writer would never (consciously) create for a production executable. What I'm trying to say is that debug builds for any compiler / runtime are not valid for any benchmarking, because that is not what is distributed to an end-user but is for the consumption of the development tools and developer only - that's a well established standard for fair benchmarking. I don't know why the C debug-build times are even included in that post, unless the reason was to try and show that Java and Smalltalk can perform "OK" compared to a binary compiled for a debugger. Debug builds are intentionally "de-optimized" so the program flow can be better followed by a debugger, etc.
The 2nd thing that jumps out is that a normal (built for production) C/C++ binary is on average 2.3 times faster than the Java code. If you extrapolate that out to real-world software, that means for example an end-of-day process that runs for 8 hrs. with C/C++ would take 18.4 hrs. with Java, which would leave only 5.6 hrs. for a workday (I'd love a job with that company :-). Also, even considering processes like the short-lived micro-benchmarks in your link, a 2x difference in execution time on a busy machine can cause an exponential drop in scalability of the server as processes stack up in the FIFO column. And that is not even considering the extra resources that runtimes like Hotspot use on the server. The code analysis, JIT, optimization and generational GC that Java runtimes like Hotspot and the .NET runtime do is really pretty expensive in a high-use environment and that is always overlooked. Hotspot is a resource hog in a heavy-use environment. What does this have to do with client-side GUI toolkits? Nothing except to say that I think Java has been over-extended to be the end-all to application development so it is neither really scalable on the server nor really fast on the client.
> This isn't the appropriate forum for a
> lengthy technical discussion, but
> Hotspot is insane. It will re-write the
> code for method while it is executing.
> It'll dynamically 'inline' more methods
> at a time than C++ would ever dream of
> since it can throw the optimizations
> away when they are no longer used by the
> program. And so on. Often a method
> invocation will take fewer mechine
> instructions in Java than C++ due to
> better knowledge of actual types at the
> call site.
Again, this sounds like it's from the Sun site :-) Under almost all circumstances, the static C/C++ compiler will have as much info. to feed "inline" heuristics as the Java code at runtime, plus it will have a lot more time to (reasonably) use this info. The major areas that a dynamic execution system may have an advantage are things like it will better know how much memory has been allocated for an object or collection of objects, and also the normal conditional path flow of the program. So what end's up happening is that more things in the C/C++ code is optimized than needs to be under normal program flow, but the upside is it is well optimized for all program flows.
> % code on any benchmarks 'proving' this
> % you have it.
> % Check out: Linux Number Crunching.
> What a crappy benchmark. The code
> quality is extremely poor, with unused
> variables all over the place and other
> variables used for multiple purposes.
> Most of the time in Java is spent in
> Math doing trig functions and much of
> the rest is in array access checks, so
Extremely poor?? I only found two unused vars. (32 bit integers), and so did the compiler. Like it or not, most time spent in many programs is calling library functions and accessing arrays, so this is a pretty valid benchmark as far as they go.
> Java has had excellent results doing
> real math, like linear algebra and FFT.
> Plus any benchmark showing C++ and
> FORTRAN as equivalent obviously is too
> simplistic to be an accurate indication
> of performance.
Well, I don't agree there. There are many areas in which C/C++ can hold it's own with Fortran, and that includes some often used mathematical stuff, even stuff that includes large matrices and math library calls. For example, depending on the circumstances, it's possible to layout large arrays and manipulate them with the C/C++ memory functions better than you can with the array handling built-in to Fortran (or Java for that matter). Besides, based on the results I've seen, the Intel Fortran system is very good and so is their C/C++ system.
> % Also check out: The Petstore
> % and download the report.
> Trying to conclude anything useful from
> Petstore is a waste of time.
No it isn't, for 3 reasons. The people who chose Petstore were Java biased in the first place (Java is where that company makes it's money) and initiated the 2nd comparison. The second reason is that the .NET and Java apps. were functionally equivalent. The third is that the .NET system ran quite a bit faster and was a lot more scalable on the same hardware than both Java systems with a lot fewer lines of code and much less time spent optimizing the code for either Java runtime. It is very significant that the lower cost and easier to maintain system can come out on top performance-wise for a functionally equivalent application where the sponser's hypothesis was disproved (according to their paper, the sponser set out to prove that Java would be the performance leader if optimized properly).
The reason I'm responding to all this is because you stated that C/C++ GUI toolkits are no longer relevant given Java performance and that is wrong given the the scads of "real-world" evidence as well as benchmarks.
I'd be a fool to ignore the usefulness of Java and I think it would be equally foolish to say there isn't a place at the table for cross-platform C/C++ GUI toolkits because of Java performance.