On 1/3/03 11:12 PM, "Gary Miller" <[EMAIL PROTECTED]> wrote: > If these benchmarks were more readily available it would be even more > apparent to businesses and users that a 3Ghz machine will not process a > typical application twice as fast as a 1.5Ghz machine.
If you actually look critically at the various system performance parameters, you find that system performance these days is scaling almost perfectly with memory performance. While memory performance and processor speed track each other only very roughly, you find that system performance on many benchmarks and memory performance track almost perfectly. There is a strong implication that for many types of applications these days, memory performance IS the system performance "rate limiting factor". The only reason faster processors seem faster is that GHz upgrades frequently come with memory performance upgrades as well. This is also why people who do scientific computing often use the STREAM benchmarks (which measure system memory performance) to compare systems when building a supercomputing cluster. STREAM metrics map more closely to real world performance than running a tight code loop in the cache to measure CPU performance. > How many of you out there with AGI projects feel you are limited > currently in your research by CPU speeds. I was myself up until 2 years > ago. If you do feel you are limited, what speeds are you currently > running at and how much more CPU (2x, 4x, 8x, ...) do you feel you could > optimally utilize. We don't feel particularly CPU limited, but we do feel memory limited, both in terms of how much we can have and how fast the CPU can access it. In fact, it would almost be more acceptable performance-wise to have a cluster of relatively slow processors that can access their (much smaller) memory spaces very fast than to have blinding fast processors with huge address spaces that may take a second or more to traverse in practice. We just don't need that much raw CPU to get the job done. The entirety of our number crunching is integer domain, and just addition/subtraction at that. Aside: Since the engine operates on relative values and the dynamic range of integers on your average machine is quite high (higher than anything going on in the human brain), there is no reason to NOT use integer formats, particularly since integer math and manipulation is very fast on most common hardware. You don't need to materialize floating point values from relative integer values to get perfectly correct statistical behaviors, a point that most people overlook (or perhaps their particular design architecture forces them to do things this way -- hell if I know). But yeah, give me fast memory access and lots of it, and I'm happy. Ironically, most systems made today that really do have good memory architectures also tend to be highly optimized for floating point performance at the expense of integer performance. > And how much do you feel this would compress the actual project plan for > your project. These numbers should give a better indication on whether > and how much current processing speeds are limiting the quest for AGI. The problem today is almost entirely a software problem. The hardware problems and limitations, such as they are, are resolving themselves just fine. The software on the other hand... -James Rogers [EMAIL PROTECTED] ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?[EMAIL PROTECTED]
