From owner-freebsd-bugs Mon Sep 7 09:10:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19898 for freebsd-bugs-outgoing; Mon, 7 Sep 1998 09:10:04 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19851 for ; Mon, 7 Sep 1998 09:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id JAA21983; Mon, 7 Sep 1998 09:10:01 -0700 (PDT) Date: Mon, 7 Sep 1998 09:10:01 -0700 (PDT) Message-Id: <199809071610.JAA21983@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Martin Cracauer Subject: Re: gnu/7811: Patch to build Objective C library shared Reply-To: Martin Cracauer Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR gnu/7811; it has been noted by GNATS. From: Martin Cracauer To: shmit@kublai.com, FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: gnu/7811: Patch to build Objective C library shared Date: Mon, 7 Sep 1998 18:00:41 +0200 In <199809021617.MAA14165@natasya.kublai.com>, shmit@kublai.com wrote: > It was not possible to build the Objective C library shared with > a.out, because the linker would generate symbol relocation warnings > that Bruce didn't like. With ELF, I get no such warnings, so I've > put a conditional in to building that will generate a shared lib > for ELF, but not for a.out. Do you really think that makes sense? Remember that each Objective-C method call calls a function from the runtime and making it shared means one pointer indirection more, with the usual bad cache effects. Here is a benchmark running small methods, smaller than a method normally is, i.e. just adding to an instance variable. I expect this benchmark not to show any cache trashing effects that a real application may encounter. This is an aout system. Sorry for the German strings. libobjc statically linked: 1.81 s (99.9%): `call auf id (aufwaermrunde)' 1.80 s (99.5%): `call auf id' 1.76 s (99.9%): `call auf id, 4. Subclasse' 1.76 s (100.0%): `call auf id, 3. Subclasse (vererbte Message)' 1.61 s (97.8%): `call auf id, 4. Subclasse ohne Parameter' 1.81 s (99.9%): `call auf id' 0.84 s (99.9%): `call auf id, 4. Subcl. ueber selector mit parameter' 0.68 s (99.9%): `call auf id, 4. Subcl. ueber selector ohne parameter' 1.86 s (100.0%): `call auf id, 4 Subclassen' 1.82 s (100.0%): `call auf declared' 3.63 s (100.0%): `call auf id mit id' libobjoc dynamically linked: 2.20 s (100.0%): `call auf id (aufwaermrunde)' 2.18 s (100.0%): `call auf id' 2.18 s (100.0%): `call auf id, 4. Subclasse' 2.20 s (98.6%): `call auf id, 3. Subclasse (vererbte Message)' 1.97 s (99.0%): `call auf id, 4. Subclasse ohne Parameter' 2.20 s (99.7%): `call auf id' 0.83 s (95.3%): `call auf id, 4. Subcl. ueber selector mit parameter' 0.63 s (99.4%): `call auf id, 4. Subcl. ueber selector ohne parameter' 2.29 s (99.6%): `call auf id, 4 Subclassen' 2.14 s (100.0%): `call auf declared' 4.69 s (99.7%): `call auf id mit id' The lib is < 80 KB. That isn't worth the slowdown, IMHO. The right thing might be to pull the method lookup functions into a seperate library that is static only and the rest into a dynamic library, but I think that will break most application Makefiles respectivly configure scripts. Opinions? If noone objects, I would leave it disabled, but change the string from NOPIC= does not work to NOPIC= works, but method lookup slowdown is significant Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message