Note of warning: This reply is to a number of people to conserve space and save time.
That is funny. A prescott on any process is still a big leak. Well maybe not FD SOI, but even then, @ 65nanos, it would still leak badly. Just too many interconnects, with too many dissimilar charges next to each other.
I don't think I ever argued that. Scotty itself was such a bad design for other reasons as well. A Scotty on any process is still Scotty. :lol: But my point is that in switching processes, Intel has to redesign the core. Maybe they'll take that opportunity to fix a few things.
I have also heard that Amd has an automation program that allows them to transition seamlessly between 90 and 65 nanos. This also suggests that Amd is already 65 nano capable. Since they have offered the tech to SMC, or one of the other chip giants, I'd guess it must work.
Just because they have an automation program that can 'transition seamlessly' doesn't mean that when they do transition, it will be seamless. And it also doesn't mean that their cores are redesigned for 65nm yet. Time will tell. That's all I'm saying on that.
I remeber when prescott was supposed to be king shit and Spud @ the time had listed an entire page of improvements out of his head(he had really high hopes) and then a few days before release the pipline increase info was leaked and then the final product only for reviewers to find that it was actually slower overall and especially bad in games. :lol:
I remember that too. Hell, we all thought that Scotty would do better than it did. I mean there were tons of improvements. Intel just unfortunately squashed that advantage with tons of bad design. :? It was a sad day indeed. Scotty could have been soooooo much better if Intel had just stuck to fixing the problems with Northwood instead of screwing around with ... everything.
slvr_phoenix may have blaimed the 90nm process, but the failure of the P4 was just due to the Prescott architecture
Umm ... I didn't blame the process. I'm just using the process as a marker for the time period. Though the process itself does have it's problems, it's the bloody crap redesign done to the Scotty core that made it really suck. Never let it be said otherwise. :mrgreen:
specifically the pipeline increase
Actually, that had a pretty minor effect. I'm not even sure if I'd call that a bad decision. It was really what Intel did to Scotty's cache latency and misprediction handling that screwed Scotty badly. The pipeline increase didn't help, but it's far from the major contributor to Scotty's suckiness.
There really isn't anything wrong with the 90nm process when compared to the 130nm or any other Intel process.
That's actually not true. 90nm was the point when leakage became a serious problem. It was much worse than predicted. AMD was smart by starting to implement SoI. Intel ... not so smart. So there really
was something wrong with the 90nm process itself. That something is leakage. And that something will get worse and worse as each process gets smaller. This however is
balanced by adding new things to the process such as strained silicon, low/high-K dielectrics, SoI, internal carbon nanotube heat channels, etc. .13 was the magic number. Everything is downhill from there.
It seems that game developers, in a rush to get the game out of the door, usually fail to optimize the code for the latest instruction sets.
It has nothing to do with being in a rush to get code out the door. It has everything to do with compatability and debugging. You don't want to alienate a giant market segment by
requiring something like SSE3. So then you have to either not compile with it at all, or produce multiple branches that all theoretically do the same thing, but with different feature sets. But because there are different branches, you then have to test them all with different hardwares, and when a bug pops up, you first have to track down which branch it's even in. It's a royal pain in the butt. Which is why most people won't optimize nearly as much as they can. It just costs too much to be worth it.
Now people may feel that optimizing code for the Pentium IV would penalize AMD, but that may not be the case.
Actually, it is. If you're talking about just optimizing for instruction sets, then not so much. But if you're talking about optimizing for actual architectural differences in a P4, then if sure will penalize AMD. One of the most notorious of such examples is the bitshift optimization. It is (was?) a commonly used cheat to use bitshifting to perform certain multiplication and division functions because in the P3 a bitshift operation was blindingly fast compared to a multiplication operation. But Intel made bitshifting damn slow in the P4. Suddenly all of these 'optimizations' that were killer on a P3 or Athlon were slow as sin on a P4.
😱 So to fix that for a P4 meant ditching those optimizations that made the P3 and Athlon code fast.
And that's not even counting the simple optimizations done by organizing your code to maximize the use of a CPU using a profiler. Reorganizing code to keep the instruction units busy can really speed up a program. But the differences between the P4 and, well,
anything else are so dramatic that optimizing in this manner for a P4 makes the code slower on
everything else. Where as AMD, and even VIA, have kept their CPUs so much like the P3 that optimizing in this manner for these chips works out quite well for all chips ... except the P4.
And again, the only way to get these optimizations in for everyone is to branch code and create a maintanance nightmare. Which is why it's just typically not done.
So sorry, ltcommander_data, but you really just don't know what you're talking about here.