A sick idea - mmapped file output

[Michael Matz]

Hi,

On Thu, 2 Nov 2000, Zack Weinberg wrote:
> 
> However, you can anticipate running off the end and extend the file
> with ftruncate.  POSIX and SUS don't guarantee that this works, but
> assuming it does, this is indeed faster than write(2) - until you run
> out of mapping, at which point you have a problem.  Or, even cleverer,
> you can catch the signal and extend it then, but this doesn't seem to
> be any faster than anticipating the end (not surprising; signals ain't
> cheap).  

Hmm, although it's not really clear if there is a benefit in real
situations (like compiling a program with optimizations ;-) ), there is
also not a real reason why we shouldn't do it if we can (and the system
supports it).

all compiled with gcc 2.95.2 and -O2, all give identical files:

i386-linux
          usr     sys     wall
  stupid  686     60      1345
  clever  660     22      690
  signal  597     26      627

hppa2.0-hp-hpux10.20, slightly loaded server machine (4 CPUs)
          usr     sys     wall
  stupid  4242    73      4324
  clever  3162    364     9181
  signal  3095    225     9049

  note the high wall time, on a second machine (a development one):
          usr     sys     wall
  stupid  2509    23      2538
  clever  1882    29      1936
  signal  1848    18      1903

sparc-sun-solaris2.6, (a Ultra 4)
  in /var/tmp (a disc)
          usr     sys     wall
  stupid  800     44      934
  clever  661     46      737
  signal  598     56      1000

  in /tmp (the memfs)
          usr     sys     wall
  stupid  794     36      842
  clever  657     28      686
  signal  606     30      636

mips-sgi-irix6.5 (a 24 processor server)
          usr     sys     wall
  stupid  1172    96      1289
  clever  1179    88      1399
  signal  1068    85      1748


Ciao,
Michael.