But these methods you compile to native code, these still need to be called regulary through JNI at some point during execution… Fx when working with vectors this tends to be scattered all through the source… Could you explain why there wouldn’t be many JNI calls that way?
I think this is an unrealistic expectation.
The moment there is 1 method-call or object-field reference within the bytecode, which (return)value can change any time, it’s basicly impossible to port it to GLSL and extremely hard to port to native code.
You’d really need a Domain Specific Language to truely transform to vector-math. Doing it on the GPU adds a significant overhead of copying the data back and forth all the time, so even when the transformer is there, you’d have to specificly design your code around it, instead of trying to find patterns in existing bytecode.
don’t think at the micro level.
I’m NOT talking about translating a single math API call to JNI, like vector4.add(vecto4 right), but about a methods using such an API to be compiled to a single native method using SIMD.
For example a method performing vertex blending: it’s likely to iterate over say 2k-50k vectors each transformed by 1-4matrices for a single virtual character - that’s when its worth to use SIMD.
Now we agreed that translating custom byte code to a native function using SIMD is very difficult (even for SUN people :-)),. However, things become much easier if the method only contains operations on primitive types, no method calls except to a special math-lib and no or only selected control flow constructs,… (the more restrictions, the easier it is ;-))
I’m not thinking at the micro-level.
All the above is still next to impossible. Everything should be put into arrays or buffers (no objects anywhere) before this would have a chance. If one is making such an effort, he can as well port it himself. bytecode analysis and transformation won’t get you anywhere, because traversing all those (dynamic) object-references with random pointers, is a horrendous datastructure for SIMD related code.
Actually, I’d prefer a DSL for vecmath. In principle that’s also what it is, but embedded in Java. This has the advantage that the programmer doesn’t need to call things like 'execute(VecMathProg). On the other hand Java doesn’t allow to embed it nicely: no operator overloading, implicit casts).
However, it would be easier to translate a DSL created upon Groovy (or Scala) to a native function, than a working at the bytecode level.
I think the usage of classes of type T as well as Arrays of them T[] should be fine, if:
- the are declared final
- contain only primitives and primitve arrays fields
checking the referred class attributes and method paramters should not be difficult.
sorry for confusion, that post I answered to ‘bitshit’…
Why do you care so much about he says? A game is not built by one person alone and Id is bigger than him. He never had any sympathy for Java and he will say as bad things as he can against it simply because it is not like “C”. Forget it.
What you should worry about is to make Java games faster and not what he says. If what he says uncovered problems in the JVM than you have a big problem. Why didn’t you foresee this?