0
). I was still thinking that on-die memory controllers were a must for Intel and I have to admit to how naive my questions sounded but cut me some slack, please. 
As the last couple of years have shown, this guy seemed to know exactly what was gonna happen. Just a fun little look back that I thought you guys might enjoy.banj0 said:
I also understand your point about the on-die memory controller. Obviously, it is easier for the mobo manu's to rev the northbridge for ddr2 and ddr3. It just seems strange to me that a semiconductor company the size of Intel wouldn't have had the wherewithall to integrate a memory controller for ddr2
They certainly could do it, but the issue is the cost of doing so versus the benefit. From the cost side you are looking at lower yield (defects increase as the square of die area), different package, different mobo socket/pinout, different heat solutions., etc. If you are going to do it, it makes sense to do it on the entire line.
What are the benefits? Better performance - but how much? The answer... it depends. The on board memory controllers main benefit is latency. Offboard memory controllers can do just as well (and a lot do better) in terms of throughput.
If your applications are heavy on random type memory access that aren't amenable to things like prefetching then you could see a huge boost from the decreased latency of a on die controller.
If your applications are easily prefetchabe, well localized, or involve large transfers of data in contiguous memory areas the latency may be almost irrelevant and you will care much more about throughput.
Quote
After all, when the Iatinic was released, ddr2 was a ways away. DDR3 is great for video cards but is still a year away from what I hear.
The Itanic (what was Merced) couldn't have put a memory controller on die in their wildest dreams. It had already had to go through a process shrink just to fit a reticle, and a massive power diet to get down to 120 watts. There was no room to put anything. Plus due to the VLIW architecture of the Itanic and its reliance of predicated instruction streams generated by the compiler it should have been relatively tolerant of latency issues.
Quote
Please understand that I'm not advocating either way, but I am intellectually curious about Intel's decision. AMD managed 939 pin counts for on-die ddr and 940 for ECC. Socket AM2 supports ddr2 on-die. And i do understand that AMD's mem controller is more susceptible to ram latencies but everyone knew that the latencies of ddr2 would come down before ddr3 was available.
AMD also managed to spend a considerable chunk more cash to produce that high pin count and die size part. There is a reason why until the last couple years AMD rarely made a profit, and Intel has turned 100+ million dollar profit every quarter since the early 1980's. It's about more than just engineering and technology - it's also about sales, and most of all production.
When I left Intel in 2004 I think the average cost of production for a P4 was about $20 per working die. The cost of the Athlon at that point was about $35 per working die. One must also look at volumes - Intel sells ~10 times as many microprocessors as AMD, and yield is a very important aspect of making money at those volumes.
Quote
Was it simply a case of Intel knowing that the move to 65nm before AMD would trump the 10-20% performance increase of having the mem controller on-die or do you think that AMD's market grab of the enthusiast coupled with the Opteron server market grab pushed Intel into high gear?
Intel is always (and has been since the early 1980's) a pusher of the process - generally Intel and IBM are a process generation ahead of everyone else... and Intel's process is almost always more production worthy.
All Intel processor plans/roadmaps are closely tied to the process, so of course the move to 65nm ahead of AMD would play a part in the decision making - just like the realization the benefits of SOI dissapeared at 90nm influenced their decision not to use SOI in their 130nm process.
It basically comes down to two things:
1) Will this improvement increase ASP more than production cost?
2) Is this improvement needed to win/hold market share?
I don't think there was much speedup due to AMDs market share takeovers. Intel always took it seriously - at least inroads in the server space, the enthusiast market gets a lot of hype, but it really is a rather small market segment. Everything that is now coming out was already roadmapped and had started work before I left in 2004.
Quote
Just curious for a former insider's opinion. IMHO, Intel's release of ESamples of Conroe helped them significantly as the hype got so big, but then the real-world performance was spot on. The performance crown is now back to Intel. AMD's quad-core may help but there are so few proggies that utilize multi-threading that it may take something more for AMD to get back in the game.
AMD's new problem is going to be what Intel's old problem was with the dual core P4 - the competition has moved on to a new microarchitecture and physical design, and you're a generation behind. Adding the extra cores helps performance - but not THAT much... and your production costs sky rocket, power becomes more of an issue, etc. Given everything as it is now the Intel quad core part (Clovertown) is supposed to ship in Q4 - and it will be faster, smaller, and much more energy efficient than the 4 core Opteron. AMD will need a new design to get there.
Quote
Their purchase of ATI won't do it, imho.
I think it will help - one of AMD's biggest issue in the past has been motherboards. Unlike Intel they don't do motherboards (about 75% of the non-Intel motherboards that are based on Intel chipsets are direct copies of the Intel reference design) - and that means they are dependent on someone else spinning silicon for their releases. Having ATI in the fold gives tham a bit of an entry into the graphics/chipset world.
Looking back, that line, "Everything that is now coming out was already roadmapped and had started work before I left in 2004," seems to be quite the kick in the head to me. They were never worried about the AMD64.
