From: Eris Discordia <eris.discordia@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] mmap and shared libraries
Date: Thu, 6 Nov 2008 00:45:05 +0000 [thread overview]
Message-ID: <C9A2E584874CDAD0B23E1ABF@[192.168.1.2]> (raw)
> Sadly, the picture changes at run time: clock on plan 9 is 128k in
> memory, xclock is 4.2M RSS and 10M VSZ.
> Sic transit gloria .so. Of course, then we hear that "well, all that
> is shared". Hmm. Prove it.
I know one thing: every major operating system I have ever heard of
leverages shared libraries. Can all those people be wrong? I don't think
so.
> FWIW, the whole issue of goodness/badness of shared libraries has
> never been systematically measured as far as I know -- in terms of
> performance cost, overhead, throughput, the usual suspects -- or at
> least
> I've never seen it done. It would be a lot of work to do it correctly.
> Might be interesting.
Title: Dynamic Linking of Software Components
Author: Michael Franz
YoP: 1997
> ABSTRACT
>
> The concepts underlying dynamic linking reached maturity through modular
> operating systems and are being reintroduced in some of the most popular
> workstation and PC operating systems.
<http://portal.acm.org/citation.cfm?id=619016.620662&coll=GUIDE&dl=GUIDE&CFID=8901601&CFTOKEN=68907171>
The abstract says this is an overall survey of dynamic linking. I can't
access the full text and I wouldn't understand it even if I could. You are
the CS/CE person. Be the judge, too.
> So the compressed version is only 50% larger than acme. The point being?
That there's a lot of redundancy in the executable image principally
imposed by the binary format.
$ readelf -e /usr/local/bin/vim
Reveals over 170 KB of data only in .data, .rodata, and .bss sections.
$ objdump -s /usr/local/bin/vim
Displays tons of zeroes in all sections except .text. Even RLE could have
considerably reduced the image size.
> Does the redundant litter cross the network when I have it mounted via
> a share and execute the program or not? That was the original
> discussion.
I don't know. The size of Emacs executable has as much connection to that
question as I do, but it was _you_ who made the bad Emacs joke.
> Wrong for ELF.
About ELF:
> Defining data elements in the bss section is somewhat different from
> defining them in the data section. Instead of declaring specific data
> types, you just declare raw segments of memory that are reserved for
> whatever purpose you need them for.
>
> [...]
>
> One benefit to declaring data in the bss section is that the data is not
> included in the executable program. When data is defined in the data
> section, it must be included in the executable program, since it must be
> initialized with a specific value. Because the data areas declared in the
> bss section are not initialized with program data, the memory areas are
> reserved at runtime, and do not have to be included in the final program.
-- Professional Assembly Programming, Richard Blum, in the context of using
(g)as and ELF
Exactly what I said. I don't want to sound authoritative but when something
is right it is right and there's nothing you or I can do about it. So:
"right for ELF."
Executable image size can be less than memory size because there can be
_uninitialized_ data reserved in data segments, e.g. when you reserve a
buffer but don't care what it initially contains. However, _initialized_
data always and invariably gets written to disk--think of a whole 64K of
zeroes.
Example from a simple program for Flat Assembler with Win32 target:
section '.data' data readable writeable
buffer_ptr dd 00h <---- a pointer reserved, and initialized
buffer db 00FFFFh dup (?) <---- a buffer reserved, but not initialized
> Ah! Now we're into feature comparisons! I'm game. How did you get to 1
> in 5 and not 1 in 4.8, or 1 in 6?
You know very well that the ratio is an inaccurate measure as the context
suggests. 1 to 5 is like your pinkie to all your fingers. Trying to
"context-switch" and turn a guesstimate into an exact number is only a
diversionary technique you have employed to evade an easily demonstrable
fact. Namely that Acme is a minimal text editor claiming to be an IDE while
Emacs is a behemoth with more features than you could count in a day, and
the following night--not that I believe Emacs is any better than Acme. Vim
leans more towards Emacs.
--On Wednesday, November 05, 2008 2:13 PM -0800 ron minnich
<rminnich@gmail.com> wrote:
> On Wed, Nov 5, 2008 at 12:54 PM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>>> yes, I agree, I was being terribly unfair to plan 9. Acme on plan 9 is
>>> about 1/2 M. Vim on DOS is 3x larger? impressive.
>>
>> My intent was, of course, to show your comparison is baseless. It seems
>> you still haven't realized that. You think Plan 9 is great?
>
> Actually, to keep it simple, I was trying to make a simple point, with
> a bit of humor intended, and not actually even directed at you,: that
> code built with shared libraries is not
> necessarily, or always, smaller than code built otherwise, for
> programs of similar capability. I don't have an emacs
> linked statically, however, so I took the nearest materials at hand.
> It depends on a lot of circumstances.
>
> There is the example of xclock which is small with X11 .so, and quite
> large otherwise. And there, for the case of a "clock", shared
> libraries clearly reduce disk footprint:
> xclock binary is about 1/10 the size of plan 9 clock (19K vs. 158K)..
>
> Sadly, the picture changes at run time: clock on plan 9 is 128k in
> memory, xclock is 4.2M RSS and 10M VSZ.
> Sic transit gloria .so. Of course, then we hear that "well, all that
> is shared". Hmm. Prove it.
>
> FWIW, the whole issue of goodness/badness of shared libraries has
> never been systematically measured as far as I know -- in terms of
> performance cost, overhead, throughput, the usual suspects -- or at
> least
> I've never seen it done. It would be a lot of work to do it correctly.
> Might be interesting.
>
>> The GUI version of Vim on Windows (gvim.exe) compresses to 734,713 bytes
>
> So the compressed version is only 50% larger than acme. The point being?
>
>> because the bigger part of the uncompressed 1,585,152 bytes is redundant
>> filler required by the binary format specification.
>
> Does the redundant litter cross the network when I have it mounted via
> a share and execute the program or not? That was the original
> discussion.
>
>> The same happens for the
>> vim executable on FreeBSD (1,221,212 bzip2'ed to 616,236). The Windows PE
>> binary format and ELF both require the executable image to contain all
>> initialized but essentially redundant (i.e. zeroed) parts of the data
>> segement. Don't pretend you didn't know that.
>
> Wrong for ELF.
>
> Simple example from /bin/cat:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x0049e8 0x100149e8 0x100149e8 0x00284 0x003cc RW
> 0x10000
>
> note that filesize is < memory size. I'll let you figure out how it works.
>
> This is the problem with your posts. You sound very authoritative, and
> I'm sure you figure you know all these bits,
> but you're wrong so often. It's confusing. It would be unfortunate
> were people to believe you are as right as you think you are.
>
>>
>> Also, Acme in p9p or on Plan 9 performs less than 1 in 5 of the functions
>> vi/vim does. That ratio is even smaller when comparing Acme to Emacs. So
>> you have been unfair. No kidding.
>>
>
> Ah! Now we're into feature comparisons! I'm game. How did you get to 1
> in 5 and not 1 in 4.8, or 1 in 6?
> Of course, you have to take into account that acme's extensions live
> in /bin or your number is bogus.
>
> ron
>
next reply other threads:[~2008-11-06 0:45 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-06 0:45 Eris Discordia [this message]
2008-11-06 5:32 ` Wes Kussmaul
[not found] <88F7FC88EA146B5826CA4895@192.168.1.2>
2008-11-06 8:45 ` Bruce Ellis
-- strict thread matches above, loose matches on Subject: below --
2008-11-06 7:34 Eris Discordia
[not found] <C9A2E584874CDAD0B23E1ABF@192.168.1.2>
2008-11-06 1:25 ` ron minnich
2008-11-06 1:20 ` erik quanstrom
2008-11-06 7:20 ` Skip Tavakkolian
2008-11-06 0:17 Eris Discordia
2008-11-06 1:26 ` erik quanstrom
[not found] <B9EFF9908B07EE7F3D52A6FE@192.168.1.2>
2008-11-05 21:09 ` andrey mirtchovski
2008-11-05 21:58 ` Eris Discordia
2008-11-05 21:12 ` Rob Pike
2008-11-05 22:02 ` Eris Discordia
2008-11-05 22:44 ` Skip Tavakkolian
2008-11-05 22:50 ` john
2008-11-05 22:13 ` ron minnich
2008-11-06 0:48 ` Eris Discordia
2008-11-06 0:53 ` Eris Discordia
[not found] ` <F57A01C450F2AF0D885A4EA2@192.168.1.2>
2008-11-06 1:17 ` andrey mirtchovski
2008-11-06 1:23 ` Rob Pike
2008-11-06 7:11 ` Eris Discordia
[not found] ` <4E85CF437A5996E22A154410@192.168.1.2>
2008-11-06 4:01 ` Noah Evans
2008-11-08 2:07 ` Lyndon Nerenberg
2008-11-08 15:21 ` Eris Discordia
[not found] ` <08704C38FEA587112964C8F7@192.168.1.2>
2008-11-08 21:37 ` Noah Evans
2008-11-08 22:12 ` Bruce Ellis
2008-11-09 14:53 ` Eris Discordia
[not found] ` <44E0B0824F0CA75923FADB8F@192.168.1.2>
2008-11-09 15:52 ` Bruce Ellis
2008-11-09 21:16 ` Noah Evans
2008-11-09 22:07 ` Bruce Ellis
2008-11-09 22:37 ` Dan Cross
2008-11-09 22:57 ` Bruce Ellis
2008-11-06 4:03 ` Roman Shaposhnik
2008-11-05 20:54 Eris Discordia
[not found] <98D93FD5E6510345BB763E1E@192.168.1.2>
2008-11-05 18:15 ` ron minnich
2008-11-05 18:55 ` David Leimbach
2008-11-05 19:28 ` Rob Pike
2008-11-05 10:57 Eris Discordia
2008-11-05 16:34 ` Abhishek Kulkarni
2008-11-05 17:19 ` roger peppe
[not found] <0BA37138CD8655143F1F7260@192.168.1.2>
2008-11-04 15:59 ` ron minnich
2008-11-05 8:26 ` Bruce Ellis
2008-11-05 8:32 ` Lyndon Nerenberg
2008-11-05 8:38 ` Bruce Ellis
2008-11-05 8:43 ` Lyndon Nerenberg
2008-11-05 10:33 ` Eris Discordia
[not found] ` <4EA3104D894655DB38E5DC15@192.168.1.2>
2008-11-05 10:55 ` Robert Raschke
2008-11-05 11:02 ` Eris Discordia
2008-11-04 15:06 Eris Discordia
2008-11-03 6:27 [9fans] mmap Charles Forsyth
2008-11-03 13:16 ` [9fans] mmap and shared libraries dave.l
2008-11-03 15:55 ` Kernel Panic
2008-11-04 1:23 ` Lyndon Nerenberg
2008-11-04 3:46 ` michael block
2008-11-05 5:17 ` Roman Shaposhnik
2008-11-05 5:21 ` ron minnich
2008-11-05 5:25 ` Lyndon Nerenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='C9A2E584874CDAD0B23E1ABF@[192.168.1.2]' \
--to=eris.discordia@gmail.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).