John said; > The moral of this anecdotage is that notionally "reasonable" maxima have > in our history always been outgrown much too soon.
True enough, but we have oscillated around a curve that is less than one additional bit of addressability every few years and because each bit represents a doubling in size, that curve has flattened dramatically, even though our overall usage continues to grow at a good clip. > Another obvious point to make is that this storage is virtual not real > storage. All of it need not be backed up, and what is backed up need not > even be connected (contiguous); It is possible to construct useful applications that sparsely use very large virtual storage areas as you yourself have done. Those are not a problem. There is not now and never has been a problem with allocating a large block of virtual storage. The problem only arises when you actually try to put data into it. At that point you have data and there are only two places it can be; in "real" memory, or on disk. In practice, neither of those places can currently store more than O(1*TiB) which is 2**40 bytes or roughly 1 sixteen-millionth of the capacity of a single address space. Call it at least 24 year's worth of room for growth if we could actually grow at a bit per year which we can't - at least not yet anyway. Not even the G-men are growing that fast because it costs real money to back virtual storage. > and still another perhaps not quite so > obvious one is that when four-byte addresses are inadequate, there are > compelling architectural reasons for moving to eight- and not five-, six-. > or seven-bye ones. I have no complaint with the clean-ness of the architecture. I happen to agree that 64-bits is the right answer. All I've done is put the numbers into perspective. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
