Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java becoming a non-deterministic runtime?  (Read 2687 times)
0 Members and 1 Guest are viewing this topic.
Offline genepi

Senior Newbie


« Posted 2004-02-27 13:49:30 »


I don't know if you feel like me, but I think that Sun is turning Java in a non-deterministic language. I'll try to explain...

I've been used to languages where one could say that a loop control structure is O(N). In ol' BASIC days,
FOR i = 1 TO N
took a time proportional to the value of N (at least when the code in the loop is constant and the compiler does not do too much agressive code removal). There are other parameters like the platform, but at least, you could do an algorithmic analysis and optimize your source code on the paper without event running it.

Now, with the Java runtime, the performance of some code depends on soo many runtime parameters:
- The JVM type (Sun, IBM, BEA...)
- The JVM compiler type: Hotspot -server or -client. Has the loop run enough to raise the hotspot compiler?
- The JVM parameters: -incgc and surch -X non-portable options.
- And of course platform: you don't write the same code for J2ME or J2SE. On J2ME, you MUST manage your objects allocations.

The programmer has less options to write optimized code and the performance depends on the runtime environment.
As a consequence, when you do a change in your code, you can't predict the impact it'll have on performance.
Remember when code was cluttered with object pools to compensate for the garbage collector poor performance?

Now, I fear to write clean code, with correct performance with today VM (and its tuned runtime parameters) and to discover in a few years that the code+tuning parameters are no more valid with current VM...  Nowadays, you take care not to create objects in a critical time loop, but how will run this code when JVM implement escape analysis or other techniques?
Offline Mark Thornton

Senior Devvie

« Reply #1 - Posted 2004-02-27 14:26:11 »

Nothing really new in this. The performance of malloc in C/C++ (and related methods) has often depended on external factors. The extent of this dependence use to change with each successive release of Microsoft's C compiler/libraries. It would become more or less tied to the performance of the platforms allocator (which was outside of your exe).
The problem isn't quite as bad as you suggest, because in most cases the performance simply improves with later versions. The only catch being that had you used simpler code (such as not moving allocations out of loops), it might have improved more.
If you restrict your more devious performance tricks to those small areas where it is really needed then you don't have to change too much code when the JVM improves.
Offline erikd

JGO Ninja

Medals: 16
Projects: 4
Exp: 14 years


« Reply #2 - Posted 2004-02-27 14:51:45 »

I can understand your fear/doubts, but as I see it is that it's not really a problem but merely a sign of improvement.
For example, my 1.1 MSVM targeted applets run as fast or faster on my current PC with current JVM than the target machine I had for those applets at the time. Even though some 1.1 typical functions perform a bit worse on todays JVM's and I used some typical 'old school' optimizing techniques that might affect performance negatively on today's JVMs, the PC's got faster to compensate.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder

Got any cats?

« Reply #3 - Posted 2004-02-28 03:56:08 »

Youve missed the point im afraid.

EVERY step we've taken with Java performance has been to imrpove the performance of exactly what you are talkign abotu writing: clear, clean, well encapsulated code.

Today Java can do so FAR better then C++ for instance where you sill have to sacrafice clarity and clean OOP in fvaor of the kind of hand-tuning you are talkign about.

So don't worry, be happy.  Write clear, clean well encapsulated code that makes it as clear as possible to the VM what your intentions are and you will get the best performance.

Its shift of mindset, but a good one!

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!
Pages: [1]
  ignore  |  Print  

EgonOlsen (42 views)
2018-06-10 19:43:48

EgonOlsen (22 views)
2018-06-10 19:43:44

EgonOlsen (43 views)
2018-06-10 19:43:20

DesertCoockie (197 views)
2018-05-13 18:23:11

nelsongames (124 views)
2018-04-24 18:15:36

nelsongames (123 views)
2018-04-24 18:14:32

ivj94 (863 views)
2018-03-24 14:47:39

ivj94 (125 views)
2018-03-24 14:46:31

ivj94 (768 views)
2018-03-24 14:43:53

Solater (140 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!