Quote:Original post by meeshoo
so explain to me, please, how can an OOP code JIT compiler be faster than a C compiler.

It can be faster because a JIT compiler compiles native code specifically for the platform it's running on. Since C/C++ is precompiled, programs need to be compiled for the worst possible scenario (IE: I don't know what platform my customer will have, so I compile it using only Pentium instructions with no MMX or SSE instructions, that way I can be sure it will run on most platforms - Pentium or later at least). Now, a user with a Pentium 4 MMX and SSE2 enabled processor buys my program. My program is going to waste a lot of cycles because it doesn't take advantage of that user's superior processor. Those cycles could be put to better use - producing higher resolution graphics or a nicer user interface.

This is why a JIT compiler can produce better code than a pre-compiler. The JIT compiler is running on the exact machine that the code will be executed on, so it can easily tell how broad of an instruction set it should use, literally producing code custom tailored for the user's system.

Assembler is 3-4 times faster than Java, so if Lua is x faster than Java, then it must be 5 times faster than an assembler,
heavily optimized assembler. It's quite interesting. I thing it would be called hearsay right?

Actually it's very easy to write compiler in an assembler. You just load an array with data, then iterate over it. Basically the same thing like you are doing when you are creating self modifying code in Java.

1.3 was released in 8 may 2000, its name was kestrel.
Current most stable VM is mantis, it was first released 26 June 2003. Current version of mantis is 1.4.2_5

Quote:Starting with Tiger, each version has two version numbers: an internal number, such as 1.5.0, and an external number, such as 5.0.

Don't cofuse version numbers.



So before we would continue in the troll contest, we should look at some real data.
For example my highly unorthodox and experimental arithmetic compressor with predication by partial matching has speeds between 450kB to 20kB. (Common speed of arithmetic compressors is around 2 kB on my computer.) It's actually the first arithmetic compressor I tested, that was able to compress movie close to one hour. It ran on 5.0 beta2 server

BTW before someone else would attempt "useless FPS contest" TM, some PS2 games run at a 30 FPS, so you should rather measure UPS, especially with Doom 3. ^-^

Quote:Original post by Strife

Quote:Original post by Anonymous Poster
but certain things are almost impossible to do, and you end up writing 500 lines 5 times were a mere 50 lines in the first place SHOULD have been enough, just once.

Huh? Could you provide an example?

Gross generalization rather than count the actual numbers of lines, but ... I encounter this regularly in function despatch and advanced OOP polymorphism (such as complex covariant types - or, more to the point, java's lack thereof).

Thank **** that java 5 has *finally* introduced some limited form of covariant types! Perhaps we can finally start writing really good OOP code on these libraries we have where a single user-class is formed from 6 or more base classes layered on top of each other from 3 independent libraries.

w.r.t. function despatch I've been doing some funky stuff that is under patent-application, but suffice it to say Java's fn-handling is as hard coded (and as expressively weak) as its type system. 99% of the time I don't care, until it comes to writing large / complex libraries - where it becomes a major pain and forces code duplication etc.

Still. I know it doesn't affect most people, ever (except perhaps indirectly - they use libraries which COULD have been easier to use but in java it was too much effort for the library coders so they didn't bother).

BTW a new demo-game to showcase what games devs are doing with java right now:

http://www.megacorpsonline.com/downloads/mco.jnlp

If you have java installed *properly* with file associations etc then that should be an auto-install-and-run link. However, I do know there are some bugs left (this is still a beta release IIRC) - enough that it's not been accepted onto javagamesfactory.org yet.

IIRC requires at least a GF3 or ATi equivalent...

redmilamber

C doesn't do inlining either. All function calls emit a jump, regardless of how small and simple they are. That's one reason C++ smacks C about when it comes to sorting (STL inlines stuff), and to a certain extent so does Java when the JVM performs inlining.

Quote:Original post by Anonymous Poster
BTW a new demo-game to showcase what games devs are doing with java right now:

http://www.megacorpsonline.com/downloads/mco.jnlp

If you have java installed *properly* with file associations etc then that should be an auto-install-and-run link. However, I do know there are some bugs left (this is still a beta release IIRC) - enough that it's not been accepted onto javagamesfactory.org yet.

IIRC requires at least a GF3 or ATi equivalent...

redmilamber

This game doesn't run on OS X :(.

Quote:Original post by Anonymous Poster

Quote:Original post by Anonymous Poster
- enough that it's not been accepted onto javagamesfactory.org yet.

This game doesn't run on OS X :(.

We will continue to nag them to fix that before we agree to put it up on JGF.

PS there are some games on JGF now that are known not to work on OS X - we're about to replace the entire site imminently and will clean them out then.

Nagging us won't help :) The resaon that Megacorps dosen't run on OSX yet is the lack of CG support in JOGL on OSX.

Cheers
Tomas
CTO Agency9

Java is Direct X compatible. Java is most certinally OpenGL compatible. Due to the extreme speed of processors and renderers, any lag that would've been caused a year ago are of no signifigance now.

The only biggest and probably most non-important part of the anti-java team should be the java runtime cost itself.

the java runtime is at a 30 MB MINIMUM on ram. (33 something is the actual number) Any other reason is completely perposterous.

So to cap it all down, the only real requirement that people have when running java is alot of ram.

Quote:Original post by Anonymous Poster
the java runtime is at a 30 MB MINIMUM on ram. (33 something is the actual number) Any other reason is completely perposterous.

Standard is 8Mb on my PC, and always has been.

But...do you know what you're looking at? java 5 (finally!) uses class data-sharing, so that JVM's share memory with each other, but lots of OS's are not clear about how much of a process's ram is shred and how much is exclusive