Slashdot Mirror
Intel Says 10GHz By 2005
Techman writes: "After breaking the 1GHz barrier just this year, how long do you think it will take before we reach 5GHz? What about 10GHz? Intel is predicting that it will be sooner than you think. AnandTech has a look at the future of Intel manufacturing to see not only if the 0.13-micron Pentium 4 has a chance at success but also if Intel can make 10GHz processors a reality."
Moore's law predicted transistor density, not speed, and is only rather approximate. If you interpret it as speed doubling every 18 months (or quadrupling every 3 years), then based on the 2 MHz 8080 in 1974, we should now have half terahertz CPUs.
1974 2 Mhz
1977 8 Mhz
1980 32 Mhz
1983 128 Mhz
1986 512 Mhz
1989 2048 Mhz
1992 8192 Mhz
1995 32768 Mhz
1998 131072 Mhz
2001 524288 Mhz
Obviously that doesn't hold very well. If you want to do some kludged curve fitting based on Intel's history, here are some data points.
1986 16 MHz i386 DX
1989 25 MHz i486 DX
1993 66 MHz Pentium
1996 150 MHz Pentium Pro
1997 200 MHz Pentium II
1999 500 MHz Pentium III
2001 1500 MHz Pentium IV
The 1.5 MHz Pentium IV was an unusually large leap. In a kludged algorithm, you could interpret that as an accellerating pace, or as a leap that's likely to be followed by a lull. So really, it doesn't tell you much, except that Intel's prediction seems optimistic based solely on historical trends.
Okay, using Moore's revised law (an increase by a factor of 2 every 18 months), and the current speeds of about 1 Ghz, that gives us 4 Ghz by the end of 2003, 8 Ghz by the middle of 2004, and 16 Ghz by the end of 2006. Why should we be surprised that we'll hit 10 Ghz in 2005? Besides, given Intel's strategy with the P3 of getting mind numbing clock speeds without actually improving performance substantially, it should be even easier.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
// PaperClip.cpp
void ThreadFunc(void* p)
{
const int nBigMem = 4096000;
char foo[nBigMem] = { 0 };
while(true) {
memset((void*)foo, 42, nBigMem);
}
}
void PaperClip()
{
for(int i = 0; i CPU_Ghz; i++) {
begin_thread(ThreadFunc, 0);
}
}
Someone you trust is one of us.
BogoMIPS (Bogus MIPS) are usually little more than an integer multiple of the clock speed of the chip. The reason is that BogoMIPS is simply a timing loop. There are certain times when it's faster to simple do nops for a while than it is to switch to other useful work and back again. In order to get the delays as efficient as possible, linux computes how long a nop (No OPeration) takes, though in an expanded form. Since virtually all computers can executes nops at their full theoretical speed (i.e. popping out 1/cycle on every pipe), you get roughly an integer multiple of the clock speed. 2 pipes, you get 2x clock speed. Three pipes, 3x clock speed. Etc.
The reason for this is that a nop has no dependencies, so finishing it off requires no dependency checking or cache flushing. Predictive branching is absolutely minimal within the bogoMIPS algorithm from what I gather.
I don't know who gave you the idea that bogoMIPS are a useful indication of system or platform performance, but it simply isn't true. Real life code tends to be very complex with a lot of dependencies, so things like branch prediction and instruction reordering and such play more of a role in real system performance than simple MHz does, though in general there is a linear relationship between MHz and performance, given the same architecture. If you want more meaningful numbers, the SPEC numbers are reasonably good, but bear in mind the old saying, "Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics, Benchmarks, and Delivery dates."
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Running Microsoft Word can only take so much processing power, regardless of how complex your documents may be, so there's no real need for such a powerful processor in conventional application areas.
Wrong! You forgot about that goddamned paperclip. By 2005, Microsoft will have advanced its goddamned paperclip technology to the point where it speaks with the same accent as the customer. Additionally, the goddamned paperclip will have a 6500 polygon count. God be damned.
Imagine being able to speak normally with your computer as you would a secretary sitting next to you
Ok, I'm imagining...
"Wow, I love the way your tits bounce when you type! Wanna take some dic (2 second pause) tation."
I'd feel really odd talking to my box that way. Of course, those of you who weren't fired from your last job due to sexual harassment might have a different view...
and have your computer accurately and quickly take notes from your speech.
Imagine trying to do revision with a speech recognition package. It's completely unsuited to the draft-revision-draft-revision-ad infinitum process used for serious writing. Limited usefullness at best. A good secretary will rewrite your dictated memos and edit them for clarity. It'll take more than cpu horsepower to get a computer to produce readable english prose - it'll take major advances in AI.
Imagine logging onto your computer not via a user name and a password but by sitting in front of your display and having it scan your face to figure out if you are allowed access to the computer.
Scary thought:combine advanced AI with face recognition. "Hey fat boy, welcome back - you look like hell. No wonder you never get laid. I'll let you log in, but I really think you should be out excersizing."
Thought provoking stuff, but not really in the killer app realm. The demand for high end cpu's in 2005 will be driven by the same factors that drive it now - "My cpu is faster than yours" ego competitions and undersexed geeks with a desire to see rounder breasts in Tomb Raider.
--Shoeboy
Okak, I'm sick of people posting useless one liners that mention clusters. There were 2 in the first 20 posts on this story; that's pretty bad.
When a read a story on how "Vibucomp now offers computers that come with vibrators" (no pun intended), I don't need to read posts that say, "Wow, if I had a Beowulf cluster of those, imagine how many vibrators I'd have! I don't even have that many orifices!"
It shouldn't be too hard to introduce some sort of auto-moderation scheme that automatically -1's all cluster-mentioning posts to not-cluster-mentioning stories.
Actually, the speed of light in a material is 1/sqrt(permittivity * permeability), with relative permittivity and permeability both equal to 1 (free space), the speed of light (and hence the electric field) is equal to approximately 3e8 m/s. But in semiconductors on a chip, a closer approximation is 1.5e8 m/s, or half the speed of light. So, given your math, 1.5cm, divided by 2.54 for inches, and that's ~0.591 inches. That's almost so small that by the time the electric field of the clock pulse ripples across the chip the next one's already started elsewhere.
I think IBM or somebody has started doing segments of chips in synchronous sections, linked somewhat asynchronously, or at least each using independent clock pulses, to better approximate synchronized switching.
See "Numerical Technologies" web page (www.numeritech.com). They've got technology which allows semiconductor manufacturers to use phase shifts to do optical lithography beyond the limits of what the wavelength of the light used would normally allow.
This only addresses the construction of such beasties, of course - the various companies still need a lot of tool development to deal with the "weird ass quantum things".