To optimize or not
Has anyone got any feelings/figures for the usefulness of code optimisation using the Blackdown 1.2.2 JDK? I may do some experimentation but I wondered if anyone had done any analysis on whether it makes much difference. Obviously it will depend on the code, but do people use it as a matter of course? Thanks for any help, Rob Kirkbride -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To optimize or not
Thanks a lot for the info yes it was the JDK optimizer I was interested in, but I may give the profiler a go as I've had much success on other projects (not involving java) I was thinking of gcc in that gcc is known to produce very non-optimal code unless optimisation is performed, I wondered what the Java optimiser was like. Much of my application is gui driven but I suspect there are areas when my string handling is not optimal. I've not used the profiler, is that 'jvmpi'? I couldn't find it in the Blackdown distribution, only a zip file in the documentation. Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem with jni lib
I used g++ instead of gcc now and it seems the error is fixed.
thanks for your help. l learned a lot about library files now.
Cheers,
Kason
Joi Ellis wrote:
> On Tue, 31 Oct 2000, kason wong wrote:
>
> > Hi,
> >
> > I guess I know what's the really problem is.
> >
> > I think I should make my problem more clear. I used to use libutil.a libpthread.a
>libcops.a to make ReqMsg.cxx executable. now I want to use COPS.cxx and
> > .h files (JNI layers) to link a java program to call ReqMsg. so I modified a
>little of you Makefile to do it.
> >
> > and after that in my java code, should i just load COPS
> > or I need to load cops, util, pthread too?
>
> I'm not familiar with COPS and cops.
>
> Ignoring the whole threads mismatch issue, you load the single
> library, libutil.so. The gcc/link step creates that lib so that it
> is entirely self-contained. The linker pulls your .o files,
> routines from all of the libraries presented on the g++ command, plus the
> standard default libs, and writes everything into the target libutil.so
> file that isn't part of the standard load path. It doesn't actually
> write copies of the system library code, it writes pointers to it so that
> the dynamic loader knows where to look for them. This makes your .so
> file smaller than a static-linked module. (It also seems to be the
> only library format JVMs know how to load.)
>
> So, you only need to loadLibrary("util"). You don't need to load
> anything it depends upon because that's already been taken care of
> by the linker.
>
> If 'ldd -r' finds missing symbols, fix the g++/link command. You can't
> get around it by using java's loadLibrary(). It never worked when I
> tried it, either.
>
> > if i need to load all the libraries, the problem is I can't not ldd libutil and
>libpthread.so alone. it gives me alot of undefined symbol errors ..
>
> Every single library your app uses must be present in either the LINKLIBS
> variable or in the JAPILIBS/APILIBS/APISOLIBS variables. The ONLY library
> you need to run 'ldd -r' against is your own. It's pointless running it
> against system libraries, and you don't loadLibrary() system libraries.
>
> > from the lib size I can see libCOPS.so doesn't include the objects in libcops,
>libpthread or libutil.so.
> > -rwxr-xr-x1 kwongkwong 360429 Oct 31 14:55 libCOPS.so*
> > -rw-r--r--1 kwongkwong 6834356 Oct 29 13:44 libcops.a
> > -rwxr-xr-x1 kwongkwong 2352811 Oct 30 15:56 libcops.so*
> > -rw-r--r--1 kwongkwong 668698 Oct 30 12:07 libpthread.a
> > -rwxr-xr-x1 kwongkwong 243595 Oct 30 18:23 libpthread.so*
> > -rw-r--r--1 kwongkwong 6469118 Oct 29 18:27 libutil.a
> > -rwxr-xr-x1 kwongkwong 3061632 Oct 31 14:56 libutil.so*
>
> Don't make too many assumptions based on size. The link may pull only
> a handful of routines from a large library to build your own library
> or object file. If you really want to see what's going on, make sure
> your Makefile contains:
>
> LDOPT=-Xlinker -t -Xlinker -Map -Xlinker /tmp/linkmap -Xlinker -cref
>
> and then peer at /tmp/linkmap and see what it actually did. That map
> is a contents and symbol list of your libutil.so file.
>
> --
> Joi EllisSoftware Engineer
> Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED]
>
> No matter what we think of Linux versus FreeBSD, etc., the one thing I
> really like about Linux is that it has Microsoft worried. Anything
> that kicks a monopoly in the pants has got to be good for something.
>- Chris Johnson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To optimize or not
KIRKBRIDE Rob wrote: > > Thanks a lot for the info yes it was the JDK optimizer I was interested in Oh, you mean "javac -O"? I'm afraid that's not very useful speed-wise. I have never noticed a noticeable speed difference between -O and not -O with the Blackdown JDK, but on the other hand I haven't really measured it either. > Much of my application is gui driven but I suspect there are areas when my string >handling is not optimal. I've not used the profiler, is that 'jvmpi'? I couldn't find >it in the Blackdown distribution, only a zip file in the documentation. Run java -Xrunhprof:help and follow the instructions to create a profiling file. If you can't figure out how to interpret that file, ask again... Ekkehard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To optimize or not
On Thu, Nov 02, 2000 at 11:29:00AM +, KIRKBRIDE Rob wrote: > Thanks a lot for the info yes it was the JDK optimizer I was interested in, but I >may give the profiler a go as I've had much success on other projects (not involving >java) > I was thinking of gcc in that gcc is known to produce very non-optimal code unless >optimisation is performed, I wondered what the Java optimiser was like. Java is, in theory, less dependent on compile-time optimization than native code. OTOH, I've seen choice of compilers make measurable differences in performance. For example, one bit of test code I worked with ran significantly better on several JVMs if built with the javac from IBM's JDK1.3 than the javac from the Blackdown JDK1.2.2. Nathan > > Much of my application is gui driven but I suspect there are areas when my string >handling is not optimal. I've not used the profiler, is that 'jvmpi'? I couldn't find >it in the Blackdown distribution, only a zip file in the documentation. > > Rob > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To optimize or not
I think the documentation for Sun's "javac" says that "-O" is a NOP. In theory (and in practice with some other compilers :-) there's a fair degree of scope for optimizing intermediate code. Not just dead code elimination, but reorganizing basic blocks, eliminating temporaries, and so on. (The Java bytecodes are in effect just another type of compiler intermediate code representation. QED.) - Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
