On 12/27/03 10:38 AM, "Ben Goertzel" <[EMAIL PROTECTED]> wrote: > > Firstly, in practice, boosting the amount of RAM is not very easy on modern > computers. On a standard PC type architecture, the most RAM you can get -- so > far as I know -- is 32GB, which is on a Penguin 64-bit linux server based on > AMD Opteron chips. To go beyond that, you're into super-high-priced machines > sold by IBM and such, which are out of the range of nearly all (maybe all) AI > R&D groups. On the NOvamente project, we have been working within the 4GB > limit (that comes with 32-bit architecture), but will during early 2004 be > upgrading the software to 64-bit and running it on a machine with 16GB of RAM.
Absolutely, and this has been a major sticking point. Even the large ccNUMA machines, some of which can have around a TB of RAM, have sufficiently poor latency in that configuration that you lose most of the advantages of having really large single system image (SSI) systems. Clusters don't solve this problem, they only make it cheaper. I also am banking on purchasing a number of large memory Opteron systems this spring. The AMD Opteron is a major step forward in terms of dealing with the problem of memory scalability. Not only does it support very large physical memories (up to a Terabyte), but it also has fairly spectacular memory latency specs. This problem won't be solved until we see much faster, cheaper, and denser memory technologies. Hopefully things like MRAM will help deal with this. My target RAM size is in the 1-10 TB range, which means I'll probably just have to wait. In the mean time, the AMD Opteron systems are damn good stopgaps. > Similarly, to get processing speed beyond 2.5GHz or so, one has to move to a > distributed processing framework, which requires a whole lot of complexity and > mess (of a nature that's specialized based on the type of computing you're > doing). True, but not a real problem for me. I've been able to ascertain that when my software starts to crawl, it isn't the amount of CPU available but keeping the CPU fed with objects in memory. Or in other words, when execution performance starts to really drag, it is because the CPU is stalled on memory fetches because the data structures are inconveniently large. But yeah, distributed processing is the solution of last resort. For many kinds of spaces, it is not even worth the cost or effort. I've actually taken an interest in the Octiga Bay systems, which have a lot of promise from a scalability standpoint. Not SSI, but the fabric and computational resources are sufficiently fast that it makes a compelling argument as a quasi-distributed architecture. -- J. Andrew Rogers ([EMAIL PROTECTED]) ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
