Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!lll-winken!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: Real disk FASTER than Ram disk
Message-ID: <5574@titcce.cc.titech.ac.jp>
Date: 10 Jun 90 04:44:21 GMT
References: <641@sibyl.eleceng.ua.OZ> <136299@sun.Eng.Sun.COM> <1990May27.210935.8564@murdoch.acc.Virginia.EDU> <3402@auspex.auspex.com> <60196@lll-winken.LLNL.GOV> <5490@titcce.cc.titech.ac.jp> <431@garth.UUCP>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 33

In article <431@garth.UUCP> fouts@bozeman.ingr.com (Martin Fouts) writes:

>Excuse me for disagreeing, but replacing /tmp with a file system that
>gets paged isn't a good solution.  What you are doing here is working
>around the lack of advance in the underlying software.  The compiler
>is still writing to /tmp because it isn't managing its own address
>space effectively in a virtual memory environment.

Compiler is using intermediate files, mostly because its development
is much easier by separating the compilation process into multiple phases.

Correctness is much important than compilation speed.

>Direct mapping
>files into the compiler address space and paging from that is much
>more effective than using a second order paging for a "file system"
>ala /tmp.

No. On UNIX, when delayed write is used, memory access is not so much
faster than IO.

Moreover, according to your policy, compilers shouldn't produce intermediate
file even into its address space. Just compile in a single phase.

BTW, using memory instead of disk files is real memroy ineffecient way.
IO is IO and has its own property. For example, most IO is done with
sequential access pattern and dose not require so much real memory
for buffering. On the other hand, most memory access is done with
LRU access pattern and allocating much real memory will improve
performance. But, overly mixed IO and swap will fail to utilize
such special properties of IO.

						Masataka Ohta