Newsgroups: comp.sys.next Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!jashley@tope.cs.indiana.edu From: J. Michael Ashley Subject: Re: Small executables (was Re: 16mb minimum for next machines) Message-ID: <1991May2.100633.12905@news.cs.indiana.edu> Organization: Computer Science, Indiana University, Bloomington. References: <1991May1.062022.1056@nntp-server.caltech.edu> <1991May2.142103.6047@potomac.ads.com> Date: Thu, 2 May 91 10:06:12 EST 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