spanki@lands.ced.berkeley.edu (Frank Goodman) (01/06/90)
I just built X11R4 on my sun 3/*'s all running SunOS 4.0.3. It required the normal amount of coersion that one would expect. Now that it's built, could someone explain to me why I want to take advantage of Sun's shared libraries? There is nothing I've found in the X documentation that really explains the difference. Is there any difference in run-time memeory use (RAM) by programs that use shared libraries? The binarys are much smaller, but my performance priorities on my sun 3/50's are RAM first, speed second(startup speed too), and diskspace third. What have shared libs bought me? Can I, as an application programmer, use these libraries, and is there any difference in the linking syntax, or for that matter the code I must write? In other words do I just go about writing my code and use a -lX11 flag and I'll automatically get the shared libs or is there more to it? Basically, I have no clue. Could some please spell out what the heck they do, along with all the pros/cons you can think of? I'm sure there must be others equally confused. thanks Frank. --------------------------------------------------------------------------- Frank Goodman arpa: spanki@CED.Berkeley.EDU University of California, Berkeley or: spanki%CED@jade.Berkeley.EDU College of Environmental Design uucp: ...hplabs!ucbvax!ced!spanki S.I.S. Research Laboratory phone: (415) 849-1166 ---------------------------------------------------------------------------
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/09/90)
There is nothing I've found in the X documentation
that really explains the difference.
There is nothing about X that is particularly special wrt shared libraries.
Is there any difference in run-time memeory use (RAM) by programs that use
shared libraries?
Yes, if you run different clients using a given shared library, they will
share the library text and data. If you link the library statically into
each client, the code and data gets replicated. The tradeoff depends on
how much of the library each client uses (one copy of the entire library,
vs. several pieces of the library). In general, for the X libraries, I
suspect the shared form is better.
Can I, as an application programmer, use these libraries,
Of course.
and is there any difference in the linking syntax,
or for that matter the code I must write?
No. There are differences in how dependencies are specified, but if you
use Imakefiles, everything is taken care of for you.john@acorn.co.uk (John Bowler) (01/10/90)
In article <9001081700.AA00895@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > >Yes, if you run different clients using a given shared library, they will >share the library text and data. If you link the library statically into ^^^^^^^^ >each client, the code and data gets replicated. The tradeoff depends on >how much of the library each client uses (one copy of the entire library, >vs. several pieces of the library). In general, for the X libraries, I >suspect the shared form is better. Even in the ``best'' shared library schemes the data is only shared until it is modified. Obviously when an application changes library data (possibly via the library code) it needs its own copy of the data. In practice in most schemes a simple data reference will cause replication of the data. This is a particular problem with the Xt implementation. Shared libXt's are possible and beneficial, but our experiments seem to indicate that sharing things built on top of libXt is not worth while - we tried libXaw. This is because of the relatively high ratio of data to code in the Intrinsics implementation. I hypothesis that the Xt design causes two problems; firstly the locality of data references is reduced, because the flow of control of the code causes data references every time a function call is made via an object method (these are stored as function pointers). I don't know how serious this is (it is, after all, only one extra reference per function call, but traditionally object methods can be very simple). Secondly the cost of sharing a widget library becomes substantial. In a normal shared library, with relatively little library data, including things in the shared library which are not used in a particular application decreases the locality of code references but this is vastly offset by the requirement for only one instance of the library (code) in the system. In libXaw (for example) including widgets which are not used in a library tends to drag all the data of the widget into each application - this has a substantial cost, particularly on machines with large page sizes. When we build shared libraries we optimise the mix of code in the library with the aim of maximising the text size and minimising the data size. Our current set of shared libraries has sizes as follows:- text data library 164868 6420 libX11 110880 16716 libXt 66960 2772 libc (an old one) 131312 4884 libc (our latest) [Note that we have our own shared library mechanism - but the arguments are equally applicable to SVR4 style shared libraries] libXt has a high data/code ratio partly because it proved impossible to separate out the parts of the code with a large amount of data. Our shared libraries must have no external references (like the SVR3 scheme); the closure of the libXt functionality pulls in almost every module in the libXt implementation. For us sharing the data does have an advantage, in that it saves disc space (the library data is stored once in the shared library) - I'm not sure if the SUN/SVR4 scheme has this advantage. If disc space is a factor (we have supply a BSD 4.3/NFS/X11 system on a 50MByte winchester) sharing as much as possible may be desirable. Otherwise it is relatively easy to make clear rules about what to share and what not to share; ignoring disc space issues:- 1) There is absolutely no point sharing something if there is only ever one *running* application which uses it. To be worthwhile the shared code must be used in at least two applications which are executing simulaneously. 2) There is a definite advantage in sharing code between applications which not only run concurrently, but interact as well. In the X case sharing code between a window manager and a client is a *major* win. Sharing code between the server and any client which runs on the same machine is even more worthwhile. 3) Typically (medium or large page size - a SUN at 8kbyte is medium) if the non-shared application size (code+static data) is less than the shared application size (application specific(not shared) code + *all* the data, including the library data) you have lost by sharing. This is what seemed likely to happen with libXaw; similarly I would expect sharing the Motif widget library would not be advantageous. John Bowler (jbowler@acorn.co.uk)