[java] Double compared to fixed point.

Started by
6 comments, last by Boomah 22 years ago
Hi, at the moment I am trying to optimise my java code and have been succesful using bitwise operators and shifts. However, I have a question concerning double numbers. At the moment I use doubles to keep track of position, velocity etc. of some of my objects. Would it be quicker using fixedpoint numbers. I know it should be but I want to know if there will be a big difference in java given that computers are so fast these days and have maths coprocessers. I don't really want to figure out how to implement fixedpoint numbers only to find that it makes my program slower! Also, I have my screen array that is 147456 elements long. When I plot a pixel I have to check to see whether it is in this array. I do this using the following: if ((x<384)&&(y<384)&&(x>-1)&&(y>-1)) {pixel[(y<<8)+(y<<7)+x] = colour} Is this the quickest way to do it or should I just use a try/catch thingy to catch the out of bounds error. Please help Thanks Boomah Edited by - boomah on March 18, 2002 12:06:27 PM
Advertisement
i''ll just comment about the exception stuff.

they are NOT intended to use when one is lazy, just to catch unpredictable faults and generates a lot of hidden stuff -> try/catch is slow. so i suggest you not to use them if you can simply check if an int is > array.length;

hope that made sense

_______________________
http://mill.3dfxsweden.net
_______________________ http://mill.3dfxsweden.net
I''d like to clarify a bit the mill-o''s comments. Using try-catch might be faster in some cases. You see if you wrap the operation you need to test inside try-catch, that in itself doesn''t make it any slower than any normal code. But if the expection is triggered, you''ll suffer quite a big penalty due to the Exception object being created, filled with current stack trace etc.

So if the operation in question would fail only say once out of million the try-catch approach would propably be faster than the if clause as it would execute 999''999 times without the added overhead of the if.

But if the operation in question will fail most of the time, it''s better stick to good old if statement.

Last I''d like to say the "three golden rules" of optimization:
1. Don''t optimize.
2. Don''t optimize.
3. Think about the consequences: added work, code becomes unreadable and the optimization might not work on all JVM''s. And don''t optimize
-Pasi Keranen
Thanks javanerd

that is what I was after. It makes perfect sense once someone has explained it to you. However, I MUST optimise ;-> (my stuff will only really get run on windows so it isn''t a massive problem)

I was wondering, does anyone know of a website out there that discusses optimising java for windows. For example, something simple like:

Which is quicker:

(int)Math.round(x) or
(int)(x+0.5)

I don''t want an answer for that, it was just an example but I hope you get what I mean.

Thanks, Boomah
quote:Original post by javanerd
But if the expection is triggered, you''ll suffer quite a big penalty due to the Exception object being created, filled with current stack trace etc.


well, that was what i meant, but thanks for making it a bit clearer to him.

_______________________
http://mill.3dfxsweden.net
_______________________ http://mill.3dfxsweden.net
quote:Original post by Boomah
I was wondering, does anyone know of a website out there that discusses optimising java for windows. For example, something simple like:

Which is quicker:

(int)Math.round(x) or
(int)(x+0.5)

I don''t want an answer for that, it was just an example but I hope you get what I mean.

That sounds like the answer to that question wouldn''t necessarily be platform-specific, but instead JVM-specific, processor-specific and implementation-specific (what JDK you''re using). I''m sure there are some things that can be optimized -for- windows, but then there are also those other factors that you should be thinking about. Optimizing java in general can be pretty tough -- I''ll get back to you if I find any good sites dealing specifically on that.

-pirate_dau
Here''s some links:

http://www.javaperformancetuning.com/
http://www.optimizeit.com/support/javaresources.html

There are dozens of other sites out there.

Personally, I don''t like a lot of the things optimization gurus force you to do. For instance, they will tell you not to use interfaces and to stick to static final methods. Well, most good designs involve interfaces and abstract classes. Why the heck do I want to ruin a good, reusable design because I can go from 750ms to 250ms? Are we that obsessed with speed? Are the video-card benchmarking kiddies deciding what java programs should look like?

I take the performance tuning stuff with a grain of salt. I am not going to spend my entire day making changes to my code that make it less readable, only to find out in two years that the computers are so fast that it doesn''t even matter. Besides, with the compilers that are out now, I think this is becoming moot. Much of the code you write will be rewritten in assembly by the new JVMs at run-time. And much of the time, they''ll write it better than you would.

Design so you can maintain the code. Don''t design for milliseconds. Because believe me, you won''t have any idea why you had a static final method that used two simultaneous threads operating simultaenously on the same ArrayList six months from now. Just write it the way it makes sense.

And, if necessary, optimize the 10% of the code where there is the most hold up.

Michael

Depends on the platform, but float (not double, but float) math is about as fast as integer math on most pc''s, so fixed point will not get you a big speed boost. Second, you use exception handling to handle EXCEPTIONAL circumstances, like file not found or out of disk space, not to do routine testing that is part of normal execution like clipping on pixels. Third, you don''t ever want to do clipping on a per pixel basis. What are you drawing? Can''t you clip the whole line, bitmap, or whatever?

This topic is closed to new replies.

Advertisement