Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  micro optimizations  (Read 8445 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #30 - Posted 2002-12-09 23:55:58 »

I'm sorry to pout cold water on your efforts, but for improving performance this is nearly all pointless (it's rather useful for other things, like certain one-off cases where the optimization wouldn''t be "safe" but you have some special knowledge, like perhaps knowing that the program always throws an exception at some point before hitting i=0, and can do something about it). This isn't an opinion, its fact, and it's all to do with compilers.

One of the major reasons for using a compiled language is so that the compiler will do precisely the kind of trick you suggest here for you, and you can carry on writing in high-level code. In the bad old days when compilers still sucked (performance wise) it was worth doing such low-level optimizations, trading on the fact that a really good human programmer was better at optimization than a typical compiler.

Nowadays, you will find in general that such optimizations have more of a negative effect (when you try them across all main platforms) than a positive one - this is because you are not only second-guessing the compiler, and assuming that it wouldn't have made the same optimization itself, but you are reducing the number of additional optimizations it could have been doing, but which are way too clever for you to ever understand (unless you are a first-rate maths PhD or above).

With java especially, its not even possible to make statements like "this is one less instruction". You can make that kind of statement with C family languages, where you have a much better knowledge of what's going to happen to your code before it gets executed (compiled straight to assembler, for instance). The fundamental way that a Java VM works is to compile java byte code into code optimized for the machine its running on. As someone suggested (I can't remember if this is correct, but it sounds pretty likely given the 486 arch), this "optimization" might work best on a 386/486 class processor. But it would work slower than the "unoptimized" version on e.g. any processor family that has instructions for doing for loops with increasing loop-variables. (the java VM for that machine would have auto-recompiled the byte code to use the native CPU instruction, but now it can't).

It's better in general (unless you have a poor compiler) not to try this kind of clever optimization. When you factor in the additional loss to the programmer of the code now being less clear (unless you are willing to put 3 lines of comments explaining the bizarre implementation in front of each and every for loop!), the weight of evidence is in favour of avoiding this.

Even things like the good idea to reduce the number of times the "length" of an array is referenced are actually a complete waste of time. Every compiler today uses "live variable analysis" and "reachability" (feel free to google for them - should be slides on them in any really good Computer Science undergrad course) to automatically remove every single unecessary calculation. Although sometimes (as part of other optimizations) it can actually be better performance to deliberately compute something twice (and thats the kind of complex decision that the compiler will make for you - if you only give it the chance!).

Finally, its worth remembering that something which is well-suited to java byte code is often slower on most real machines than something that isn't. Java byte code was deliberately designed to be a really rubbish processor architecture for one of two reasons (depending on who you talk to in Sun):

1. They wanted it to be extremely easy to create a "hardware Java chip" that could execute java byte code. MAJC (the java chip) was much cheaper and easier for them to design and manufacture using 15-yr old techniques in processor design.

2. Java 1.0 came out when machines were a heck of a lot slower than today (I still have somewhere a copy of a Java VM for DOS!). Making java byte code a shitty inefficient architecture made it very easy for lots of different manufacturers and developers to write the first VM for each of the different platforms. Sun were rather worried that they might not achieve the critical mass of Java VM's for enough platforms (and it took quite a few years to happen, even with the very easy to implement java 1.0 VM's).

malloc will be first against the wall when the revolution comes...
Offline pepe

Junior Member




Nothing unreal exists


« Reply #31 - Posted 2002-12-10 02:02:57 »

Quote
I'm sorry to pout cold water on your efforts, but for improving performance this is nearly all pointless

Yes, that's what  came out after the first bench in the beginning of the thread.  Nevertheless, some things came out of the tests, and while pointless, it was useful. At least, i think so.

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #32 - Posted 2002-12-13 16:29:54 »

Quote
Even things like the good idea to reduce the number of times the "length" of an array is referenced are actually a complete waste of time. Every compiler today uses "live variable analysis" and "reachability" (feel free to google for them - should be slides on them in any really good Computer Science undergrad course) to automatically remove every single unecessary calculation.


For array.length this is true.. but for String.length(), where you have a method invocation that possibly has side effects, it is likely a different story.

I agree in principal that optimizations should be left to the compiler, particularily for Java where the 'final' compiler is often not under your control.  But there are still some low-level optimizations that are still useful.

Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (12 views)
2014-08-28 18:26:30

CopyableCougar4 (24 views)
2014-08-22 19:31:30

atombrot (37 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (29 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (28 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (33 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!