From owner-freebsd-hackers  Tue Nov 12 02:21:27 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id CAA08737
          for hackers-outgoing; Tue, 12 Nov 1996 02:21:27 -0800 (PST)
Received: from pdx1.world.net (pdx1.world.net [192.243.32.18])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA08732
          for <hackers@freebsd.org>; Tue, 12 Nov 1996 02:21:17 -0800 (PST)
Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id CAA03492; Tue, 12 Nov 1996 02:20:50 -0800 (PST)
Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id VAA30753; Tue, 12 Nov 1996 21:20:07 +1100
From: Julian Assange <proff@suburbia.net>
Message-Id: <199611121020.VAA30753@suburbia.net>
Subject: predictor-clues [was ufs too slow?]
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Tue, 12 Nov 1996 21:20:06 +1100 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <7358.847790435@time.cdrom.com> from "Jordan K. Hubbard" at Nov 12, 96 01:20:35 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >  > Xfs is pretty fragile from what I've heard.
> > 
> > SGI's XFS is actually pretty robust. We run 16 and 32GB file
> > systems with it, and the performance is good. It can handle
> > an FS of some-number Terabytes. It is really a journal filesystem,
> 
> Actually, Matt Dillon over at BEST Internet talked about their
> experiences with XFS in a recent presentation, and his opinion of XFS
> was far from flattering.  In their experience, using XFS was a good
> way of crashing IRIX far too frequently for comfort.
> 
> 					Jordan

One thing that never ceases to annoy me about current opperating systems,
API's and compilers is the lack of support for predictor-clues.

File system layout could be hugely optimised if open had predictor-clues
such as "expected file size", "average read/write size",
"sequential/random access factor", "minimal time response" etc. 

I'm suprised no one has incorporated such predictor-clues for branch
optimisation in GCC. i.e this if has a 1/1,000,000 chance of actually being
taken (error condition). You can optimise this so that you can thread a
path of probabilities through the code, and (physically) move the
inprobable code away from the probable path. This would improve code
cache-hit rates so much it isn't funny. Recent Solaris cc/ld impliment a
poor-man's version of this path to physical association by examining
which functions are called by what functions and clustering the object
code accordingly.

-- 
"Of all tyrannies a tyranny sincerely  exercised for the good of its victims  
 may be the most  oppressive.  It may be better to live under  robber barons  
 than  under  omnipotent  moral busybodies,  The robber baron's  cruelty may  
 sometimes sleep,  his cupidity may at some point be satiated; but those who  
 torment us for own good  will torment us  without end,  for they do so with 
 the approval of their own conscience."    -   C.S. Lewis, _God in the Dock_ 
+---------------------+--------------------+----------------------------------+
|Julian Assange RSO   | PO Box 2031 BARKER | Secret Analytic Guy Union        |
|proff@suburbia.net   | VIC 3122 AUSTRALIA | finger for PGP key hash ID =     |
|proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D |
+---------------------+--------------------+----------------------------------+