> From: David Seifert <seifert@sequent.com>
>
> >> On port-mac68k, I've seen people with 8 MB systems boot fine
> >> (although that's a 32-bit system).
> >
> > NetBSD/vax can run nicely on a 2MB machine :-)
>
> I have a ns32k box that can run a BSD-based OS in 0.75 MB.
> It runs okay in 1 MB and nicely in 3.
>
> I have another ns32k box that runs NetBSD in 4MB and
> nicely in 16.
>
> My alphas page and swap like crazy with 32MB.  If we believe
> ps(1) output, alpha binaries need 10x the memory that ns32k
> does (both running NetBSD).  I routinely see rn(1) with a VSS of
> 50MB!!! (rn-classic, not the X11 version)
>
> Now I know that ns32k is one of the most efficient architectures,
> that the alpha is RISC and 64 bits and has a larger page size, but
> 10 times as large???  Something seems wrong here?
>
> Anyone know why the alpha is such a memory pig?
>

Hmm, 1575 email messages after only a 3-day weekend vacation.  
   
But this one is the easiest to deal with. Besides working on the alpha
(as you all know) I was with the group at National that built the first
NS32K compilers and systems. I can actually explain this!
 
Yes, the NS32 takes the all-time code-density prize, at least among 32
bit architectures. But that is not what you are seeing. What you are seeing
is:
 
        The ps(1) listings you are comparing are measuring two completely
	different things...

	I don't think your old NS32K BSD system did shared libraries, so
	each image has a static mapping of just the program and the library
	functions it actually needed to link.

	NetBSD/alpha executables directly execve(2) very little, the program
	and all libraries it uses are mmap(2)'ed in.  Consequently, any
	_one_ executable will _appear_ to use vastly more memory, but the
	RAM size of the program and the system as a whole will be reasonable.
	It's even possible (because of the shared libraries) to make a test
	case that uses a lot _more_ memory on your static NS32 system than
	NetBSD/alpha...believe it or not!


Also, the alpha isn't a memory pig at all. Yes, the NS32 had little 512-byte
pages, so the VM overhead was miniscule, and the instruction set code density
was nothing short of amazing.

But we can boot and run real stuff in 16 MB, and that's after giving away
2 MB to the console, as was noted. And that's running GENERIC.

I was able to get to a multi-user login prompt with a grand total of only
8MB installed, although I never actually got a shell prompt. With a little
tweaking, I bet we could get logged in on an 8 MB (6 MB after SRM!) system.
(Oh, and cgd's recollection of my test results--16MB--wasn't really wrong...I
initially reported it incorrectly...thinking I had run the test with more
RAM than I had.)

Junk fax from last week quotes the following memory prices: (McDonald
and Associates) 72-pin Parity: 16/32/64MB for $21/38/135. SDRAM: 32/64/128MB
for $31/75/143. "100MHz Intel certifed": $42/88/180. So, clearly, the
relatively small amount of extra memory required by the Alpha's bigger
pages and SRM console are reasonable. And our instruction set code density
should be exactly the same as any other RISC processor, and data sizes only
a bit bigger due to the 64-pointers and longs.