Bob Colwell (chief Intel x86 architect) talk.

Ahh, thanks Mfa. I stand corrected.

 

Um... too bad you're memory isn't good enough to remember, during that time, they didn't have problems keeping up with AMD, infact, they scaled back their roadmap when it came to speed bumps, because of that reason alone. Mind you that was performance taken on RDRAM platforms and only comparing the flagships of each company. Not price performance or anything like that.

 

Well, they tried to release faster 180nm P3's but we all know what happened to them. Intel pushed the P3 until it broke (originally it was supposed to scale at a much more leisurely pace to around 700 MHz) and still could’t touch neither Athlons nor P4's. I don't think that Intel could have gotten much more out of the P3 architecture without a full redesign like the PM and there wasn't any time for that.

I take the opposite viewpoint – I don’t think everything Intel did with the P4 was good (eg. L1 cache that sometimes behaves like it’s direct mapped and slow shifters). I think that the decision to go with a speed demon design was one of several good ones available and certainly the P4 matched the Athlon on the 180 nm process and often outperformed it on the 130 nm process. Sure it’s more dependant on optimised code but Intel is big enough to force that on developers (just see what happed between IL-2 and IL-2 FB) and in the long run that’s a good thing for everyone. Normally one would expect a 90 nm Netburst core to have competitive performance but somewhere along the way some combination of core fixes, more use of automated design tools, mystery transistors, overestimating the effect of strained silicon, 90 nm leakage and 31 stages borked the Prescott.

Yes, but that is only wrong if they don’t deliver the performance and the Alpha EV5 and P4 shows that speed demons can work very well.

 

It's not like they had to go the route of the P4, though. My point was that the P3 had much higher IPC than the P4. You'd think it would have been pretty straightforward for Intel to have either maintained or enhanced IPC for their next architecture. But no, they decided for, "MHz or bust." This was a dead-end, and they should have known it.

It's not that high frequency is a bad thing to pursue. It's that pursuing high frequency at the cost of IPC is bad. That's what Intel did, and now they're paying for it.

 

Jesus christ, that takes up about 46% of the scroll bar on my IE. O.O Very interesting though. Edit: That was 3608 words, Walt. I am truely impressed.

 

GPU manufacturers are competing for gamers, and the CPU is dragging them down compared to their main competitors ... consoles.

CPUs are doing occlusion culling now, and doing a lousy job. That has to move to the GPU sooner or later. Physics? Probably going to move to the GPU too. AI? Well it doesnt need SIMD so the CPU has a bit less of a disadvantage, but it is still massively parallel (each actor is independent in a given timestep). For gaming the CPU is a poor match for any computationally intensive task.

Maybe the symbioses wont change, but then PC gaming will start bleeding even more players.

 

When you look at the computation market, GPU manufacturers have targeted the floating point performance segment far more than the CPU manufacturers.

I agree that pretty much all of the computation intensive tasks will eventually move to what is now considered the GPU. This includes all the physcial simulation, collision detection, 3d graphics (including all the culling), etc.

This means the GPU of the future will need to gradually transform into a massively parallel general purpose floating point vector processor that can be programmed using standard programming languages like C++. This in turn means general purpose addressing, branching, and stack management. Something that looks more like a FASTMATH processor than a current GPU. However, one major difference compared to a CPU is that the vast majority of the transistors will be used for actual logic with large numbers of floating point ALUs rather than for on-die cache. Instead future GPUs/vector processors will likely continue to rely on very high external memory bandwidths with a small amount of on-die cache.

It also means scaling up frequencies significantly using dynamic logic.

 

CPU and then a Math Co, we've been there before, they could merge.

I feel that, there will come a time where a motherboard will have very fast interfaces, within which one can attach a processor geared towards differeing workloads, however.

I'm leaning towards the latter because, we can start affording that sooner than we can the transistors in a single package to support a unified solution.

If I understand things correctly, logic heavy chips have sprawling networks for power and signalling, these large networks will utilize interconnects more heavily, which, as the feature size decreases, present greater resistances; won't all of this require greater voltage to propagate a singal and thusly increase power quadratically as opposed to smaller PU and smaller networks at higher frequencies?

 

I think the voltage that a processor can use is limited by the transistors that are used.

 

SA -
I hope that your description of a "massively parallel GPU of the future" is coupled with a language that allows the software developer to directly specify parallelism to the compiler. Keeping the syntax similar to C/C++/Java/C# is IMO a good idea, but to my mind using any of those languages as they stand would be like having an old grannie drive a Porshe.

Somewhat OT, an interesting link :
http://wavescalar.cs.washington.edu/

exciting times ahead...

 

If I understand you correctly, ATi is already on the right track, cause they have licenced the Fast14 - process for dynamic logic from Intrinsity which is also producing or licencing the FastMATH processor. So it could very well be that they have also licenced the FastMATH processor too.

IMHO there could even be another path to high performance computing for massive parallel multimedia-tasks :

http://stretchinc.com/

