From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd3b8571c28b75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-23 19:56:14 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!washdc3-snh1.gtei.net!news.gtei.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!wn11feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3F4828D9.8050700@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software References: <3F44BC65.4020203@noplace.com><20030822005323.2ff66948.david@realityrift.com> <20030822020403.625ffbf5.david@realityrift.com> <3F4657AD.1040908@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc51.ops.asp.att.net 1061693671 24.34.139.183 (Sun, 24 Aug 2003 02:54:31 GMT) NNTP-Posting-Date: Sun, 24 Aug 2003 02:54:31 GMT Organization: Comcast Online Date: Sun, 24 Aug 2003 02:54:31 GMT Xref: archiver1.google.com comp.lang.ada:41821 Date: 2003-08-24T02:54:31+00:00 List-Id: Alexander Kopilovitch wrote: > No, there is no need to fetch bunches of memory - compiler will tell (perhaps > through OS directives) the memory chip suitable value of "base" and it's enough > - we went through that long ago. Naturally, that will be less efficient than > we currently associate with "real" (that is, non-virtual) memory - the switches > of the "base" will take time, but it will be more efficient than disk I/O. I guess this is not an Ada issue yet, but it will be. ;-) Remember that when Ada first came out, there was no agreement that Integer should be 32-bits, not 16-bits. Of course, the only real effect on machines that support both 16-bit and 32-bit Integer types is on the size of Strings. Within a few years, as expected, almost all implementations had moved to 32-bit Integers. (Almost all, because of 24 and 36-bit implementations. ;-) For a financial package is 4 Gigabytes of addressable memory enough? (Two Gigabytes currently under Windows.) Some people are running up against that limit with spreadsheets, and most large database servers use machines with 64-bit address space support. Note that with current large databases a 32-bit address space is insufficient to manage the indexes and tables that are (virtual) memory resident. (Advertisement -- The next paragraph is in some sense a shameless plug for the new Opteron from AMD, and for the Athlon64 and Athlon64 FX that will be released next month.) AMD is now selling processors where the architecture supports up to 64-bit addresses. The virtual memory system supports 40-bits of addressable memory per processor, and the virtual memory system supports up to a 48-bit address space. (But unless you are putting together a system with over 1000 processors, those later numbers are details. The Red Storm machine which may soon be the worlds fastest supercomputer will have over 10,000 Opteron processors, and I am sure they are working the global addressing issue.) So not only can you now buy machines off the shelf that can directly address almost a petabyte of data, some organizations are buying them... But what I wanted to point out about the AMD64 architecture here is that with a 64-bit aware OS, modules written in (x86) compatibility mode can call dynamically linked libraries that are written in long mode. So a "database" module could address hundreds of Gigabytes of memory directly, while the application for the most part uses 32-bit addressing. Compared to a file system call which will take thousands to millions of clock cycles, an in memory database can probably be accessed in under a hundred clock cycles. That is a noticeable performance improvement. Apple has also recently started shipping 64-bit machines based on the new PowerPC chip from IBM. And if you are into masochism, there is Intel's Itanium2. (Speaking only as a compiler developer, of course. ;-) So in a few years, almost all server hardware should allow users to avoid the file system and address enough memory for most accounting systems and databases. Of course, someone will then invent a use for all that memory... -- Robert I. Eachus "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh