From owner-freebsd-hackers Sun Apr 23 16:04:31 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA12981 for hackers-outgoing; Sun, 23 Apr 1995 16:04:31 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA12975 for ; Sun, 23 Apr 1995 16:04:29 -0700 Received: from jsdinc.root.com (uucp@localhost) by Root.COM (8.6.8/8.6.5) with UUCP id QAA09525; Sun, 23 Apr 1995 16:04:26 -0700 Received: (root@localhost) by localhost (8.6.11/8.6.5) id SAA00351; Sun, 23 Apr 1995 18:06:20 GMT From: "John S. Dyson" Message-Id: <199504231806.SAA00351@localhost> Subject: Re: benchmark hell.. To: FreeBSD.org!hackers@implode.root.com Date: Sun, 23 Apr 1995 18:06:20 +0000 () Cc: hackers@FreeBSD.org In-Reply-To: <199504232155.XAA02620@jette.heep.sax.de> from "J Wunsch" at Apr 23, 95 11:55:49 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1328 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > 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