Date: Sun, 23 Apr 1995 18:06:20 +0000 () From: "John S. Dyson" <toor@jsdinc.root.com> To: FreeBSD.org!hackers@implode.root.com Cc: hackers@FreeBSD.org Subject: Re: benchmark hell.. Message-ID: <199504231806.SAA00351@localhost> In-Reply-To: <199504232155.XAA02620@jette.heep.sax.de> from "J Wunsch" at Apr 23, 95 11:55:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Part of the execl problem is the Sun-OS style shared libs that we > > use. > > To the contrary, *make*ing the Linux shlib's is a pain in the butt, > while it's a very easy process to create a SunOS-like shlib. > I agree... I have built some large SVR3 style shared libs in the past (100-500 entry points), from code that wasn't originally meant to use them. But the SunOS style shared libs are slower to start-up and take an extra (scarce) register much of the time on an X86. On some machines like the R3000-R4400 that I use/kernel hack at work, it really does not cost as much (they pre-bind the shared libs to an address, and the R3000-R4400's have lots of registers.) In fact, you can produces SunOS style shared libs directly from the .a's on the R3000-R4400's!!!! The fact is though, we DO have what we have, and I hope that we can make our shlib's faster and more efficient. We have done lots in the mmap code to help mitigate the speed issues, and it would be nice if someone could take on the task of improving the efficiency from the ld.so viewpoint someday. Note that I wasn't saying that our shared libs are BAD, it is just that they can make it seem that the system is slower (and in some cases can make a difference in reality). But indeed the SunOS scheme is more flexible. John dyson@root.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504231806.SAA00351>