Java 3D-engine

[Bohdy]

Does anyone here have any experience with Eiffel?

They made me learn the finer points of OO with it, but I haven't had any serious experience. I liked it because it "melted" its high-level code down to C before compilation with a standard compiler, so it was pretty fast. Design by contract was used extensively in it also.

 

[hkultala]

Actually many JVM's nowadays do not do JIT but "DAC", "dynamic adaptive compilation". They start by interpreting every method, but do profiling, and compile the methods that take most time.

the idea bases on the fact that 10% of code seems to take 90% of the time.

compared to JIT this has the following advantages
1) functions that are called just once are not compiled, only interpreted, which is faster for them.
2) memory is saved ( as naive code consumes more space than bytecode, and less is compiled)

btw. modern mobile phones have enough performance on their java for quite nice things. I coded a real-time Mandelbrot + Julia zoomer for MIDP2 and it could run acceptably on some phones.

(I had to use MIDP2, MIDP1 is not enough as MIDP1 does not have a bitblit function and pixel-per-pixel-rendering is too slow, and MIDP2 has a nice bitblit function)

 

[_xxx_]

I'm not that familiar with Java, but wouldn't JIT still mean you'll be waitnig half an hour for the game to load, since compiling is being done on startup? The same for whatever's being dynamically loaded at any time? Just curious.

 

[Scali]

I'm not that familiar with Java, but wouldn't JIT still mean you'll be waitnig half an hour for the game to load, since compiling is being done on startup? The same for whatever's being dynamically loaded at any time? Just curious.

Not really. You can't compare JIT-compiling in Java to native compiling, since you don't work from ASCII sourcecode but from bytecode.
A lot of the hard work is already done. It is stored in compact bytecode rather than large ASCII files, and there's no need to parse a lot of huge header files and such.
What you have is simply a preparsed, machine-independent version of the sourcecode, with high-level optimizations already applied.
Going from this bytecode to native code is quite a fast process compared to native compiling. Ofcourse it could still take some time on large pieces of code, but you'd have to have a LOT of code to get it compiling for over a minute on a modern machine.

 

[_xxx_]

I get it. One more q: where's the actual benifit of a Java 3D-Engine besides being cross-platform?

 

[Scali]

I get it. One more q: where's the actual benifit of a Java 3D-Engine besides being cross-platform?

Mostly that Java is a simple, clean and comfortable language to develop in, I suppose.
Which could mean that development takes less time, and time is money

 

[DemoCoder]

Just wait, one day, Haskell compilers will be able to generate code at close to C performance.

 

[Humus]

Whenever that happens, I'll release my first demo written in Haskell. 8)

 

[Saem]

(I'm not trying to be snobbish here,I love high level languages, but I believe you also have to learn the low level stuff too so that you can understand what's happening in the high end system "behind your back")

I understand the point you're making. Though, I think jumping from learning about algorithms and data structures to low-level stuffs is flawed. I know folks who learn algorithms in rather high level languages, not VB, mind you.

My point is that your line of reasoning could be shown to be true, but in fact, would be a correlation than anything causal.

 

[Ragemare]

Only vaguely releated to the conversation but I'll post it anyway.

http://www.mojomonkeycoding.com

A nice scene graph API written in Java, some people have done interesting things in it.

 

[ERP]

(I'm not trying to be snobbish here,I love high level languages, but I believe you also have to learn the low level stuff too so that you can understand what's happening in the high end system "behind your back")

I understand the point you're making. Though, I think jumping from learning about algorithms and data structures to low-level stuffs is flawed. I know folks who learn algorithms in rather high level languages, not VB, mind you.

My point is that your line of reasoning could be shown to be true, but in fact, would be a correlation than anything causal.

Adding to this, IME the best C++ programmers I work with are old school assembler programmers.

The low level knowledege is invaluable, understanding why something is expensive or why something else should be avoided is a great help.

A lot of what I percieve as better quality it has to do with code structure though. Writing large scale apps in assembler requires planning and organisation (or it's unmanageable), where you can just hack things togther in high level languages doing the same thing in assembler is a recipe for disaster. People who've been through this in assembler apps tend to produce better organised code.

That's not to say that you can't learn to be a good programmer in high level languages. You certainly can, but having both the high and low level viewpoints is a real benefit.

I occasionally give presentations to programmers on staff about producing good code and a lot of that talk is about why you should avoid cetain language features in certain situations. It's about understanding what they do and why that can sometimes be bad.

 

[DemoCoder]

One can learn algorithms and datastructures in high level languages, but that does not teach one to respect how these algorithms run on the underlying machine model.

Sure, I can express quicksort in 3 lines of Haskell, but it runs horribly slow compared to the in-place C version. I can learn Fibonacci Heaps and their asymptotic running time looks sweet, but for most data sizes and uses, they are too slow. I could use fast fourier transform to do large integer multplication in O(n lg n) time, but will I ever encounter such large integers? Data structures can be studied via high level languages, but the abstract model they present fails to prepare one for the realities of performance, where the "constant" of the Big-O() actually has a huge effect on your performance, and a bad mismatch with your underlying hardware could yield pathological performance problems.

If you only expose yourself to high level languages, you will never have an appreciate for how things like memory layout and cache affect your performance, or how to pipeline operations together to maximize CPU utilization.

I say this as a person with deep love of high level languages. I love Perl, Python, Haskell, OCaml, Java, C# and the like, for the huge productivity boost they give one. But I do not think one's education in programming is complete unless one has had experience and exposure to both extremes.

 

[Saem]

If you only expose yourself to high level languages, you will never have an appreciate for how things like memory layout and cache affect your performance, or how to pipeline operations together to maximize CPU utilization.

I'll give you that.

Though I wonder, with the use of a profiler, n HLL and understanding of computer architecture could, data alignment and so on be taught?

-----

As an aside

I remember we had an assignment in an intro to data structures class where we had to do an insane amount of string generation and comparison in java or C++, student's choice. I knew object creation was expensive and so I used char arrays and extracted creation of objects out of my inner loop and simply used reinitialization when needed. It blew all the other implementations out of the water.