From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <94de6d3ea92d11ed9b35646bbc71d08f@quanstro.net> From: erik quanstrom Date: Mon, 24 Apr 2006 21:30:37 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] impressive MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 453afce0-ead1-11e9-9d60-3106f5b1d025 On Mon Apr 24 21:16:57 CDT 2006, dfawcus@cisco.com wrote: > On Mon, Apr 24, 2006 at 02:37:21PM -0600, Ronald G Minnich wrote: > > This program: > > > > compiles to a 512KB binary on linux with -static > > glibc is bloated, printf and strtoul are also quite large. [..,] noooo.... you're kidding, right? this is the gnu fallacy in action. nobody can find a theoretical algorithmic weakness, so it must be better. (my take: if it's sufficiently complicated, it can't be criticized by anybody who understands it. proof: nobody has enough time to understand it. qed.) ; wc -l /sys/src/sys/src/libc/port/strstr.c 29 /sys/src/libc/port/strstr.c ; wc -l $home/glibc-2.3.5/sysdeps/generic/strstr.c 123 /home/quanstro/glibc-2.3.5/sysdeps/generic/strstr.c the gnu strstr is really slick and exploits many tricks, but it's 4-5x bigger than the plan 9 version. i would venture to guess that for the common case of smallish searches on typically cache-bound systems, the plan 9 version beats the pants off the glibc version. (and, if you follow the thinking through to a whole library, you start thinking that dynamic libraries and other complicated cheats are good ideas.) - erik