On Di, 2010-04-13 at 08:16 -0500, Peter Cao wrote: > > Stamminger, Johannes wrote: > > Hi! > > > > > > On Mo, 2010-04-12 at 15:39 -0500, Peter Cao wrote: > > > >>>> wrapping the native shared libraries. And it is *not* hdf-java as this > >>>> does not support the H5PT but using JNA for that purpose. > >>>> > >>>> Still interested? > >>>> > >>> ... > >>> > >> It will be very helpful to see the difference of JNA and JNI. The > >> current hdf-java JNI was carefully > >> designed so that the memory allocated in Java is directly used in the > >> JNI C. The overhead between > >> Java and C is very small, i.e. the I/O from JNI calls is close to C. > >> > >> A good way to test is to read and write a simple 1-D array, e.g. > >> float[10*1024*1024] in JNA and > >> in C (directly use the HDF5 library) and see the results. > > > > JNA with using there "direct mapping" (as I do) intends to be nearly as > > fast as JNI (in the background it seems to do just the same. But it has > > to do some initial additional shared library analysis). > > > > Indeed, a JNI comparison would be interesting. Maybe I go for this > > later, currently this is not my main target ... > > > You don't have to compare with JNI. Just compare to a simple C program. > If JNA is close to C in terms of memory usage and io speed, JNA is a way > to go.
Ok, let's compare plain C, JNI, JNA-interface mapping and JNA-direct mapping then. All those make sense IMHO. But I have no idea of how to measure native mem usage in java ... ? ... > > One of my major problems with this JNA approach remain the hdf constants > > as they are not available in the hdf native libs as symbols, only as > > #define's. My current workaround is to use - only for this purpose - the > > hdf-java's HDF5Constants (implicating to additionally put the hdf native > > libs to the java.library.path and the hdf-java jar's to the classpath). > > But I will contact the helpdesk to simply add the constants additionally > > as symbols to the native libs. And in the meanwhile I will do this > > myself with patching and compiling the sources. > > Btw the hdf-java suffers the same and has written some JNI code for this > > purpose. > > > Some ( or most) of the HDF5 constant values are defined at runtime. > There is no way to get such > C constants in Java directly. This is why we use private function calls > in JNI to get the values. In the JNA documentation I found https://jna.dev.java.net/javadoc/com/sun/jna/NativeLibrary.html#getGlobalVariableAddress(java.lang.String) So global variables should be accessible from java - or are global variables no option for this purpose? Best regards, Johannes Stamminger
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