They embedd an FPGA, called ISEF within an RISC-processor so that they can program the FPGA with C/C++. The performance of this combination seems to be very high. An S5000 @ 300MHz programmed in C++ is faster than an FastMATH processor @ 2GHz programmed in assembler in the EEMBC telemark benchmark.
The only drawback I see at the moment seems to be the slow interchangeability between different algorithm due to the need to program the ISEF/FPGA.

 

FPGAs are hugely inefficient as far as power consumption and area use when working with wide words is concerned. Anything suited to our needs would still need to have specialized circuitry for arithmetic, datapaths, register sets and caches IMO. The overhead of implementing any of these in a FPGA is unrealistic.

There might be levels below simple multi-core chips with relatively standard processors/shader-units though which could work well, something like MOVE. I still think condensed graphs might translate well to hardware.

 

I think we more or less agree on that. I just don't think it was a bad idea at 130 nm an earlier and it should have worked decently enough at 90 nm but all this Intel talk about superscaling 10 GHz P4's is looking more and more like someones bad acid trip.

 

What I'm simply trying to point out is that AMD realized these things long ago when it was designing the original K7 core, and so AMD never embarked on the same kind of "less-efficient-but-clocked-to-the- stratosphere" approach to Athlon that Intel announced early on for the P4. The roadmap cancelled here is the P4's--not the Athlon's--so that should tip you to the fact the problems faced by AMD with Athlon as to its particular roadmap, and the problems faced by Intel with respect to the P4 roadmap are entirely *different* sets of problems, because the strategies behind the roadmaps are different, and the cpu architectures themselves are different. AMD never at any time announced a 7-10GHz ultimate production target for the K7, Intel did for the P4, and so obviously these differing roadmap strategies produced different kinds of problems for each company to solve.

Of course, as I said, everybody knows cpu manufacturing is getting tougher--that's not news--and is certainly something generally well known prior to Intel's P4 MHz-ramp roadmap being cancelled. What's going to count in the future is how these companies respond to the problems and challenges they face ahead. This does not simply boil down to a matter of technology--it boils down to the strategies companies employ to deal with those problems--which in turn becomes much more a matter of judgment than one of pure technology. As you say, there are always several ways to skin the cat... What counts in the end, though, is whether or not one company chooses a better method of skinning the cat than another. With the introduction of Athlon, AMD embarked on one method of skinning the cat (architecurally-driven increases in processing efficiency), with P4 Intel embarked on another (less-efficient architectures driving performance through MHz ramps achieved through process reductions), and it certainly seems to me that what's been cancelled here is the P4 strategy--not the Athlon strategy, right?

In fact, Dothan and Itanium also eschew the strategy of driving performance through the MHz ramping of less efficient architectures, don't they? So does IBM's G5, Sun's SPARC, etc. In other words, what AMD's done relative to its Athlon strategy is actually much more common in cpu design and manufacturing than was the P4's MHz-driven strategy, even within the Intel family of cpus itself. Cancellation of the P4 roadmap tells us only about problems Intel had with its P4 MHz-driven roadmap, which Intel has found to be insurmountable. However, they are changing strategies to bring their x86 design strategy in line with the strategy used by AMD for x86 cpu design and manufacturing--just because the problems are tougher these days doesn't mean Intel's giving up--it's just shifting gears and changing strategies.

 

I agree with most of what you're saying, but I wouldn't lump IBM's G5 into this.

It's focused on more floating point performance and parallel processing not the Mhz as seen they are barely able to reach 2GHz.

Speng.

 

Let me clarify my positions below.

The Pentium 4

I really dont know what happened but there are some levels of possible problems like:
a - the basic idea of use long pipelines to implement a speed deamon.
b - the conceptual phase of the design based on "a"
c - the implementation phase of the design

Looks like the conceptual phase of the P4 design had some modifications of the initial idea, and the implementation phase had problems like:
- few people (3) really understand the entire design
- too large development team
- probably the tools where the best possible, but not good enough to help with such complex design

The point is I am not sure a long pipeline is not a good idea if you:
- have a better ISA
- dont have heavy logic overhead for hyperthreads, i32e, DRM, etc...
- have better tools to develop it

Maybe if Intel had redesigned/improved the northwood core they could:
- Had implemented a faster 1MB L2 cache ( 5% performance increase)
- implemented a larger L1 microops cache
- implemented a larger L1 data cache
- a second FPU unit
- some speed gain without the hyperthread logic overhead

This could
- have "only" around 80 Millions transistors
- more chips per wafer and better yields
- colder
- higher IPC

Then a 2.8GHz P4 could have a 3.2GHz performance and a 1.8AGHz heat dissipation.
And a 4GHz P4 could be as fast as a 5GHz Prescott.
This could be a winner in the current PC market

edited: also we dont dont know what impact a low latency onchip memory controller could have with a long pipeline CPU.

The wintel PC model

Independentelly of the P4 success or failure IMHO the current wintel Personal Computer model is old, ineficient and it is time to change for something better.
We need some alternatives urgentlly. Maybe I will post a new thread about it.