Mark, I understand your points, but disagree.
It is true that native code is needed to use Altivec instructions. Therefore, you are right that optimisations like these would have to cross the JNI boundary. Therefore, it is clear to me that for small amounts of data or processing, Altivec gains are little. However, this is not what Altivec was intended for. It handles large sets of processing and data. Otherwise optimisations made are not justified when efforts are considered. So agree that using this technology to perform a few matrix/vector operations is not efficient effort. HOWEVER, I hae written several apps that do quite a large amount of matrix/vector operations, and these operations VERY QUICKLY become the bottleneck, not the hardware. Therefore, yes often the hardware is the bottleneck, but often it is Java. If the bottleneck is Java, I propose developing classes for doing operations on large batches of data, which would be accelerated via JNI and NIO (possibly, dont know much about these yet) on both MMX and Altivec. Imagine then that I could load up my Batch class with 2000 or 20000 or whatever number of matrices/vectors. Then any time I need an operation performed on them, I call that method in the Batch class, and it is performed, fully accelerated by hardware SIMD (altivec, mmx) if present. This is what im talking about. It is divergent from what you understood, based on your previous email. Your points are well taken about compiler level optimisations, etc, but im talking about more developer level usages. Please let me know what you think. Sincerely, Ian Nieves On Tue, 18 Feb 2003, Mark Hood wrote: > > Date: Mon, 17 Feb 2003 00:50:44 -0700 > > From: Ian Nieves <[EMAIL PROTECTED]> > > > > I wanted to use this email to get people thinking about how Altivec can > > increase the performance of Java3D applications. That is, I hope to see > > responses to this email. > > Someone else also posted a question about the 3DNow x86 processor extensions > with respect to Java 3D. > > The thing is, alternative processor instructions can only be exploited by > natively compiled code. The overhead of crossing the JNI barrier for single > calls to vecmath and Transform3D methods would most likely outweigh any > hardware performance gains. It's effective for 3D rendering only in that we > make very few calls across the JNI for relatively large amounts of data. > > The underlying OpenGL or D3D implementation may of course use processor > extensions as well as the available 3D graphics hardware. Solaris OpenGL, for > example, uses the VIZ extensions on Sparc when appropriate. > > You would really need to talk to the Java compiler folks about expoiting 3DNow, > Altivec, or MMX instruction sets in a general way for Java. Even then, it's > difficult to see how an enhancement like that could be done transparently -- > how does the compiler know it's performing a matrix multiply unless there are > new Java bytecodes defined or the app makes a special System call like > arraycopy()? > > Java 3D performs all matrix and vector operations in pure Java, down to the > level of setting the model-view and projection matrices, before letting the > graphics hardware take over. Those operations don't appear to be the > performance bottleneck for any Java 3D applications -- it's usually the speed > of the graphics hardware, updates to the scene graph, the amount of memory > consumed, and the cost of copying and moving data around. > > -- Mark Hood > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff JAVA3D-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
