Xref: utzoo comp.arch:17580 comp.databases:6724 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!sun-barr!newstop!sun!amdahl!JUTS!rbw00 From: rbw00@ccc.amdahl.com ( 213 Richard Wilmot) Newsgroups: comp.arch,comp.databases Subject: Re: Extremely Fast Filesystems Keywords: addressing,fractions,floating-point,caches Message-ID: Date: 7 Aug 90 22:38:28 GMT References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <13667@cbmvax.commodore.com> <13578@yunexus.YorkU.CA> Reply-To: rbw00@JUTS.ccc.amdahl.com ( 213 Richard Wilmot) Organization: Amdahl Corporation, Sunnyvale CA Lines: 58 davecb@yunexus.YorkU.CA (David Collier-Brown) wrote: > In article <30728@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes: > [in a discussion of Tannenbaum's Bullet fileserver] > | >This is very elegant, but there is > | >a problem. We're running out of address bits again. > ... stuff deleted > It's always a bad idea to put a hard addressing limit on things: > Intel, based on their past needs, octupled the addressable memory available > when they introduced the 8086, even though they expected 16k was adequate. > Experience has shown them wrong (;-)). They needed to increase it by a > somewhat larger factor [see, we're back to computer architecture again]. ... more deleted. >--dave Indeed. I began administering a database of 1,600 MB in 1974 for Kaiser Medical of Northern California. I think their membership has grown from the 1,000,000 active and 2,000,000 inactive of that time and Kaiser very likely keeps much more data about each member. This was done with an IBM 370/158 computer having 1 MB of main memory. All of the performance parameters of that hardware system can be easily exceeded by today's high-end PCs. I am certainly willig to bet that they've exceeded the 4,300 MB addressing limit of IBM's VSAM by now (for them there are ways around this). We always seem to exceed any addressing limit we can imagine. I still think it is time to stop trying to use integers for addressing. They always break down and probably always will. Many computers today have floating point units. I would like to see floating point used for addressing. It would help a great deal if addresses were not dense. What I have in mind is for data objects to have addresses but these would be floating point and between any two objects we could *always* fit another new object. In this way I could expand a file from a hundred bytes to a hundred gigabytes without changing the addresses of any stored objects. An index pointing to objects in such a file would never need to be adjusted as the file grew or shrank. Plastic addressing. This could still be efficient since addresses are almost never real anymore anyway. Addressing is used to locate things in high speed processor caches, in virtual memory, in virtual memory and on disk drives (and in disk controller caches). Integer addresssing is unsuited to all these different tasks. Fractional addressing could be flexible enough to allow for all these locational needs. Some things are nicely stored by hashing instead of by b*tree organization (e.g. person records by driver license number) (it minimizes update locking problems prevalent in b*trees as well as saving one or more extra levels of access. This is hard to do as a file grows but would be simple with a file addressed by fractions (0.5 is *logically* half way through the file). I think this was used by one of the graphics systems for describing picture objects (GKS?). So when will I see fractional addressing? -- Dick Wilmot | I declaim that Amdahl might disclaim any of my claims. (408) 746-6108