On Wed, Nov 5, 2008 at 12:54 PM, Eris Discordia <[EMAIL PROTECTED]> 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
