Slashdot Mirror
Build Your Own Java Performance Profiling Tool
An anonymous reader writes "IBM DeveloperWorks has an interesting look at creating a custom profiler using Java 5 and AOP. From the article: 'Profiling is a technique for measuring where software programs consume resources, including CPU time and memory. This article provides a list of best-of-breed features you might look for in an ideal profiler and explains why aspect-oriented techniques are well suited to achieving some of those features. It also introduces you to the JDK 5.0 agent interface and walks you through the steps of using it to build your own aspect-oriented profiler.'"
Byte-code hacking!?
Why not simply use AspectJ?
I use the JVMPI by sun which IMHO does a pretty good job and is extremely easy to use. However the custom profiler looks easy enough and will probably be much more accurate. Worth a try for sure.
The only popular languages faster than Java are Assembly, C, C++, and Fortra. All of which take are enormously difficult to use for large scale projects.
Java's a speed demon compared to almost all other programming languages out there. So what if it's 1/5 (warning : 97% of statistics are made up on the spot...) the speed of Assembly?
That is pure Flamebait.
Java is a language which benefits more than most from performance profiling, in that
it is very easy to write inefficient code, because the mapping from code to actual
execution is not always very clear.
This is a strength, and a weakness. The degree of abstraction from the underlying
machine is high. This results in quite intelligible code, and an ease of coding complex
and abstract tasks. It also results in it being quite possible to write apparently
simple looking code which ends up executing in a very complex way.
Profiling will expose the gross inefficiencies, and allow them to be corrected.
It will never be possible to write as efficiently (execution time), as
in a more direct language, but the coding efficiency (programming time) is quite good,
and for a lot of applications that matters a lot more. It also has a lot of
cross platform capabilities (not perfect I concede).
I prefer writing code where I can see the bits and bytes (i.e. not Java), but
to put down Java in such an off hand way is unjustified.
--shit, sorry, must have trashed a pointer somewhere. hang on, this'll just take a minute...
Download jrat here
I've used it many times, and it's helped me find horrible Hibernate queries, Lucene bottlenecks, Batik rendering pipeline issues. It is fantastic.
[% slash_sig_val.text %]
That's simply not true. I work on a large Java project that deals with a lot of matrix intensive work. Our Java code has been rigorously architected, engineered, and optimized. The matrix code in particular (where the majority of our processing time is spent) is far superior in Java than it was in C or C++. Every programming language has its place, use the one that suites your needs. Profiling most any code can reveal useful information.
You're implying that there are languages (other than Java) that don't ever require profiling which is simply rediculous.
I've worked on quite a few contracts where I was part of a massive 3 ring circus to collect Java metrics, so we could make pie charts for PHBs to show their PHBs. Of course the coders with half a brain already knew where their bottlenecks were. Glad to see all my efforts are being taken so seriously.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
The matrix code in particular (where the majority of our processing time is spent) is far superior in Java than it was in C or C++.
If your code is targetted to a specific platform then all that says is your C/C++ coders were idiots. The only case where a jitted language exceeds a natively compiled language is where the JIT compiler can apply optimizations the native code compiler cannot for compatibility reasons (eg avoiding SSE3 when you might run on an older CPU).
There is no excuse for heavy math code such as matrix processing to be faster in Java than C/C++. In the absolute worst case, you can simply take the machine code generated from the Java JIT and reproduce better code in C/C++.
Fear: When you see B8 00 4C CD 21 and know what it means
Sure, JRat is interesting, but I like the DeveloperWorks article's idea of taking the *exact* bytecode you'll be running and instrumenting it. Now if I can just figure out how to shoehorn it into Tomcat ...
Here you go, be sure to thank HP for them.
d ex.htmln e/index.html
http://www.hp.com/products1/unix/java/hpjmeter/in
http://www.hp.com/products1/unix/java/java2/hpjtu
silent memory corruption or npe w/stack trace, take your pick.
Seriously. Modifying a program to profile it?
I'd do that, but I'm a hybrid java developer/IT d00d. Most IT folk I know wouldn't touch a profiler with a 10-foot pole, much less write one and semi-build it into an app. This is a programming topic, not an IT one.
"Time flies like an arrow; fruit flies like a banana." --Groucho Marx
Using hprof and decent unit testing, you can work out where your problems are, I've found. All of this bytecode hacking and AOP stuff might show how l33t you are, but I'm not convinced it's really *needed*. Just my humble, uninformed opinion, of course, I'm very willing to hear from others. It could be that I'm just not working on sufficiently complex systems, or that I'm spending more time writing unit tests and pouring through hprof results than most folks.
I agree totally. Java is dead. We just have to get the message through to the huge numbers of organizations and developers who depend on the technology to get their jobs done. Oh, and then we have to come up with something better to replace it. Give me a little while... ;)
Actually, the post to which you replied never said the Java solution was faster than a C++ implementation. He said it was "superior". True, it is a vague term, but for his organization, superior may mean "easier to maintain", "smaller codebase", "easier to use on other hardware platforms", or any other number of possibilities.
The idea of being easily able to measure where a program is using resources appeals to me. It might settle a few arguments around here.
Programming in C with a monkey chewing on your arm. I see students doing that all the time. They struggle for hours to write code that they could do in minutes with a higher level language. They look like they are having about as much fun as if they had a monkey chewing on their arm for sure. Usually, for what they are doing, speed of execution is irrelevant.
I often hear C programmers insist that they can be as productive as someone writing in a higher level language. They say it's just that the people writing in the higher level language never learned to program properly. Actually they're right about that one. Many people who get paid to write in higher level languages aren't really good programmers but that doesn't prove anything about the innate goodness of the languages in question.
We have gotten to the point where being able to write at a low level isn't as advantageous as it used to be. For instance, it used to be possible to write key elements of code (for DSPs in my case) in assembler. With modern tools, that advantage has evaporated. Trying to code by hand often creates much slower code. (Actually in this case, C is the higher level language.)
My own preference for a higher level language is Python. The large majority of the time, there is absolutely no useful benefit that I could get by writing in C.
Anyway, your comment about programming in C with a monkey chewing on your arm, reminded me a lot of an ongoing argument with the people who teach programming around here. The students do need C because they do a lot of embedded stuff, but the rabidity of some of the C folks does seem a bit overboard. Sorry if you got caught in the crossfire.;-)
Sorry , but no. The matrix library we use was written in C++. We used a Sun Blade 1000 system (SSE free) and the Sun compiler to run an extensive set of sample calculations. The code was ported in house to Java 1.5, making only minimal changes to make it Java compatible. The same sample calculations were performed using the Java library and were approximately 15% faster. We initially thought we had done something wrong, because we all assumed the C++ code would be faster. We verified, verfied again, and verified some more. A few changes were made but the Java code just got faster. Believe what you will, but in this case the Java was faster, and we had the metrics to prove it.
I'm looking for an application that will monitor a specified application and log how long the application is "not responding".
We use CAD (Computer Aided Design) software, and I would like to justify new hardware by being able to say how much less time we would have to spend waiting on the software if we had faster computers.
If I had a way to measure how often the cursor was an hourglass in our CAD software during the course of a standard workweek and then benchmark this on a new computer I could have a metric that I could use for justification.
Anyone know about anything like this?
Steve
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Depends what you mean by "speed". For example, compare how long it takes to fire up ANT, compared to Ruby's Rant. Both are build tools offering roughly equivalent functionality.
Results:
$ time antBuildfile: build.xml does not exist!
Build failed
real 0m1.233s
user 0m0.188s
sys 0m0.043s
$ time rant
rant: [ERROR] No Rantfile found, looking for:
Rantfile, rantfile, root.rant
rant aborted!
real 0m1.071s
user 0m0.089s
sys 0m0.015s
Ruby's an interpreted language, and it's one of the slowest in its class. (Slower than Python or Perl). It's loading in all the libraries as source code and interpreting them. Yet it still wipes the floor with Java at speed of startup. And that's before you actually start building anything--the first time I used Rant, it was so much faster than ANT that I thought I must have done something wrong.
Try launching a major Java GUI application, and you can profile the application startup speed with a manual stopwatch. Try launching a J2EE setup, and compare it with starting up Ruby on Rails.
Java isn't going to lose its well-deserved reputation for slowness until some major work is done on startup speeds.
(And yes, I'm using Java 1.5.0.)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Ever heard of HotSpot? Java JVM does runtime optimization that C/C++ can't. No it doesn't happen in a two second bench test designed for C to prevail, but use in real life applications the JVM performance improves with longer runs. If you honestly look into it and realize that your "java is slow" mantra is a bit dated or is that a SlashDot fact that is not refutable?
if vegetarians eat vegetables why are cannibals not humanitarians.
Just raise the taxes on crack.
What matrix library were you using for C++? Was it hand-rolled, and if so was it faster than C++ matrix libraries like Blitz++?
"Quick! Name a successful Java program. Nope. I can't think of one either."
.NET.
Gmail. It uses Java for almost all of its back end. In fact almost all of Google's large scale web applications use Java in some form. Python is also used extensively however, it's generally used for simple scripts and smaller applications. Tons of websites use Java extensively and people like you are just too dumb to realize it. If you do online banking it's almost guaranteed that the website is using server side Java.
In terms of client side applications there's; Azureus, LimeWire, Eclipse, Netbeans, Intellij IDEA, Yahoo Site Builder, ZipCreator, Summit Groupware, jEdit, SmartCVS, NeoOffice etc. etc. Just because you don't use them doesn't mean that they're not there. The truth is that most people only use a very select few programs and these programs are often using code bases that are over 10 years old (ie. Microsoft Office, Outlook, Internet Explorer etc.). Then there's all the enterprise applications that are written in Java.... In the enterprise world Java is dominant and the only real competitor is
I forget the name of the C++ library and it's past 5 o'clock here so everyone has left. We have moved on to the Colt http://dsd.lbl.gov/~hoschek/colt/index.html matrix library.
There is no excuse for heavy math code such as matrix processing to be faster in Java than C/C++. In the absolute worst case, you can simply take the machine code generated from the Java JIT and reproduce better code in C/C++.
Following your logic I rather would write: There is no excuse for heavy math code such as matrix processing to be faster in C/C++ than in Java. In the absolute worst case, you can simply take the machine code generated from the C/C++ compiler and reproduce better code with the Java JIT.
Bottom line: you have to admit that there is an "optimal" code for doing a certain matrix problem (general matrix is different from a diagonal one e.g.). It does absolutely not matter if that optimal code is generated by a C++ compiler or by a Java Jit.
For general purpose computing Java is as fast as C++, since 4 to 5 years. Even Doom clones and 3D engines are written in Java in our days
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You need a real unix like solaris for this feature and not linux.
Although I heard linux has limited support for profiling these days I dont know how good it is for monitoring regular applications in userspace.
http://saveie6.com/
Sorry, but you are wrong. For some things Java can never be as fast as C/C++ due to the definition of the language itself - things like lack of value objects, specifics of method dispatching, late binding, etc.
I don't want to go into details here, but as a good example of Java's inefficiencies think about an array of complex numbers in Java and C/C++. Java is at least an order of magnitude slower in this particular example and no JIT can ever fix that unless the language itself is changed. If you don't believe me and you know C and Java you can even try it - write a small program performing a simple operation with the array - for example sum of the elements.
Admittedly matrix algorithms do not necessarily exhibit the problems I am talking about. However I sincerely doubt that the current generation of JAVA JITs do complex optimizations like loop reshaping, cache blocking, prefetching, etc.
Never use the word "best-of-breed" again. Or else.
Sorry, we are on Windows. They don't even write a *nix version of this software. Anyone know of a not-responding process monitoring app for Windows? Steve
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
You are grossly misinformed about the inefficiencies of Java. It is extremely easy to examine two languages and design a 20-line test that shows that one is faster than the other.
This does not make Java "an order of magnitude slower...", a real test of requires two seperate developers, with roughly equal skill in their respective languages, given a general problem and the task of implementing a solution, then comparing the resulting applications.
Given those results, the first thing you'll note is that all the specific instances you previously cooked up (your "Fool's loop test") which proves Java is slower doesn't matter, because the Java-equivilant solution to an actual problem is entirely different. Everything about the structure of the code, where and when messages are sent, right down to the type and size of objects will be entirely different between languages.
Your test uses the assumption that in order to test Java's execution speed, the only necessary step is to take a program in C++ and translate the code, line for line, into Java syntax. The difference between programming languages is not in the syntax.
Your test is like redoing a physical structure by, beam for beam, replacing it with a different material. As any architect can tell you, the placement of the load-bearing beams will need to be dramatically altered depending on the material you use. If you take the design for a timber home and instead use concrete, the whole thing will cave in. Does this mean that concrete is weaker than timber? But yet, if you take a timber plank and slam it into a concrete wall it'll splinter into pieces. Wow, what a bizarre phenomenon!! It's as if, under different circumstances, each material has varying levels of suitability.
Your test is as ridiculous as arbitrarily declaring a search engine superior based on the results of a single keyword. "I'll prove Yahoo is the best! If you search for 'chicken', Yahoo returns better results! Therefore Yahoo is superior to Google!"
Following your logic I rather would write: There is no excuse for heavy math code such as matrix processing to be faster in C/C++ than in Java. In the absolute worst case, you can simply take the machine code generated from the C/C++ compiler and reproduce better code with the Java JIT.
.... get a clue, go with the time, stop repeating over half a decade old mythes.
No, you can't. The language restrictions of Java are far more significant than the language restrictions in C. For example, you cannot perform unchecked array access in Java on arbitrary memory. In a very real sense, Java's performance on a given platform has an upper bound at C's performance.
Bottom line: you have to admit that there is an "optimal" code for doing a certain matrix problem (general matrix is different from a diagonal one e.g.). It does absolutely not matter if that optimal code is generated by a C++ compiler or by a Java Jit.
There is definitely optimal code, and I am saying that that code will not be able to be produced by a Java JIT compiler because the structure of the java language is unable to deal with it as efficiently as the structure (or absence of structure) that the C language has.
The Java code will probably be more maintainable and less error-prone, but to suggest that it will outperform optimized C code is patently ridiculous.
For general purpose computing Java is as fast as C++, since 4 to 5 years. Even Doom clones and 3D engines are written in Java in our days
Java is not as fast as C/C++. It's simply a function of the language. In optimized cases, the speed difference may not be great but Java does have performance penalties defined by the language (garbage collection, checked array access, etc.) that are simply not present in C. You might write a Doom clone, but you sure won't write a F.E.A.R. clone. Take your binders off and realize that the tradeoff for the manageability and elegance of Java is some speed. It's no myth - it's a raw fact.
However, if you still choose to disbelieve me, please post the Java source code you believe will outperform optimized C/C++ code. I'd be fascinated to test it out.
Fear: When you see B8 00 4C CD 21 and know what it means
This perl script. (Or google for "wherehot.pl")
It's a relatively simple script I wrote a while back to filter hprof textual output. It tells you things like "which of the code inside com.foo.* is being slow"? And "which of the code inside com.foo.* is causing StringBufffer.expandCapacity to be invoked, and thereby being slow?".
A further enhancement of it (that I haven't posted yet, sorry) changes the output format to look something like a java stack trace, which means you can take the output of that script, copy and paste it into eclipse's Java Stack Trace console, and be able to click on the lines identified as being slow.
We've found it to be a nice complement to graphical tools that let you visualize what bits are slow, like HPJmeter.
I shouldn't really be replying, since you already said that all the specific instances which prove Java is slower don't matter - how could I argue with that ? However I would like to benefit from your obvious knowledge of the matter.
Also, please note that I didn't say "C/C++ is best", which you seem to be implying in your last paragraph - I was commenting in the context of the thread about Java vs C/C++ performance for matrix computations. I don't care about language wars, because obviously everyone who disagrees with me is wrong ... :-)
I have seen many claims about Java's performance, ranging from reasonable to absurd and ridiculous. For example:
I would love to share my opinion on these subjects some other time, but for this post they are irrelevant.
So, getting back to the subject. Obviously you agree that for the scenario I am describing, Java is slower than C. You contend that this results from "translating line by line from C into Java syntax". OK, enlighten me then. What is the Java-specific solution for keeping complex numbers in an array ? You can go wild - use any Java tool and technology. This is not an artifical scenario. The same problem exists for arrays of 2D or 3D coordinates, actually arrays of anything except primitive types, so if you present a solution I will be very grateful and even offer to buy you a beer ot two (or a dozen!).
No, it is CoCreate OneSpace Designer.
>Its a shame the cad market is going to windows from unix.
I think you meant "from unix to windows"?
I'm not surprised. CAD is becoming more and more a commodity - it is currently running about $5000 a seat for stuff like SolidWorks or Pro/Engineer. There are less and less dollars to spend on things like multi-platform support.
Windows is the predominate desktop environment.
Personally, I don't care what the platform is.
Steve
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
We have a product that requires that profiling be done on a per-object basis. I'm not using the Java class transformer interface, but I am rewriting classfiles in a manner similar to hprof's bytecode instrumentation option (as opposed to the stack sampling option), using JVMTI.
JVMTI + JNI is pretty slick stuff. The source code to hprof comes with the JDK 1.5 release and is very informative, if overwhelming at first. If I instrument methods very selectively, the effect on runtime speed is minimal.
OTOH, trying to implement something like this for Perl (my favorite language) would be an exploration of pain the likes of which hasn't been experienced since people were broken on the wheel.
You don't have the foggiest clue what you are talking about.
Class rewriting is cool, and can be done on a live JVM, even multiple times for the same class if desired. The result runs just like the original unmodified class. It's like *func = sub { print "new sub" } in Perl, but with much greater control and granularity.
Anyway, don't be such a tard in public.
I prefer Mercury's profiler. Its for J2EE or .NET applications but it integrates with Load Runner and Business Availabillity Center. There is a free trail here.
~~ What's stopping you?
Ahh...your typical uninformed slashdot poster...
p er/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4 .html
r k.html
You do realize that array bounds checking is eliminated by modern VM's? i.e. HotSpot. Suggest you read:
http://java.sun.com/products/hotspot/docs/whitepa
The Java version of Quake performs faster than the C version:
http://www.bytonic.de/html/benchmarks.html
Here are some other benchmarks:
http://www.idiom.com/~zilla/Computer/javaCbenchma
http://kano.net/javabench/
Java VM's such as HotSpot have the ability to de-optimize and re-optimize on the fly. C/C++ can not do that.
Stop repeating the lie that Java is slower than C/C++.
Look, nobody is using notepad/vi and javac these days to develop anything. And most of the Java software we develop these days doesn't simply run from the command line. Be it a J2EE application or an Eclipse RCP application, most *free* (as in speech or beer) tools don't do the greatest job when dealing with a predefined configuration, such as the aforementioned.
Please, someone prove me wrong on this, but I can't seem to find a decent code profiler for use with J2EE or Eclipse RCP applications. You can't simply launch them in a JVM and have your way with them.
I have used some plugins for Eclipse that almost do an OK job of this, but even they are limited. The best I've found to-date is:
http://sourceforge.net/projects/eclipsecolorer
Even this one has major warts, though. Such as it only runs reasonably on Windows, while I do most of my Java development on a Mac these days.
I'm sure someone will come along and suggest JProbe, or another commercial product. If the price were right, I'd by any of these as well. Unfortunately, for the moment, it is more cost effective to pepper my code with Log4J statements providing profiling information in the form of a log file and to parse the results myself.
Again, if anyone can prove that I'm incredibly wrong, I'll buy you all the beer you can drink the next time I'm "in your neck of the woods."
http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html
- I don't need to go outside, my CRT tan'll do me just fine.
However I sincerely doubt that the current generation of JAVA JITs do complex optimizations like loop reshaping, cache blocking, prefetching, etc.
But you are wrong.
And your example about complext numbers
You won't need virtual methods in both cases, so you use standard methods (or non virtual operators).
Especially in vector math and matrix operatiosn Java is proofen to be as fast as C++, except for hyper specialized template libraries like Boost, which have factored out special situations into templates.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The Java code will probably be more maintainable and less error-prone, but to suggest that it will outperform optimized C code is patently ridiculous.
Well, you are to narrow minded. Your example about arrays is strictly correct, but modern Java jits REMOVE the array bounds check if they can prove that the index will never be out of bounds. So this arguemnt does not hold
So I only picked the one above.
Please: why the heck do you think that a linked list traversal in Java MUST be slower than "optimized" C code? Whatever "optimized" in that context may mean?
Just because Java has an "not null" check?
Sorry, but sentences like this: because the structure of the java language is unable to deal with it as efficiently as the structure are complete nonsense. Java has only a few runtime checks. Those take not much time. Often during Jit compiling and Hot Spot optimization those checks can get removed, and are removed. At that stage the code is as efficient as C.
Your whole argument chain is not taking into account modern compiler technologies. In fact languages like Haskell or Occaml or Self or Erlang have prooven that OO and functional languages can be transformed to more efficient code than C. C is just transformed "structure" by "structure" into assembelr and is then fix.
Modern compilers do much more controll flow and data analysises and inline much more. The above languages do that mainly even static at compile time, and Self and Java during Hot Spot analysis at runtime. They basicly try to attempt what template metaprogramming does for C++, and they succeede in that (google
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
That's simply not true. I work on a large Java project that deals with a lot of matrix intensive work. Our Java code has been rigorously architected, engineered, and optimized.
It is meaningless to ask, "Which is faster, Java or C++?" because how the compiler, not the language, has a very large effect on that. People who claim that Java is fast because their favourite JVM happens to have some particular optimization they like are barking even further up the wrong tree, because the only speed that matters is the speed that users actually get, rather than the speed that users would get if they were running a JVM other than the one they were actually running.
It is more meaningful to ask: How easy is it to do things really badly in Java vs C++? The answer to that is: it is very easy to write extremely slow Java code, and very easy to write extremely fragile (and leaky) C++ code. I've managed large Java projects and seen how fast good programmers can make Java go, but I've also seen how slow merely average programmers can make Java go. And how much of a resource hog Java can be in the hands of average programmers (and on average VMs). Likewise, my own C++ code is clean and robust, but I've worked with developers who just aren't safe to let near a C++ compiler. Invalid iterators aren't the half of it.
The fact that extremely good programmers can make Java apps fast does not make Java a "fast language" any more than the fact that extremely good C++ programmers can make C++ apps safe makes C++ a safe language. It will always be really easy to write Java apps that move at the speed grass grows and use up all the memory in the machine, and it will always be really easy to blow you whole leg off with C++. Both languages require really good developers to use them well.
Blasphemy is a human right. Blasphemophobia kills.
At $JOB-1 I trialled and bought Yourkit's YJP, which is truly excellent, very easy to use and a very effective tool. Moreover, it's not expensive, and the support is pretty good too. I'm just a happy customer, not affiliated in any other way.
Actually, I have avoided Java like the plague. When I decided to dump Windows and run Linux I had zero Linux or Mac experience. I was looking for a language that would be cross-platform. I was considering Java but then there was a story on Slashdot. The story said that developers at Sun didn't think Java was very good in their programming environment. They recommended a couple of languages and Python was one of them.
.NET or even the VCL technologies, but in moving to other OSes you ahve to recreate or use the equivalent technologies and that requires a lot of rework on some things.
A good environment was Kylix and Delpi (pascal) from Borland for Linux and Windows. Fast compiler, fit both OS frameworks, etc etc.
Borland didn't get the support in the Linux community and has let the Kylix portion slide. Inquire, show them some support or encourage them to open up part of the project for others to help with.
Good old fashioned C/C++ works the best for moving from platform to platform. There is always a Good C Compiler, but that is not always the easy solution. In Windows you get help with
I've written my own java profiler/coverage tool using JVMTI, JNI which publishes results on a dynamic webpage (see Patty @ SourceForge ). One of the problems when maintaining statistics on execution and line number coverage if you keep it in the same JVM is that it has a large performance impact to continuously look up the buckets (like many profilers do), the buckets where the statistics are kept. So one of the things is to bring down this impact by only profiling certain classes, plus sending all the profiling data to a separate computer, which has CPU available to put the data into the stat buckets to be extracted later. (this is the process that is costly to do inside the same process, putting stats into the correct buckets, due to `lookup` code ). I'm using a Tomcat process to gather data for example on a simple text-based protocol. With ByteCode Engineering (called bytecode instrumentation in this case) rather than AOP, the advantage is that you can reload the class later without the instrumentation. AOP is not that flexible. So the advantage is that without any instrumented classes, if your environment is set up correctly, you can even start profiling in production if you wanted to (I would highly recommend not to though). The other benefit of native profilers is that you can put this profiler under every JVM, even code that you don't know anything about, and it allows you to profile anything at will without writing specific AOP junctions or other stuff. (let's not assume you only want to profile your own 'known' code?) JVMTI also allows you to analyze the objects on the heap. If you look into the Sun API, you can see there are various functions to tag objects, which cna be used to filter on specific objects only. I'm using this to make an estimate how many instances of certain objects there are and how much memory they are using. Sun comes out with their own implementations (JFluid for NetBeans) and jconsole. So the benefit of future projects is that it must be aimed at a specific problem not yet solved. My project on SourceForge has full source code available if you wanted to have a look how it works (C and Java). (GPL / Mozilla, you choose)
If you like performance, try the 1.6 VM (beta)! Although it should make much more of a difference on a Windows box really. The code speedup that I got was about 50% for a heavily algorithmic application (cryptographic, mostly SHA-1, unoptimized). I presume it has to do with the better register handling of the VM. This is one of the fun things about Java, it can get faster without recompilation of any source code.
"It will never be possible to write as efficiently (execution time), as
in a more direct language.."
Well, obviously, theoretically you're right. But in practice some Java applications that run under JIT can actually go faster as, e.g. C++ code. Especially if you take some common coding practices in C++ (heavy use of copying constructors etc).
Also a very cool company, as I have had personal replies to my enquiries regarding certain aspects and suggested enhancements...
>I must be missing something. Is "to A from B" somehow different than "from B to A" ???
/said/ "windows to unix" - I think he meant "unix to windows" since I was saying our software was only available on Windows).
I'm not sure what you mean. The fellow was (I think) trying to lament how the CAD market was going from unix to Windows (though he
As I said - I don't care what platform the software runs on.
Steve
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Would the Apple store and the iTunes Music store be considered successful?
Am I really wrong about complex optimizations like cache blocking and prefetching ? I might be - however unless you provide a verifiable reference I am disinclined to believe you. Many static compilers don't even do those.
To answer your question about why C++ would be faster. Examine the C++ declarations below and think about how fast a sum of the entire array would be in each case. If you like to look at the bigger picture, think about memory consumption too.
double arr1[10000];
double * arr2[10000];
I'm not narrow minded, I'm just not a Java bigot like you. The simple fact is you can optimze C code more than you can optimze Java code. All the studies (which I have looked at extensively) show that generic C code can be outperformed by Java but they neglect the fact that the C code can also undergo optimizations. The typical assumption is that gcc is the compiler, which immediately puts the C code at a significant disadvantage. Get a real compiler which allows hinting on aliasing and other things that the Java JIT uses.
Looking at your ridiculous claims:
Java jits REMOVE the array bounds check if they can prove that the index will never be out of bounds
In short, Java *can* be as fast as C if the compiler can prove to itself that the array doesn't go out of bounds. If it can't, then it's slower. My statement remains - the upper bound of Java is optimized C.
why the heck do you think that a linked list traversal in Java MUST be slower than "optimized" C code?
I don't - you're just a failure at english comprehension. I said its upper bound is optimized C performance (where optimized means what the dictionary says it does - that you've made it as efficient as the language allows). This means that it is either slower or equal. I'm even allowing Java the advantage of ignoring JIT time there.
Java has only a few runtime checks. Those take not much time. Often during Jit compiling and Hot Spot optimization those checks can get removed, and are removed. At that stage the code is as efficient as C.
So, my statement is correct. The performance of Java has an upper bound at the performance of C, in the case where all the runtime checks are removed. In the case where they aren't (which you admit is possible) then Java is slower. You see - you're losing your own argument.
Your whole argument chain is not taking into account modern compiler technologies.
Garbage. Your argument is not taking into account modern C compiler technologies, which use everything that Java has available. The fact that I'm comparing optimized C code eliminates any advantage Java has in runtime analysis because optimizing C involves runtime analysis and recoding to suit.
In short, you're the narrow minded bigot here. I'm just stating facts that C allows the programmer much more freedom to optimize the code manually with knowledge that is not able to be represented to a Java JIT compiler.
However, please feel free to continue defeating your own argument with proofs that Java can equal C's optimized performance if the JIT can recognize the conditions as right.
Fear: When you see B8 00 4C CD 21 and know what it means
Ahh...your typical uninformed slashdot poster...
Not guilty. However, you seem guilty of Java bigotry and failure to read and understand research papers.
You do realize that array bounds checking is eliminated by modern VM's?
Of course, and I've read the paper you linked. Thanks for telling me stuff I know and even recognized in my previous posts by saying that Java has an upper bound at C's optimized performance. *If* the runtime checks can be removed then Java array access is as fast as C. If they can't then Java is slower.
The Java version of Quake performs faster than the C version
The C version was compiled for a 386. Recompile it and optimize it and you'll get a hell of a lot more performance than the original. Do you really think that game developers are all idiots for using C/C++ for their game engines instead of Java? Here's a big smack with the cluestick for you - they use C/C++ because it offers better performance when optimized. When I see a game released under Java then I might give you some credibility but until then you're just another tired old bigot comparing a modern JIT with a C program compiled for a 10 year old processor.
Your other benchmarks are just as telling - they compare Java code with unoptimized C code using the worst possible compiler for performance (gcc). You do realize modern C optimization allows the developer to specify pointer aliasing, efficiently use registers and processor features through intrinsics and other optimizations that the JIT uses in the cases that you demonstrate performance advantages over C/C++ code.
Simply put, the only cases where you demonstrate Java advantages are in comparisons to unoptimized C. If all you have is comparisons using C as a baseline rather than comparisons with optimized C then you're deluding yourself and pitching out the lie that Java *is* as fast as C rather than the truth that Java has an upper bound at optimized C's performance.
Java and Hotspots optimize on the fly. C coders optimize better through runtime analysis and knowing meta-information about the code that a compiler can never hope to know.
Fear: When you see B8 00 4C CD 21 and know what it means
Oh, I see now what your point of arguemntatin is:
.... google is your friend. There are at least 100 research papers about exat this topic. Ppl are no longer interested in "optimizing" C compilers, its boring. People research other languages and other problems, e.g. optimizing code generation for OO systems on multi processor (or multy core) hardware.
you always speak about the upper bound is optimzed C. So you want to say: Java is most of the time slower than C, and in the cases where it is approaching C speed, it is at max on equal speed.
Sorry, I have to admit I missed that little word uper bound. In fact it is not nice of you to make a conversation over 3 posts and finally hit me with that into my face.
So let me give you a last small example:
Your argument is not taking into account modern C compiler technologies, which use everything that Java has available.
Thats wrong.
C is compiled staticaly before the code runs. Most (not all) C compilers only look at the compilation unit and don't take stuff into account from other compilation units. A very simple situation where the C model fails is: compile a program to Pentium code and let it run on a Pentium 4. It does not "adapt" to the new processor as it is staticaly compiled. All static compileds languages fail there and all have the same fix: recompile. But still then the limited scope of only one compilation unit stays.
Java looks at Jit time on the whole area of interest. And that includes method calls spanning several compialtion units. C in general does not do that. So C in general is not upper bound the limit of what Java can do.
As I mentioned before
There are hundrets of probelms you can't even express in C but only model around by using libraries (like synchronization). How you can think that C is always on the same speed if not faster if it goes into optimizing stuff you can't even describe is beyond my imagination.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Java and Hotspots optimize on the fly. C coders optimize better through runtime analysis and knowing meta-information about the code that a compiler can never hope to know.
L ive/2005/jl0315.html
What do you think hotspot does??? It does runtime analysis. You can even set the compile threshhold...i.e. execute 1000 times before compilation, or wait longer for a better compile.
See this:
".... Also, profile data is collected by the interpreter for guiding the optimizations."
here:
http://java.sun.com/developer/community/chat/Java
So it DOES do runtime analysis optimization. C code can only be optimized for certain scenarios, whereas hotspot adapts and will de-compile and re-compile as the state of the program changes.
In fact there are two articles on DeveloperWorks that I wrote last fall that describe how to use AspectJ to do more advanced performance monitoring (that are cited in the original article). See http://www-128.ibm.com/developerworks/java/library /j-aopwork10/ and http://www-128.ibm.com/developerworks/java/library /j-aopwork12/
The big benefits of using AspectJ are the ability to build more interesting coherent logic with a higher level language rather than (virtual) assembly language, and to have a well-document, accessible extension language for custom monitors.
Ron Bodkin
Sorry, I have to admit I missed that little word uper bound. In fact it is not nice of you to make a conversation over 3 posts and finally hit me with that into my face.
It's not nice of me to make you miss a word I clearly posted and used? You need to wear more tinfoil on your head so my mind control rays affect you less.
A very simple situation where the C model fails is: compile a program to Pentium code and let it run on a Pentium 4.
Yes - and that is the case that most Java nuts use to "prove" Java is faster than C. However, it's not the case I was arguing. My point is that if you know your target platform then C will be faster or at least as fast as Java because you can compile it to that specific platform.
In the absolute worst case, the argument falls back to the fact the entire JVM is written in C, so I can happily make the argument that C is provably as fast as Java in every situation simply because Java is really executing C code anyway. Yes - it's cheating but it just shows the futility of the Java argument.
C/C++ optimization is not "cool" in the academic community but it's very much alive and still very much an area that companies spend billions of dollars on. A CPU lives and dies by the efficiency of its C compiler. The same cannot be said for JVMs.
You can express every problem in C that you can express in Java. Excluding C libraries is just stupidity, unless you want to exclude java.lang, java.util and all the other stuff from Java as well, which makes the entire language useless.
So, no. Unless you change the bounds of the argument, fully optimized C will always present the upper bound of performance for fully optimized Java when you know the target platform. To suggest anything else is simple ignorance of how computers work.
Fear: When you see B8 00 4C CD 21 and know what it means
A hotspot compiler optimizes for situations the hotspot compiler can detect and adapt to.
A human optimizing C code can optimize for all those situations and more.
C optimization is therefore a superset of Java optimization. Whine about it all you like, but that's the fundamental truth.
Thanks for playing, you lose.
Fear: When you see B8 00 4C CD 21 and know what it means
So, no. Unless you change the bounds of the argument, fully optimized C will always present the upper bound of performance for fully optimized Java when you know the target platform. To suggest anything else is simple ignorance of how computers work.
No you can't.
You accuse me to overlook a word you used only once
C compilers work on one compilation unit only, and optimize that oen only.
Jit compiler span multiple compilation units and optimize on that. So Jit compilers for Self and Java and similar languages create faster code than C, and this is true for over 15 years, when the first Self Jits where build and the runtime adaption research started.
Compiled C is not "the upper bound" for speed in relation to other technologies. And as I emtioned there is lots of stuff you can't express in C. Parallel execution, thread synchronization etc. can't be expressed on language level so a compiler can't take any advantages
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.