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."
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.
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
The funny thing is that people thought the chips would get cooler when the gate sizes got smaller. Obviously this is not happening. But the thing is this - if the package is getting bumpless, the real challenge is getting the power through the package and onto the power mesh of the chip. Plus, will the new package substrates thermally match to the system boards they will be attached to? By the time Intel intends to have sub 50nm line widths, the die power is supposed to approach something close to your garden variety NUCLEAR REACTOR.
Then you have the issue of signal integrity, particularly for high-speed analog and differential pair signals, which smaller traces only aggravate. The most advanced flip chip packages in the world currently push around 2000 connections for power and signals. This will only get more aggravated and congested at the board and package level as the level of integration increases due to the feature size decreases on the silicon. Small lines increase impedances, and merely cutting layers away will NOT help. Differential signals are supposed to be pushing 40Gb/s per pair in a year or so using modulation on top of differential signaling, so what are they expecting that these packages will be supporting when they have such strict routing requirements both in the signal and redistribution layer routing AND through the package? Not to mention the fact that they still have to attach these monsters using a substitute to lead solder to avoid alpha particles causing false switching in already small noise margins.
Instead, you need different package materials than simple organic laminate subtrate and different silicon process materials than silicon dioxide and tungsten vias. When it gets to this, they have to rely on material science, which is the gating factor in a lot of science right now. I don't believe that Intel's core competency includes material science per se, so they'll be relying on outside companies and research labs for a good chunk of the new materials. Since this is out of their direct control, I don't see how they can deterministically schedule their packaging roadmap - not without forming clear strategic alliances with companies whose core competencies lie in material science related to the above-listed materials. I wish them all the luck and blessings in getting there though.
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.