On Thu, Oct 30, 2008 at 08:30:02AM -0000, Stephen Rowles wrote: > > Things like the Hot Spot compiler in Java, which can re-optimise > > byte code as the program is running depending on how its actually > > being used can complicate things (ending up with Java performing > > better than C in *some* circumstances).
That will never happen. Java can approach C's performance in some circumstances, but Java /always/ carries an overhead. The JVM is simply not designed to match C's speed. For example, Java arrays are always bounds- checked. The hot-spot compiler is not a tool for doing extra super-duper optimisation of frequently used code but for saving time by avoiding optimisations on infrequently used code. You can assume that a C compiler always fully optimises everything. > That's one of the problems with performance optimisation. You cannot > optimise everything (for a large software project you never have time) so > you have to work on the areas you think are important / used the most. Of > course if you get the wrong areas, then it doesn't help ;). This is true but it's a completely different type of optimisation, one that cannot be done automatically. Compilers can fully perform instruction-level optimisation, but they won't rewrite an O(n²) algorithm to an O(n log n) algorithm, which is usually the kind of optimisation programmers usually look for when they are coding. The circumstances where Java will run faster than C are the latter type of operation: JFC gives programmers a far better library than the STL, meaning it's easier to write code with better asymptotic complexity in Java. Dan -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --------------------------------------------------------------
