From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5ff0a30a1e679e61ff04ca7a4cdcfa4c@quanstro.net> From: erik quanstrom Date: Tue, 25 Apr 2006 05:20:19 -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: 45dd92a2-ead1-11e9-9d60-3106f5b1d025 i have not had a chance to look at dietlibc printf functions. the gnu version is extra jumbo, and the code is very difficult to read. but printf is a pretty big set of functions, regardless. it's curious that __lltostr is a different functino tha __ltostr. as rob loves to point out, for small values of n, simple algorithms are best. n is usually small. so i think it's generally a incorrect to contrast small and fast. - erik On Mon Apr 24 21:50:10 CDT 2006, dfawcus@cisco.com wrote: > On Mon, Apr 24, 2006 at 09:30:37PM -0500, erik quanstrom wrote: > > On Mon Apr 24 21:16:57 CDT 2006, dfawcus@cisco.com wrote: > > > glibc is bloated, printf and strtoul are also quite large. [..,] > > > > noooo.... you're kidding, right? > > What I meant is that relative to some other (commonly used) routines within > dietlibc, printf and stroul are large in object size terms. I should have > written the above as two sentances. > > The biggest things seem to be printf support, perror support, and strtoul. > > __v_printf |080484b8| T | FUNC|00000773| |.text > __dtostr |08048cc7| T | FUNC|000003ae| |.text > sys_errlist |08049650| R | OBJECT|000001f8| |.rodata > __umoddi3 |08049400| T | FUNC|000001e5| |.text > __udivdi3 |080492c0| T | FUNC|0000013e| |.text > strtoul |080482f0| T | FUNC|0000010e| |.text > __lltostr |080490ec| T | FUNC|000000db| |.text > __ltostr |080491c8| T | FUNC|00000099| |.text > strtol |08048268| T | FUNC|00000086| |.text > perror |080481ec| T | FUNC|0000007a| |.text > > compare to main: > > main |080480bc| T | FUNC|000000d6| |.text > > The dietlibc versions of the algorithms have generally been written to be > small, rather than fast. > > DF