Date: Mon, 7 Sep 1998 09:10:01 -0700 (PDT) From: Martin Cracauer <cracauer@cons.org> To: freebsd-bugs@FreeBSD.ORG Subject: Re: gnu/7811: Patch to build Objective C library shared Message-ID: <199809071610.JAA21983@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR gnu/7811; it has been noted by GNATS. From: Martin Cracauer <cracauer@cons.org> 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 <cracauer@cons.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809071610.JAA21983>