Return to BSD News archive
Xref: sserve comp.os.minix:22401 comp.os.386bsd.misc:537 comp.os.386bsd.questions:3405 comp.os.linux:45796 Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!olivea!uunet!pipex!uknet!yorkohm!minster!forsyth From: forsyth@minster.york.ac.uk Newsgroups: comp.os.minix,comp.os.386bsd.misc,comp.os.386bsd.questions,comp.os.linux Subject: Re: Choosing a Unix like OS for a pc (plan 9 compilation time) Message-ID: <741438841.9926@minster.york.ac.uk> Date: 30 Jun 1993 11:14:01 GMT References: <C8wC29.9qq@world.std.com> <201f9p$kkv@klaava.Helsinki.FI> <203s5k$j9u@urmel.informatik.rwth-aachen.de> <C9E4J4.Fsw.1@cs.cmu.edu> <FOX.93Jun29142638@graphics.cs.nyu.edu> Organization: Department of Computer Science, University of York, England Lines: 44 i don't know how long it takes on a laptop, but here's what i've got: cpu% cd /sys/src/9/pc cpu% NPROC=4 time mk 'CONF=pccpu' >/dev/null 83.80u 28.65s 130.35r mk CONF=pccpu that rebuilt a 386/486 CPU kernel from scratch, on a no-name 16Mb 486dx2/66 ISA [256k direct mapped WB cache], connected by ethernet to a 16Mb 486sx/33 ISA file server. ethernet is fairly slow; that's why it took nearly 20 seconds longer than perhaps it ought to have done. four instances of the C compiler 8c were running concurrently, using at most about 30% of the available memory in all (ie, there was no paging or swapping). rather more memory is used by the linker 8l during the final link stage, though. the system wasn't single user, but it wasn't very busy. the CPU kernel i compiled includes most devices, including /dev/bitblt, five ethernet drivers, and several SCSI drivers. of course, in practice, when developing (say) new device drivers, building a kernel doesn't take anything like that long, since only the changed bits need to be recompiled, and the kernel relinked. it typically takes about 20 seconds (the linker takes most of that time, and would take less with a faster file server link). being smaller (highly specialised) the PC file server kernel takes less than a minute to compile from scratch. compared to gcc, 8c does a reasonable job on the 386 for the sort of code i compile (non-numerical), but is much faster. 8c does a better job than lcc could do, and is slightly faster since it includes a C preprocessor subset and compiles to binary. regarding Christopher Maeda's point, the secret is in which half of the supposed `functionality' you choose to leave out. (for the system as whole, start with X11.) when people actually use the Oberon environment or Plan 9 they often find that to get real work done they neither need nor value a lot of the crud others regard as necessary.