Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!sol.ctr.columbia.edu!news.kei.com!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Which is better ? Message-ID: <1993May30.231852.6748@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <1u5l7q$i4m@umcc.umcc.umich.edu> <1993May28.201031.6850@serval.net.wsu.edu> <1993May30.133258.4476@knobel.GUN.de> Date: Sun, 30 May 93 23:18:52 GMT Lines: 87 In article <1993May30.133258.4476@knobel.GUN.de> andreas@knobel.GUN.de (Andreas Klemm) writes: >In <1993May28.201031.6850@serval.net.wsu.edu> hlu@eecs.wsu.edu (HJ Lu) writes: >|answer from me. Without the shared libraries, I don't think 386bsd will >|have any real performance edge over Linux. BTW, if you are doing FP >|stuff, Linux may be better for you. > >What have shared libraries to deal with better performance ? >Ok you get significant smaller code. And that can prevent a system >from being swapping or paging. >But the code isn't that fast as statically linked code. >because the shared memory organisation in the kernel produces some >overhead when running processes. > >Or did I misunderstand something ? Basically shared code between applications, and a less frequent lru on pages shared between applications. For multiple instances of a single program, shred libraries offer *NO* image size benefit... ie: if all you run are "xterm"s, then there isn't a problem. Shared libraries reduce the on disk image, sometimes significanlty for trivial programs. For non-trivial programs, there isn't as much of a savings, since the ratio of non-library-to-library code is much higher (the library makes up a smaller percentage of the image size on disk). This is a disk storage issue more than anything else. Linux will, in general, take up 20% less space for an equivalent functional install. Process load is slightly accellerated in a shared library environment, enhancing the *appearance* of speed by causing programs to start executing faster, expecially applications programs which produce immediate feedback (like displaying a menu, etc.). This is significantly mitigated by the way processes are started with a page-from-image mechanism in both 386BSD and Linux, where the advantage is generally one fewer pages to demand load. The costs of shared library are execution time, and are permanent by way of requiring a jump table indirection for library function references; this is somewhat (but not entirely) offset by the pages likelihood of being in core by virtue of being shared between multiple processes, Thus the advantages of shared libraries boil down to: o Somewhat (~20%) less disk space overall o Slightly faster start time for each process *if* it is a process that provides immediate feedback (appears to have better performance). o Ability to upgrade libraries without recompilation, as long as major revision number does not change (interface is static). o Overall less memory is used for a medium to large number of processes. The disadvantages are: o Slower overall performance of applications (doesn't really have better performance). All things being equal (they're not), shared libraries accelerate library debugging and availability. I say they are unequal because of the fact that thethe interface on the libraries is still not static; in fact, I had to make a change recently to get the srand48/drand48 patch installed, and this would change the size and location of entry points in any implementation currently available or currently under consideration or developement. Thus the upgrade ability is not an applicable advantage. The disk space advantage is not currently an issue worth consideration, as the number of patches required for current "best funcctionality" level are such that sufficient disk space for recompilations and developement tools (like the compiler) are still necessary. Without an additional 60% of disk space (say from 30M to 65M), there isn't sufficient space to produce a good robust system ; without 65M, a system that "fits" in 30M is just as useless as one requiring 40M (ie: without shared libs). The memory issues are moot, since the VM system still needs work, and once you hit the threshold of 8M, the memory issues are not going to be much of a problem one way or the other. I would say that at the current state of 386BSD, shared libraries are not really required nor are they very useful. Doesn't mean that those of us dealing with shared library implementations don't want to be ready when 386BSD becomes a little more mature; it just means that this should not be a factor in decisions you make at this time. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.