aglew@crhc.uiuc.edu (Andy Glew) (10/24/90)
Occasionally this group discusses whether there is a need for computers with >32 bits of address space. I remember a few years back when people actually argued about this, although now it pretty much is the consensus that >32 bit, byte addressible, linear address, machines not only are needed, but they are also just around the corner[*]. Just to put a few more nails in the coffin, here is an excerpt from a misc.jobs.offered posting: >We are a publisher company , publishing 120 telefon catalogs for northern >german towns... > >The main objekt of development is software to maintain all data for telefon >catalogs includinding graphics, and programs to compute this data ready for >foto composing. So we are producing this catalogs fully electronically. >At the moment this projekt is the largest UNIX / ORACLE V 6 projekt in >europe.(600 tables;12 Gigabyte raw data;up to 150 transactions per minute). People already have databases that exceed 32 bits worth of address if memory mapped. It isn't even the largest banks anymore. Regional companies even, not multinationals. [*] byte addressible and linear address space may be somewhat debatable, but I don't want to get into that... -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
jpk@ingres.com (Jon Krueger) (10/25/90)
From article <AGLEW.90Oct23161224@bach.crhc.uiuc.edu>, by aglew@crhc.uiuc.edu (Andy Glew): > Occasionally this group discusses whether there is a need for > computers with >32 bits of address space.... > People already have databases that exceed 32 bits worth of address if > memory mapped. Just to play devil's advocate, why use the processor to address persistent, shared data objects? The processor is designed to address objects that live in volotile store, exist for the lifetime of a process, and are private to that process. The database engine is designed to address persistent, shared, objects. The database engine uses processors, but it doesn't depend on particular processor's address space. Well? -- Jon -- Jon Krueger, jpk@ingres.com
francis@cs.ua.oz.au (Francis Vaughan) (10/25/90)
In article <1990Oct25.011034.3664@ingres.Ingres.COM>, jpk@ingres.com (Jon Krueger) writes: |> From article <AGLEW.90Oct23161224@bach.crhc.uiuc.edu>, by aglew@crhc.uiuc.edu (Andy Glew): |> > Occasionally this group discusses whether there is a need for |> > computers with >32 bits of address space.... |> > People already have databases that exceed 32 bits worth of address if |> > memory mapped. |> |> Just to play devil's advocate, why use the processor to address |> persistent, shared data objects? The processor is designed to address |> objects that live in volotile store, exist for the lifetime of a |> process, and are private to that process. The database engine is |> designed to address persistent, shared, objects. The database engine |> uses processors, but it doesn't depend on particular processor's |> address space. |> |> Well? Funnily emough there are groups (well group) doing just this. The MONADS project at the University of Newcastle, Australia does basicly what you describe. 128 bits of object ID but mapped down to 32 bits for use by an off the shelf processor (SPARC in the machine currently being designed). Maybe someone from Newcastle would care to comment, I'm sure someone is reading. Note however that orthogonal persitence requires that ANY object may become persistent, the fact that an object comes into being in volatile store should not require special action on the part of the programmer to make it persistent. From the point of view of the execution engine there is no distinction between persistent and volatile data. Francis Vaughan.