Comment Bus Speed and the like (Score 2) 136
Yes! Bus speed is an issue, but the solution is non-trivial. Those lines on your motherboard have electrical characteristics, based on length and frequency. Simply put, they become radio-transmitters! Even the layout rules for the 100Mhz/133Mhz buses are tight.
Inside the chip, it's a lot easier to push frequency because your lengths are *very* short. Thus, it's likely that there will be consumer-level 1Ghz CPUs next year or so. But the bus speed is still down near 100Mhz (even if you try tricks like double pumping it).
One solution to this problem is to put more on the same chip. These systems on a chip have been created less than happily before, as you lose most upgradeability, *but* you get to use whatever bus speeds you want internally. You also save a few bucks, and a few inches.
If I had to guess (and my crystal ball is down for the RH 6.1 Upgrade
Remember, though, that if your code fits in cache and takes advance of new hints for caching present in the K7/P3, you might not even notice the faster bus speed.
My wish for improving computer performance would not be a faster bus, faster clock speeds - it would be software:
An excellent optimizing compiler!
(And, a Linux port of Intel's VTune would be fairly sweet too).
(I haven't checked lately, but last I looked there was nothing that would generate code that took advantage of P6 instructions, despite conditional moves that would eliminate many branches and give a noticeable speed boost). Here's a nice little advocacy experiment for those so inclined.. Compare the output of VC6.0 under NT (running console), versus latest Cygnus build of GCC with various algorithms, Sieve of E, etc.