madler@nntp-server.caltech.edu (Mark Adler) (05/01/91)
Adrian Smith notices: >> A standard old "Hello World" in C takes 48K with no >> optimized compile switches on my slab. Nearly all of that is 48K is not necessary. The compile switches -s (to not include the symbol table info) and -object (to use the MH_OBJECT format which allows small binaries to be small) reduce the size considerably: beauty> cc -object -s hello.c beauty> ls -l a.out -rwxr-xr-x 1 me 1236 Apr 30 23:02 a.out* beauty> a.out hello, world A null program is 1140 bytes when compiled this way. The -s reduces the size from 48811 to 16384, and -object takes it from 16384 to 1236. -object doesn't seem to work with Objective-C programs though, so they have a minimum object size of 16K. -s does the same thing as strip, which you can do after the compile and load. I have used it often to make executables from ftp sites much smaller. Mark Adler madler@pooh.caltech.edu
J. Michael Ashley <jashley@tope.cs.indiana.edu> (05/02/91)
In article <1991May2.142103.6047@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: > >... ahem yes well all this talk about the size of binaries implies >that compiler writers are no longer concerned with space effeciency as >they used to be since internal memory is now cheap as dirt and >besides, you've got virtual memory so no problem right? Compiler writers still have to worry about page faults, so the issue is not entirely ignored. > Hmmmm... > still compilers should be more effecient about what they generate. A compiler could generate a relatively small amount of target code, but that code would probably run slower than the code produced by a compiler that strategically unrolled a few loops and inlined a couple of procedure calls. It's a tradeoff, and with virtual memory, most people would prefer to see faster code at the expense of code size. If people cared about code size, you would see such statistics in benchmarks. Sensible compiler writers will consider the amount of code generated by their compilers and make the tradeoffs they see as appropriate. Mike
jtn@potomac.ads.com (John T. Nelson) (05/02/91)
... ahem yes well all this talk about the size of binaries implies that compiler writers are no longer concerned with space effeciency as they used to be since internal memory is now cheap as dirt and besides, you've got virtual memory so no problem right? Hmmmm... still compilers should be more effecient about what they generate.
sstreep@elvis (Sam Streeper) (05/03/91)
In article <1991May2.142103.6047@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: > > .... ahem yes well all this talk about the size of binaries implies > that compiler writers are no longer concerned with space effeciency as > they used to be since internal memory is now cheap as dirt and > besides, you've got virtual memory so no problem right? Hmmmm... > still compilers should be more effecient about what they generate. Things are not always as they might seem. No file on disk will ever be smaller than the sector (or perhaps cluster) size, even if it has very few "meaningful" bytes. And no program in virtual memory will ever be smaller than the page size. Mach is (surprise) actually very smart about swapping, and pages from an executable file are not swapped out to the swap file because they already exist on the disk in page size chunks (8K). Thus you tend not to have executables taking twice as much disk space as necessary. Also, sometime for fun you might take a look at the assembly code gcc spits out. Its so optimized that it can be as difficult to read as clever hand coded assembly in many cases. cheers, -sam -- Opinions are not those of my employer. They're not even mine. They're probably wrong besides. How did they get in here, anyway?
n67786@cc.tut.fi (Tero Nieminen) (05/04/91)
In article <650@rosie.NeXT.COM> sstreep@elvis (Sam Streeper) writes:
No file on disk will ever be smaller than the sector (or perhaps
cluster) size, even if it has very few "meaningful" bytes.
Time for you to recheck the BSD fast file system internals, cause your
statement does not hold.
--
Tero Nieminen Tampere University of Technology
n67786@cc.tut.fi Tampere, Finland, Europemelling@cs.psu.edu (Michael D Mellinger) (05/04/91)
In article <N67786.91May4013238@lehtori.cc.tut.fi> n67786@cc.tut.fi (Tero Nieminen) writes: In article <650@rosie.NeXT.COM> sstreep@elvis (Sam Streeper) writes: No file on disk will ever be smaller than the sector (or perhaps cluster) size, even if it has very few "meaningful" bytes. Time for you to recheck the BSD fast file system internals, cause your statement does not hold. Could you explain? Wasn't he talking about internal fragmentation? Inquiring minds want to know. -Mike
scott@nic.gac.edu (Scott Hess) (05/06/91)
In article <aj7G3.u=1@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: In article <N67786.91May4013238@lehtori.cc.tut.fi> n67786@cc.tut.fi (Tero Nieminen) writes: In article <650@rosie.NeXT.COM> sstreep@elvis (Sam Streeper) writes: No file on disk will ever be smaller than the sector (or perhaps cluster) size, even if it has very few "meaningful" bytes. Time for you to recheck the BSD fast file system internals, cause your statement does not hold. Could you explain? Wasn't he talking about internal fragmentation? Inquiring minds want to know. You asked for it! Say that the cluster size is 8192 and the sector size is 512 (these are both the default for NeXT-shipped NeXTs I think - though they say they recommend 1024-byte sectors, I've yet to see one from them that says that :-). Then, the basic unit of allocation will be 8192, the cluster size. _But_ this means that, on average, we'd lose 4096 bytes per file. Since Unix has alot of files, this is obviously a problem. The simple solution is to make the cluster size smaller (say, 1024), so that there is less waste. The down side is that then you need more space for the block listings (that indicate the location of each block in the file), and the file system is slower. So, what was done for FFS was a comprimise. The block size can still be large, but they introduced the concept of a fragment, which would be some amount of space than a block in size, but an integral number of sectors. This could be used to represent the trailing partial block of a file. Also, multiple fragments could be placed in a single block, so the wasted space is no longer. In the case of a NeXT, you'll probably have a block size of 8192, and a sector size of 512, so fragments should be n*512 in size, where n goes from 1 to 15. Otherwise, in a 1024 byte sectored system, it will be n*1024, where n is 1-7. This all is limited to use on short files, I believe. Just implementing it for files <block size is generally good enough, because those are the most wasteful files (in relative terms). Also, many files on the NeXT (executables come to mind) are a multiple of 8192 in size because Mach likes to see integrally-paged files (pagesize is 8192). But, data files should get the right treatment . . . Flame away. This might be all wrong, but I suspect not - maybe some of the details are slightly off. I got most of my info from "Design and Implementation of 4.3BSD Unix", which is a good book to have on your coffee table . . . Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <I still speak for nobody> "Simply press Control-right-Shift while click-dragging the mouse . . ." "I smoke the nose Lucifer . . . Banana, banana."
wiml@milton.u.washington.edu (William Lewis) (05/06/91)
In article <1991May2.142103.6047@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >... ahem yes well all this talk about the size of binaries implies >that compiler writers are no longer concerned with space effeciency as >they used to be since internal memory is now cheap as dirt and >besides, you've got virtual memory so no problem right? Hmmmm... >still compilers should be more effecient about what they generate. Actually, if I understand things, the two switches that dropped things from 48k to ~2k ( -s and -object ) don't modify the code generation at all, just the packaging. In a standard Mach-Object file, for reasons of virtual memory efficiency probably, all segments are rounded to a multiple of 8k bytes. A stripped binary ( -s ) contains the text and data segments, for 16k after being rounded up. An unstripped binary includes debugging information, a symbol table, indexes to the original source code, and probably a copy of the Gnu Manifesto (why not, it gets into everything else) which bumps things up another 32k. But it's the same code running either way. -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "Just remember, wherever you go ... you're stuck there."
dnanian@uw.com (Dave Nanian) (05/06/91)
In article <SCOTT.91May5174536@nic.gac.edu> scott@nic.gac.edu (Scott Hess) writes: [text deleted] > Say that the cluster size is 8192 and the sector size is 512 (these > are both the default for NeXT-shipped NeXTs I think - though they > say they recommend 1024-byte sectors, I've yet to see one from > them that says that :-). Then, the basic unit of allocation > will be 8192, the cluster size. [text deleted] > Later, > -- > scott hess scott@gac.edu > Independent NeXT Developer GAC Undergrad > <I still speak for nobody> > "Simply press Control-right-Shift while click-dragging the mouse . . ." > "I smoke the nose Lucifer . . . Banana, banana." Not to get slightly off the subject, but the HP drive NeXT ships for the "660MB" drive doesn't seem to be able to be formatted with 1024-byte sectors, at least not with Rory Bolt's formatter_1.2 (up on Purdue). Something about the SCSI command not being supported. Is this just a matter of replacing a ROM, or are these HP drives really old? If you know what's going on, EMAIL and I'll summarize. Many thanks! --Dave Nanian, UnderWare, Inc. (dnanian@uw.com, uunet!uw!dnanian -- NeXT mail preferred)
cnh5730@maraba.tamu.edu (Charles Herrick) (05/07/91)
In article <1991May6.133912.3710@uw.com> dnanian@uw.com (Dave Nanian) writes:
From: dnanian@uw.com (Dave Nanian)
Newsgroups: comp.sys.next
Sender: dnanian@uw.com
Reply-To: dnanian@uw.com (Dave Nanian)
Organization: UnderWare, Inc.
Is everyone aware that UnderWare is the source of Brief, the ultimate,
most wonderful programming editor which runs on PC-compatibles?
Could it be that something as incredibly wonderful as Brief could be
ported to the NeXT?
--
"Battle not with monsters, lest ye become a monster,
and if you gaze into the abyss, the abyss gazes also into you."
-Friedrich Wilhelm Nietzschednanian@uw.com (Dave Nanian) (05/07/91)
In article <CNH5730.91May6152539@maraba.tamu.edu> cnh5730@maraba.tamu.edu (Charles Herrick) writes: > In article <1991May6.133912.3710@uw.com> dnanian@uw.com (Dave Nanian) writes: > From: dnanian@uw.com (Dave Nanian) > Newsgroups: comp.sys.next > Sender: dnanian@uw.com > Reply-To: dnanian@uw.com (Dave Nanian) > Organization: UnderWare, Inc. > > > Is everyone aware that UnderWare is the source of Brief, the ultimate, > most wonderful programming editor which runs on PC-compatibles? > > Could it be that something as incredibly wonderful as Brief could be > ported to the NeXT? > -- > "Battle not with monsters, lest ye become a monster, > and if you gaze into the abyss, the abyss gazes also into you." > -Friedrich Wilhelm Nietzsche That's us, all right. Not to disappoint, but we sold BRIEF late last summer so we could move on to new, hopefully cooler products (products that my lips are sealed about, except to say that we're not working on an editor [I had more than enough of that in BRIEF's 7 years with UnderWare], and it's for programmers -- and while we're writing it for the PC, I'm trying to parallel-port it to the NeXT). Anyway, thanks for the compliments re:BRIEF -- it was really a labor of love, and I'm really happy that people liked it! --Dave Nanian, UnderWare, Inc. (dnanian@uw.com, uunet!uw!dnanian, NeXT Mail preferred)
bb@math.ufl.edu (Brian Bartholomew) (05/07/91)
In article <CNH5730.91May6152539@maraba.tamu.edu> cnh5730@maraba.tamu.edu (Charles Herrick) writes: > Is everyone aware that UnderWare is the source of Brief, the ultimate, > most wonderful programming editor which runs on PC-compatibles? > Could it be that something as incredibly wonderful as Brief could be > ported to the NeXT? It's called "emacs", and it's bundled as standard system software. You can even get complete source code for free if you wish. -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
edwardm@hpcuhe.cup.hp.com (Edward McClanahan) (05/09/91)
> Compiler writers still have to worry about page faults, so the issue > is not entirely ignored. ...and cache misses ...and Virtual-to-Physical address translation cache misses ...and ...and ...and