Slashdot Mirror
Intel Looks to Billion-Transistor Processors
Weedstock writes: "EE Times has an article about Intel's next decade roadmap. It explains what are the current issues with the actual "plastic bumped organic land grid array" packaging technology and how it will be modified into a "bumpless package with built-up layers" to accomodate billion-transistor processors."
Hopefully people will be putting all of this power to good use. I wonder if C programming will become as rare as assembler programming is today?
http://www.anandtech.com/showdoc.html?i=1542 If the URL is bad. Go to www.anandtech.com, CPU on the right side, and look under recent articles for the BBUL story.
I was interested by the fact that the article indicates that chip speed is about to reach a bottleneck with the array package. Of course, as with all things, everything needs to be upgraded in step in order to reap the benefits.
The thing that i'm curious about is whether or not these changes in chip packaging will result in a disorganized series of changes in chip/board interface standards. socket 7, slot a, socket 370, etc.
Will the various companies(most notably intel and AMD) all be independently trying to solve the same problem in different ways? And will this mean that not only will we have rapid interface generations within the same company but that we will have to deal with even further incompatability between chips of competing companies?
-
lysergically yours
1THz processors are nice and all, but what about the necessary advancements in motherboard bus technology to match? I mean, you can have as fast a car you want, you get it to a track and flatten it's tires, it's not going to go very far. Personally, I would like to see a better partnership of chipset manufacturers and processor manufacturers to make sure that the rise of processor speeds is proportionate to the rise of chipset speeds.
A billion here, a billion there, sooner or later you're talking about a really, really hot piece of silicon.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
Your post really demostrates that your are ignorant of what you're posting about.
AMD is not copying Intel's IP. If they were, Intel would be winning the suits against AMD, not losing them as they have been. AMD has reverse-engineered the x86 instruction set that has been around for quite some time, but implemented in silicon differently. The end result is greater performance, as evidenced by any benchmark you care to run. Like it or not, the fastest x86 processor on the planet right now, even according to Intel's own benchmark suite, is the Athlon XP 2000+.
And to further add insult to your injury, AMD doesn't stand for "American Micro Devices", it stands for Advanced Micro Devices. If you'd done the slightest bit of reading, researching, or thinking before you posted your previous comment, you'd know that.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
That's nothing. I left my house right here before I went to the bar, and now it's missing. Does anybody know who moved my house?
If tits were wings it'd be flying around.
What about the IBM/Motorolla PowerPC chips? American made, and more efficient per cycle than Intel's chips (except for maybe the Itanium).
And you tout Intel for get thermal protection working?! Howabout some chips that don't need thermal protection (like the recent iMacs which can cool themselves with ONLY air convection [meaning no fans for you lesser literates])?
Next thing you know, you'll be crowing about MS's innovation of the GUI over Xerox's... ah.... GUI?!
Vote monkeys into Congress. They are cheaper and more trustworthy.
But we are nowhere near that limit.
What we've all been waiting for...a gigazistor! Enjoy it while you can. No doubt, sooner or later, the LinguisticallyCorrectNazis from Academia will change the name to gibizistor.
cat
This was more or less just a summary article. You had to be somewhat familiar with a number of announcements Intel made over the last year to get any sense of importance out of this.
Bumped to bumpless is important because the solder balls were starting to dominate layout and packaging considerations.
Having better lithography processes and smaller traces is important because even though everyone expects them to continue to improve, someone still has to discover the technology required to do so first.
The new gate oxide has been shown off and does exist. It's only really improvement is for current leakage so it's not stop the world kind of news. Cost per wafer and manufacturability with existing machinery are the real things to worry about.
This is a different SOI approach than previous chipmakers have been using. They're also doing variations of xOI whereas other approaches use a standard silicon substrate.
The whole slashdot crew needs to learn more than just technology before posting articles.
Maybe I'm wrong, and if I am, I'll just crawl back in to my hole and shut up.
But the article claims that the new technology will allow them to *embed* the
processor(s) inside the casing material, unlike today where the core actually
sticks out above the packaging.
But the advantage, as I see it, to having the core *above* the packaging, is
that heatsinks, thermal grease, etc... all have direct (or extremely close
to direct) contact with the core - which is what generates the heat. Mabye
in reducing voltage, heat output will drop significantly, but I digress.
With the core embedded in the casing, it would seem hard to help cool the core
when a heatsink doesn't have direct contact.
I may be wrong, and in that case just ignore this comment, but I don't know
how Intel would plan on dealing with that as a problem (if it in fact is one).
Just as C programming made a 12-MHz 80286 almost as powerful as a 4-MHz Z-80 programmed in hand-tuned assembly language, the multiply abstract and fantastically elegant languages of the future will make those terahertz machines almost as powerful for real work as a TRS-80 Model 1 programmed in Level II BASIC.
Brackets contain world's first nanosig, highly magnified:[.]
Does this mean faster pr0n?!
Mod me down, fine with me, it's my real karma I try to keep up.
Firstly they did mention reducing gate leakage current by a factor of 3 i believe which means the chip will produce a lot less heat.
As for embedding the core in the packaging - it's probably a great bonus. As has been pointed out this means that the top of your chip will be completely flush so you'll hopefully get better thermal transfer since you have a bigger surface area.
On a current intel chip the space between the packaging and the heatsink is currently acting as an insulator (since air does that best when it's not moving).
In addition to this, I would speculate that if the core is embedded into the packaging it might allow for small heat pipes to run directly into the core, allowing particularly hot areas of the chip to have additional passive cooling.
That said, given fabrication facilities i'd struggle to make even a single pnp transistor and whilst i could probably remember how to build simple mos (and hence cmos) gates - i'd struggle to replicate what intel was doing in the 70s... so dont take me as any sort of authority on this one.
You need to look at what's driving processor design these days. It isn't word processing and spreadsheets, that's for sure. There are only four areas that I can think of that are really driving the desire for more and more transistors:
#1 - Larger memory sizes. Terabyte databases require terabytes of RAM. Current 32-bit processors can't touch that with a 10-bit pole. Even the most elegant 4- and 8-bit processors can't do anything about their memory addressing limitations without huge kludges.
#2 - Engineering/Scientific problems. Ever try to model the fluid/thermal dynamics of a star? You need ungodly amounts of processor power to do this properly, or ungodly numbers of processors. Preferrably both.
#3 - 3D multimedia and design. This is my area of work. I've got five (count 'em, five) dual Athlons right this moment rendering like mad, churning through a 1 hour 3D animated sequence with lots of volumetric lights, NURBS, and tons of polygons. 3D eats cycles like they're going out of style, and in my business if you can cut your render time in half, you've just doubled your production capability. You can never buy enough render power.
#4 - Gaming. Yes, games. Doom. Quake. Doom II. Quake 2. Quake 3. Unreal Tournament. Every game pushes the triangle count, texture resolution, and framerate to higher highs. Photorealism is the holy grail, and it's going to take absurd amounts of transistors running at an unheard of clockrate to do this.
You'll note that business apps are anywhere in there, and they shouldn't be. Your average desktop processor spends about 99% of its time idle waiting on the operator between keystrokes. Nobody needs a 2Ghz P4 or a 1.6Ghz Athlon for these tasks, despite Intel's propaganda to the contrary.
I know you long for fast, tight code, but that isn't being taught in college anymore (heck, it wasn't even when I went through in 1990). Profs are encouraging rapid design and quick-to-market code over elegant design. It's unfortunate, but the market itself is rewarding this philosophy. I don't agree with it, but the fact is that the company that produces a "good enough" piece of software quickly will generally steamroller a company that produces "elegant" software but comes out later.
After all, beta means alpha, and 1.0 is really an extended beta. Kick it out the door, the marketing campaign is scheduled to start! Who cares if it works, we can always patch it later or put the bugfixes in version 2.0!
Oh, and I strongly disagree with your assessment of Lord of the Rings. I found it a very good adaptation of such a sprawling book. What did you dislike about it so much that you descend to profanity to describe it?
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
That is what I kinda (badly, maybe?) said. That this was a PR piece through and through, with only a glimmer of technobably to give it credence.
Yet somehow, I managed to get OVER_RATED in a previous post for saying the same thing?
Vote monkeys into Congress. They are cheaper and more trustworthy.
We decided we wanted to do more with our computers. It's all very well to long for the days of very clever, small and fast programs but it's entirely another thing to create software which does all the things we have come to expect today while still keeping the software incredibly small and fast. It's even harder when you want to stay within a tight schedule and budget.
Lets look at something near and dear to our hearts, something that many of us here have contributed to and something that isn't affected by budgets or timelines (well, mostly) - the Linux kernel. The Linux kernel is undoubtably a very good piece of software development, arguably the best that's currently available and it has been created by a wide range of people many of who come from the days when RAM and CPU time was expensive. Despite this, the linux kernel is certainly not small, and it shouldn't be. It has a wide range of devices to support, it has to be able to handle multiple users simultaneously and it provides a bunch of services that previously would never have been provided in an OS, let alone in a kernel.
It could be argued that the Linux kernel is clever, and with my lack of knowledge of the kernel source I can't really comment. I think it is safe to assume that it's not as clever as it could be though - it doesn't use every trick in the book to reduce file size and increase efficiency because it's no longer small enough to make that kind of thing feasible. It's also modularised so that things can be loaded and unloaded as needed, there's extra code and overhead required to provide that. Finally, it supports a range of architectures now and is more portable. Going back to the old ways of doing things gives up all those benefits.
Finally, the linux kernel is not fast - it is comparably fast for all the things it does, but it is not as fast on a per-cycle basis as OS's were back when every cycle mattered. It does however provide more features (like loadable modules), more portability and a faster release schedule for fewer man hours.
So when you really sit down and think about it, while programs these days take up more RAM and CPU power there are a range of benefits that come from this. You should also note that comparatively the overall experience of using a computer has become radically faster then it previously used to. You may think that a program feels slow when you run it on a 3 year old machine, but what you fail to realise is that you've just gotten used to how much faster your new machine is. Having said that, some software is just plain crap, but so are some cars and bridges so the bad apples don't just come from software engineering.
Why should the processor have to predict the next mess of instructions, load them into a cache, find out it predicted incorrectly, dump the cache, find the correct location, load the instructions...
Incredibly poor chip design actually. This problem really only becomes significant when pipelines are made too long (such as in the P4). The pipelines are extended to make it possible to use a higher Mhz rating - though because of the extended pipeline and the problems caused by having to guess ahead so far the CPU doesn't actually function anywhere near as fast as the Mhz would indicate it should. This is why people talk about the Megahertz Myth - there's a ton of information on it around the web.
Why are processors marketed by their internal clock speed when they spend most of their time waiting for data?
Because consumers don't understand computers well enough to know this and Mhz has been used as a rating mechanism for so long (and previously it had been reasonably accurate). Marketers will jump at any opportunity to make their product sound better than the competition.
And above all, why does software suck so badly?
It doesn't. There is and always has been poorly written software but to say that all software sucks is unjustified. There are cars that break down due to manufacturing defects, bridges that collapse, constructions which go over time and budget and a myriad of failures from all types of engineering so of course not all software is perfect but it is improving whether or not you like the way it is improving is another matter.
Thought for today: why do HTDV receivers cost so much? A GeForce 3 board has 35 million transistors in the CPU, 64MB of RAM, and costs under $200 at retail. The radio part of a cell phone, which is more elaborate than the radio receiver for HDTV, has a parts cost of about $10. $600 will buy a pretty good computer, monitor and all. Why do HDTV receivers cost upwards of $500 without a display device?
Another item on your list can be carrier grade communication systems. Do you think the next generation of networking systems are going to be provided by a bunch of parallel 8 bit processors? Hell no. In order to move several terabits of data at crazy speeds we're going to need really fast switching technology to do it. Yet another is post production work. After you render all of your CG sequences somebody else with their ungodly number of processors computer edits it all together into a final product. The faster the processor is and the more memory it has the faster you can composite your video and audio and polish it up.
I'm a loner Dottie, a Rebel.
How is it the biggest semiconductor manufacturer in the solar system is on its last legs?
I'm a loner Dottie, a Rebel.
What about the IBM/Motorolla PowerPC chips? American made, and more efficient per cycle than Intel's chips (except for maybe the Itanium).
I don't think "American Made" is a significant point when deciding on a processor...
Where does one get ATX-format boards and processors to be able to build these ultra-quiet, ultra-fast marvels? (Seriously - I like quiet PCs, but I don't much like Macs, so that would be a nice LinuxPPC box, potentially).
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
Actually, pipelines aren't made longer to get higher MHz rating only, but to increase throughput [in optimal case]. Current crop of CPUs do more per clock than older ones (well, not counting P4, usually). You can nowadays add more than two numbers in one clock cycle and possibly do additinal multiplication in the same time. Even P4 should be really fast if all you do is basic operations without loops. P4 has 3+GHz ALU unit for this! Unfortunately, we really don't need that much computing power but logic power partly because we have additional processors on our sound and graphics cards where the computing power really counts. If you really need to emulate DSP in software, then P4 is what you need, otherwise deep pipeline is going to hurt badly.
Perhaps it's just you didn't expect that much from computers a couple of years ago. I remember using 75MHz Pentium with sucky graphics adapter for not too many years ago and it felt plenty fast. I'd hate to have to use that kind of crap anymore - no matter what software I used. And that's because I know about better.
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
Depends on your application. Bandwidth is certainly one limitation, but there is plenty of stuff that is still processor bound.
For example, if your processor was fast enough you could do accurate physics modelling in real-time. The amount of data is quite small (not memory bound) but the number of equations you have to solve are enormous.
This would be fantastic for 3D games - objects would behave like like do in the real world rather then being forced to follow strict animated sequences. You could model chains, pulleys, swaying bridges, tumbling crates, bouncing balls, ramps etc.
Thanks to the GeForce and other high-end graphics cards we have the power to render scenes with this level of complexity, it's just a shame that we don't yet have the processor horsepower to accurately model them.