|
Joe Pluta wrote: >If I'm wrong, please show me some numbers! It is particularly hard to compare Java and RPG at a load-add-store level. I don't have good stuff on my own. However, I know a lot about basic compiler technology and I base my claims on RPG versus Java based on what I know about compilation in general and also some specific work I've done with Java versus C. I do have some code that is largely procedural that enables me to track the basic codegen of Java versus C. Its main defect is that it minimizes the O-O procedure call penalty and the garbage collection penalty, but for the load-add-store part, proper, it is a good predictor. And, I certainly see many applications where these penalties are minimized. In JIT, for instance, the polymorphism penalty can actually be less than in direct execution, because it can sometimes pretend methods are final based on the dynamic situation of what classes have actually been loaded. It can then "inline" the code (ie treat the next method call as an old-style assembler code macro and make a extra, local copy of the code, elimiating the call overhead). So, the "big penalty" for O-O can sometimes be minimized, just as it can in C++ with inlining (inlining came in in a big way with C++, though C sometimes does it, too). The JIT has to work harder than a compiler at it, but this part continues to improve and conventional compilers are correspondingly more mature and improve at a slower rate. Direct execution can play most of these games and has the leisure to optimize things that even a two pass JIT won't do. I have seen the ordinary load-add-store difference steadily narrow in any event. Unfortuantely, I can't publish numbers, except in a general way, due to licensing restrictions from the benchmark vendor from whom I obtained the code. At COMMON, I put up some underlabelled charts when I talk about this, but in the end, it unfortunately boils down to "trust me" because I can't get specific or even point you at the source I use. It's a lawyer thing. In principle, however, if you knew where to look, you could prove this for yourself without a great deal of work. I have generally found, in my work with customers that most performance problems do not relate to Java proper, but rather to something relating to how OS/400 is invoked or how the Java class library or third party application library is invoked. Fix that and no one seems to care much about the codegen. Larry W. Loen - Senior Java and AS/400 Performance Analyst Dept HP4, Rochester MN +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.