 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2008How much efficient is Java 6 to Java 1.3?
I have an Applet designed using Java1.3 Since the people browsing the applets are using Java 6 / 7 (Latest version) They already getting advantage of higher version. Should I compile the code with Java 6 to get higher performance? Will that speed up the Applet processing? That applet was compiled using Java 1.3, Will recompiling speed up the applet. Will I be seeing a 100 %/ 200 % Jump in Applet speed? Bye Sanny Java Experts Needed: http://www.getclub.com/Experts.php > I have an Applet designed using Java1.3 > > Since the people browsing the applets are using Java 6 / 7 (Latest > version) They already getting advantage of higher version. The latest full release version is Java 6; Java 7 is (last I checked) still in alpha builds. > Should I compile the code with Java 6 to get higher performance? Will > that speed up the Applet processing? Do you have the source code? If not, you probably can't legally decompile it and then recompile to Java 6; in any case, decompilers still need some tweaking of the outputs to compile correctly. That said, you will not get any speed increase by recompiling the code with a newer compiler. Unlike software compiled to native code, Java's optimization comes at runtime. Even code written in Java 1.0 will have the same optimizations applied as code in Java 6. However, it may be possible that the applet is using antiquated, slow libraries (e.g., Vector instead of LinkedList or ArrayList). Any further speed enhancements you could get would require you to rewrite the code to use this newer stuff.  SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > That said, you will not get any speed increase by recompiling the code > with a newer compiler. Unlike software compiled to native code, Java's > optimization comes at runtime. Even code written in Java 1.0 will have > the same optimizations applied as code in Java 6. Yes, optimization is done at runtime, but newer compiler may generate different code. And it does. For example addition of strings in 1.3 uses StringBuffer, but in 6.0 StringBuilder that is supposed to be faster. >> That said, you will not get any speed increase by recompiling the code >> with a newer compiler. Unlike software compiled to native code, Java's [quoted text clipped - 5 lines] > uses StringBuffer, but in 6.0 StringBuilder that is supposed to be > faster. Joshua Cranmer's point would apply here, then - in order to get the benefit of StringBuilder you'd have to rewrite the class that uses StringBuffer. StringBuffer is only slower because its methods are synchronized. The overhead of synchronization is much less than it used to be, especially if you are using StringBuffer in only a single thread. The speed difference might not be sufficient to justify rewriting the code, given that other areas of the project almost certainly would require attention much more urgently. SignatureLew > Joshua Cranmer's point would apply here, then - in order to get the benefit of > StringBuilder you'd have to rewrite the class that uses StringBuffer. No. The same sorce code will generate different bytecode. For example: public class A { String s(String s1, String s2) { return s1 + s2; } } Comiled with 1.6: 0: new <java.lang.StringBuilder> (2) 3: dup 4: invokespecial java.lang.StringBuilder.<init> ()V (3) 7: aload_1 8: invokevirtual java.lang.StringBuilder.append (Ljava/lang/ String;)Ljava/lang/StringBuilder; (4) 11: aload_2 12: invokevirtual java.lang.StringBuilder.append (Ljava/lang/ String;)Ljava/lang/StringBuilder; (4) 15: invokevirtual java.lang.StringBuilder.toString ()Ljava/lang/ String; (5) 18: areturn And compiled with 1.3: 0: new <java.lang.StringBuffer> (2) 3: dup 4: invokespecial java.lang.StringBuffer.<init> ()V (3) 7: aload_1 8: invokevirtual java.lang.StringBuffer.append (Ljava/lang/ String;)Ljava/lang/StringBuffer; (4) 11: aload_2 12: invokevirtual java.lang.StringBuffer.append (Ljava/lang/ String;)Ljava/lang/StringBuffer; (4) 15: invokevirtual java.lang.StringBuffer.toString ()Ljava/lang/ String; (5) 18: areturn >> Joshua Cranmer's point would apply here, then - in order to get the benefit of >> StringBuilder you'd have to rewrite the class that uses StringBuffer. [quoted text clipped - 6 lines] > } > } The code doesn't explicitly use either StringBuilder *or* StringBuffer, it uses 'String'. Other JVMs might not do that the same way. I was referring to the case where the programmer selected StringBuffer, not where the programmer selected String. I make no claims about what happens when you only use String operations. You shifted ground when you went from discussion of the use of StringBuffer/StringBuilder to discussion of the use of String. Apples and oranges. Not fair. SignatureLew > The code doesn't explicitly use either StringBuilder *or* StringBuffer, it > uses 'String'. Other JVMs might not do that the same way. That's exactly my point. Recompilation may generate different code, which can be faster. Differences may or may not be measurable (actually I agree that probably won't be), but if speed is really important and applet does a lot of calculations there's no reason not to recompile and benchmark. >The code doesn't explicitly use either StringBuilder *or* StringBuffer, it >uses 'String'. Other JVMs might not do that the same way. Javac.exe is the one which makes the decision how the + concatenation operator is handled. So it would help to recompile with JDK 1.6 and target -1.6. Of course it won't change any EXPLICIT use of StringBuffer to StringBuilder. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> Joshua Cranmer's point would apply here, then - in order to get the benefit of >> StringBuilder you'd have to rewrite the class that uses StringBuffer. [quoted text clipped - 36 lines] > String; (5) > 18: areturn They more or less had to switch. They put the following in the docs for StringBuffer: "The StringBuilder class should generally be used in preference to this one," And if they have to eat their own dog food then ... And it is slightly faste. But we are down in the nanoseconds magnitude. Arne >And it is slightly faste. But we are down in the nanoseconds magnitude. StringBuilder was much faster than StringBuffer, then Sun improved the code for locking so the gain was reduced. Ditto for Vector and ArrayList. As optimisers get more and more clever it gets less an less important precisely how you specify your algorithm. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > As optimisers get more and more clever it gets less an less important > precisely how you specify your algorithm. I wonder, if optimizers are or will (ever) be able to optimize even this particular anti-pattern: String s=""; for(<whateveloop>) { s+= <something> ; <...> } such that only one StringBuilder is used, rather than one for each iteration.(*) Theoretically, it doesn't seem entirely infeasible to me. For readers of a certain other current (sub-)thread: (*) This would be one case, where re-using the StringBuilder would be much more efficient after all, because it's state at the end of each iteration is exactly what it would be initialized to for the next one. The "t4(re-init)" would be 0 here, quite unlike the t4(init to "s"'s content). > I wonder, if optimizers are or will (ever) be able to optimize > even this particular anti-pattern: [quoted text clipped - 8 lines] > > Theoretically, it doesn't seem entirely infeasible to me. Unless there is something in the JLS or VM Spec that prohibits this type of optimization, then it should indeed be possible. Arne On 12 Apr 2008 22:22:35 GMT, Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted someone who said : >I wonder, if optimizers are or will (ever) be able to optimize >even this particular anti-pattern: see http://mindprod.com/project/stringbuilderoptimiser.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com ><avl@gamma.logic.tuwien.ac.at> wrote: >>I wonder, if optimizers are or will (ever) be able to optimize >>even this particular anti-pattern: > see http://mindprod.com/project/stringbuilderoptimiser.html "Estimated Existing Implementations": 0 :-( PS: That reminds me of another of your project-suggestions, namely http://mindprod.com/project/interfacefinder.html Some time ago, I asked you to change the text from "Split it at the semicolons" to "Split it at occurrances of File.pathSeparator" But you didn't show any reaction at all, not even one like "I'm a Windows guy, and don't care about teaching portability", so I'm not sure you even read my previous bug-reports. I hope, you see it this time. Roedy Green wrote: >> see http://mindprod.com/project/stringbuilderoptimiser.html from which: > Convert sb.append ( " " ) to sb.append ( ' ' ); This might not be much of an optimization. The String " " is literal, and therefore will be obtained directly from the intern pool. HotSpot will see an indirect reference to the same location in the JVM for the argument of each 'append(" ")'. That's only one hop longer than a direct load of the character. Part of the student project (excellent service to the community to post those projects, btw) should be to benchmark the difference between the String- and character-argument calls before implementing the optimization, and to compare any change in the String-argument call times to that difference as well. Just to invent fictional numbers by way of example, let's say the String benchmark time is two granoseconds ("grano-" being the prefix for whatever is the appropriate granularity of measurement), and the character time is one granosec. One would hope that the optimized String call would come down from 2 granosec to something close to one. Also, if you happen to test on a JVM whose authors have already optimized the String call, you might find that the "before" difference is surprisingly small. Maybe the difference without your optimization is only 1.001 granosec for the String call vs. one for the character case, once HotSpot warms up. SignatureLew > That's only one hop longer than a direct load of the >character. Part of the student project (excellent service to the community to >post those projects, btw) should be to benchmark the difference between the >String- and character-argument calls before implementing the optimization, and >to compare any change in the String-argument call times to that difference as >well. When you are writing general purpose optimisers you go for broke. You shave every nanosecond you can. It may matter to someone, even if just an artificial benchmark against the competition. For a given application, of course, you measure and don't bother with negligible optimisations. To an assembler programmer such as myself append(' ') is obviously vastly faster than append (" "). Because it is a trivial optimisation, so you might as well do it. append( ' ' ) might be optimised roughly like this: if ( ++bufflen >= bufflimt ) { handleOverflow() }; buff[ bufflen ] = ' '; append( " ") will be roughly implemented like this: int end = bufflen + literalxxx.length(); if (end >= bufflimt ) { handleOverflow() }; for ( int i = 0; i< literalxxx.length(); i++ ) { buff[ bufflen + i ] = literalxxx[ i ]; } bufflen = end; SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On 13 Apr 2008 09:47:54 GMT, Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted someone who said : >But you didn't show any reaction at all, not even one like "I'm a >Windows guy, and don't care about teaching portability", so I'm not >sure you even read my previous bug-reports. I I don't read all the messages in the newsgroups, and even the ones I do read I mostly skim, so it won't necessarily register you are asking for a change to the text on one of my web pages. If you want to make sure I notice, email me. see http://mindprod.com/contact/contact.html Subject: Error on http://mindprod.com/project/interfacefinder.html will help me notice even if the spam filter misfiles. I tried several times to get Linux to co-exist with Windows , but all it does it trash my partition tables requiring a from scratch reinstall of everything. That is inexcusable. I want Windows to fade into the sunset, but if Linunoids are going to make installs so difficult, that can't happen. The initial install has to be idiot-proof. Those essays at http://mindprod.com/project/projects.html are just project suggestions, to give you then general idea of what you might do for a project, not specifications. Your beef should primarily be with someone who implemented them in an unnecessarily platform-specific way. Any any rate, your correction will be in there within the hour. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >>But you didn't show any reaction at all, ... > I don't read all the messages in the newsgroups, and even the ones I > do read I mostly skim, so it won't necessarily register you are asking > for a change to the text on one of my web pages. If you want to make > sure I notice, email me. see http://mindprod.com/contact/contact.html > Subject: Error on http://mindprod.com/project/interfacefinder.html I did email you, but quite likely with a different one than what you suggested here. > will help me notice even if the spam filter misfiles. That might have happened. > I tried several times to get Linux to co-exist with Windows, This is of course not a forum to discuss windows+linux co-installation, and I'm not even able to help much anyway, since my machines are linux only since roughly a decade. I casually read remarks by others who complained that the installation procedures that worked with some version of windows suddenly stopped working with some newer version of windows, so this gives me some idea of the culprit. > Those essays at http://mindprod.com/project/projects.html are just > project suggestions, to give you then general idea of what you might > do for a project, not specifications. Your beef should primarily be > with someone who implemented them in an unnecessarily > platform-specific way. Generally, you're right, unless the platform-lock is already (inadvertedly) suggested in the outset. > Any any rate, your correction will be in there within the hour. It's better now, but I think it would be best to principially suggest File.pathSeperator, pointing out that this way should be the preferred one over any hardcoding of platform-specific values. As it is now, it sounds like: only if you're really really sure that you need it to run on more platforms, use the pathSeparator... Your students'-projects surely have some teaching effect from their very outset, so let's not teach the wrong message. On 14 Apr 2008 08:52:29 GMT, Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted someone who said : > File.pathSeperator your mean: File.pathSeparator That is probably the #1 spelling programmer spelling error. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> File.pathSeperator > your mean: > File.pathSeparator Correct one speling mistake, make a grammatically one instead :-) But I'm a bit disappointed, that teaching platform neutral idioms is obviously not one of the goals of the student projects. It still mentions two specific platform solutions before the general one - at least still better than what it was before. On 14 Apr 2008 08:52:29 GMT, Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted someone who said : >Your students'-projects surely have some teaching effect from >their very outset, so let's not teach the wrong message. Good point. Since multi-platform comes out in the wash so easily in Java if you follow some reasonable precautions I tend to forget about being explicit about it. Personally, I like extremely concrete examples when I am learning or trying to understand something difficult. Any generality or abstraction just ties up some neurons and gets in the way. I think I am the reverse of my university math profs who liked high abstraction as a way of clearing away anything extraneous to the logic. (They were repelled by my requests for examples of non-arithmetic groups/rings/vector spaces etc used in the real world. To them it was would be like collecting bric-a-brac.) On the other hand I have little trouble writing code that generalises from a few very specific concrete examples. However, on general principles, I should work to reduce the Windows-centricity of the mindprod.com website, especially given the very low opinion I have of that OS. So please keep up the reports of excessive Windows-centricity and I will gradually weed them out. Further anyone who can get Boot-it NG, Vista and Ubuntu to co-exist please tell me the secret incantation. I'm willing to give it yet another shot. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> And it is slightly faste. But we are down in the nanoseconds magnitude. > > StringBuilder was much faster than StringBuffer, then Sun improved the > code for locking so the gain was reduced. Ditto for Vector and > ArrayList. StringBuilder was introduced in 1.5 - I think most of the improvements in synchronization had already been done. ArrayList was introduced in 1.2 and that was an entire different matter. If I were to guess then it was at least as important to avoid the frequent mistakes caused by people who thought using a thread safe class would make their code thread safe than for the performance gain. But it is pure speculation. Arne >> And it is slightly faste. But we are down in the nanoseconds magnitude. > > StringBuilder was much faster than StringBuffer, then Sun improved the > code for locking so the gain was reduced. Ditto for Vector and > ArrayList. However, the reasons to use ArrayList in preference to Vector are not related to performance. SignatureLew >However, the reasons to use ArrayList in preference to Vector are not related >to performance. What are they? SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> However, the reasons to use ArrayList in preference to Vector are not related >> to performance. > > What are they? To me, one reason is Occam's Razor, loosely speaking. Vector is retrofitted to the collections class, and contains methods and uses helper types not supported in the rest of collections. I prefer to use a type that lacks the redundancies. This gives better control over the code, and increases the likelihood that the code will play nicely with maintenance, enhancement and refactoring down the road. Another factor is that Vector is implicitly synchronized. Uses that synchronize ArrayList (or other List types) are explicitly synchronized, increasing the degree to which the source code documents itself. Some people use Vector without knowing that it synchronizes all its methods. ArrayList more openly supports a good impedance match between what you see in the source and the semantics of the resulting program. Likewise, I prefer to declare variables that point to Lists as Lists rather than as a specific subtype. Of course there are times when you must specify a narrower variable type, but one should use the widest type appropriate to the algorithmic purpose of the variable. The intuitive summary of this is that ArrayList and the other "true" List implementations are more elegantly expressive concrete types than Vector for most use cases. SignatureLew >To me, one reason is Occam's Razor, loosely speaking. I have added this to the entry on "ArrayList" at http://mindprod.com/jgloss/arraylist.html to summarise your objections to Vector. "Don't use Vector in new code. It has confusing redundant methods, and the synchronisation is excessive and implicit." SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > I have added this to the entry on "ArrayList" at > http://mindprod.com/jgloss/arraylist.html to summarise your objections > to Vector. > > "Don't use Vector in new code. It has confusing redundant methods, > and the synchronisation is excessive and implicit." You have a gift for putting things clearly and succinctly. SignatureLew >> That said, you will not get any speed increase by recompiling the code >> with a newer compiler. Unlike software compiled to native code, Java's [quoted text clipped - 5 lines] > uses StringBuffer, but in 6.0 StringBuilder that is supposed to be > faster. I doubt that effect will be measurable. Arne > I have an Applet designed using Java1.3 > [quoted text clipped - 6 lines] > That applet was compiled using Java 1.3, Will recompiling speed up the > applet. Will I be seeing a 100 %/ 200 % Jump in Applet speed? You will see approx. 0% jump, because it is the JVM not the compiler that does the optimization. The 1.6.0 JVM are much faster than the 1.3.1 JVM - a 100% jump for number crunching type of app is not unrealistic. But speed of an applet would probably depend more on the native calls made for GUI than on the JIT compilers optimization. I believe that the GUI stuff has also been improved from 1.3.1 to 1.6.0, but I do not have any numbers. And I would expect that part to be very platform specific as well. The JIT compiler be about identical on Windows and Linux/x86, but thenative GUI calls will be very different. Arne Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.