Will Intel ever use the rapid execution engine again?

[Duke3d87]

One of the features that i liked about the NetBurst core was the rapid execution engine; something that double clocked the ALU allowing operations to be done in half a clock cycle. Will such features come to conroe successors? I think it would be really great if upcoming processors obtained the rapid execution engine for more performance.

And is HT really gone forever? Anandtech believes that HT would do more for woodcrest then it did for the netburst generation cores.

 

[Scali]

I'm not sure if Conroe uses the Rapid Execution Engine idea...
But I think that many of the ideas in the P4 will be very useful again in the future, when the current barriers of clockspeed have been broken.
The P4 was originally designed to reach at least 5 GHz, and Intel was hoping for 10 GHz.
Because of the extreme leakage in the 90 nm process, they fell well short of their goal.
If a P4 can reach the actual clockspeeds it was designed for, it will be relatively more efficient. The pipeline is now 'too long' for the clockspeeds it is running at.
So I think Intel will be recycling the P4-technology when the time is right.

As for HT... Perhaps it is too expensive for Intel, so it's a decision based on economy, not on performance.
With the dualcore P4s, they only had it on the EE aswell... Perhaps because the yields of HT-capable CPUs were too low on the dualcores.

 

[empoy]

Core microarchitecture now uses 3 ALUs as part of its Wide Issue goodness.

 

[Scali]

But do these ALUs have 'early out' for the simpler instructions such as add, sub, or, and.., like the P4 did? That's the question.

 

[empoy]

what do you mean by early out?

 

[covertclocker]

what do you mean by early out?

I would have to guess that computing floating point calc's take a little longer than it does to computer 2+2. So he is asking if it sends the result of the simple add earlier when it gets the result instead of waiting a full clock or two like the floating point. I would have to say completing a calculation would increase performance.

 

[Scali]

I mean that the key feature of the P4's ALUs was that there was a certain group of instructions that could complete in 0.5 clks (that's basically what the whole Netburst/Rapid Execution Engine thing is all about).
So they had 'early out'. You could re-use the same ALU in the same cycle for a second instruction.
That way you could theoretically execute 4 ALU-instructions in only 1 clockcycle (the P4 has two ALUs).
I say theoretically, because in practice the CPU issued instructions every 2 clks and was limited to only 6 instructions per 2 clks. So effectively you could get no more than 3 instructions per clk sustained, although there may have been some clks where there were 4 instructions executed... that would just mean that there would never be more than 2 instructions in the following clk.

Since the new Conroe is clocked even lower, there will be an even larger group of instructions that requires less than one clk, and if you would use the P4's ALU's in the Conroe, some instructions may even be done in only 0.33 clks or less.

 

[Duke3d87]

I mean that the key feature of the P4's ALUs was that there was a certain group of instructions that could complete in 0.5 clks (that's basically what the whole Netburst/Rapid Execution Engine thing is all about).
So they had 'early out'. You could re-use the same ALU in the same cycle for a second instruction.
That way you could theoretically execute 4 ALU-instructions in only 1 clockcycle (the P4 has two ALUs).
I say theoretically, because in practice the CPU issued instructions every 2 clks and was limited to only 6 instructions per 2 clks. So effectively you could get no more than 3 instructions per clk sustained, although there may have been some clks where there were 4 instructions executed... that would just mean that there would never be more than 2 instructions in the following clk.

Since the new Conroe is clocked even lower, there will be an even larger group of instructions that requires less than one clk, and if you would use the P4's ALU's in the Conroe, some instructions may even be done in only 0.33 clks or less.

the first part i understood. How do you konw that the P4 could only issue instructions every two clock and was only able to issue three instructions per clock. Is it because of the three issue core?

And how does clock spee matter when it comes to conroe and a larger group of instructions that require less the one clock? Are you talking about maco and micro ops fusion? Also, if the Conroe core can execute one SSE2 instruction per clock and you double clocked, that'd be really interesting. How many SSE instructions can be processed at once? They never really say. And AMD claimed that with the AthlonXP, they could crank out 9 instructions per clock and the Pentium 4, 6 instructions per clock. If you can issue three instructions per clock, you're bottlenecked at 3 instructions per clock. How does AMD claim to have such as high instruction per clock?

 

[empoy]

wish I could provide more info but more microarchitecture details (aside from what has been released in IDF) are still confidential

what you're talking about SSE is called SSE unlamination

 

[Scali]

the first part i understood. How do you konw that the P4 could only issue instructions every two clock and was only able to issue three instructions per clock. Is it because of the three issue core?

That's just how the P4 works. It's documented in the Intel optimization manuals. The instructions are not issued per clk, but per 2 clks, and there is a maximum of 6 instructions at a time (not sure if it was the issuing or the retirement that was the limiting factor, or perhaps both... with Athlon the retirement is the limit anyway... 3 instructions per clk max).

And how does clock spee matter when it comes to conroe and a larger group of instructions that require less the one clock?

Quite simple... lower clockspeed means that a single clockcycle takes longer. So, assuming that the ALUs of the Conroe are at least as fast and efficient as the ones in the P4, they have more 'idle time' when performing the same instructions.

Are you talking about maco and micro ops fusion? Also, if the Conroe core can execute one SSE2 instruction per clock and you double clocked, that'd be really interesting. How many SSE instructions can be processed at once? They never really say.

But they do. Well, not directly, but they document how many units the CPU has, and what instructions each unit is capable of handling. I believe in general you can do 2 SSE instructions at a time on P4 and Athlon, although there are always exceptions.

And AMD claimed that with the AthlonXP, they could crank out 9 instructions per clock and the Pentium 4, 6 instructions per clock. If you can issue three instructions per clock, you're bottlenecked at 3 instructions per clock. How does AMD claim to have such as high instruction per clock?

I don't think AMD ever claimed that.
The only claim involving 9 instructions is the number of instructions being in execution at the same time, as far as I recall. Which is correct. AMD uses 3 ALUs, a 3-way FPU unit, and then it has 3 more units for address generation and load/store operations, if I'm not mistaken.
So theoretically you can have 9 instructions running at the same time. But you won't get anywhere near that amount with normal code, unless most of your instructions are stalling for some reason. With most code, you probably have 2 or 3 instructions at the same time, on average.

 

[Duke3d87]

That's just how the P4 works. It's documented in the Intel optimization manuals. The instructions are not issued per clk, but per 2 clks, and there is a maximum of 6 instructions at a time (not sure if it was the issuing or the retirement that was the limiting factor, or perhaps both... with Athlon the retirement is the limit anyway... 3 instructions per clk max).

So based on what i'm understanding it would be more adventatious to issue every clock? Is there a reason why they don't issue every clock cycle?

Quite simple... lower clockspeed means that a single clockcycle takes longer. So, assuming that the ALUs of the Conroe are at least as fast and efficient as the ones in the P4, they have more 'idle time' when performing the same instructions.

But would not the P4 have a harder time processing what Conroe can process in the same amount of time? The P4 was also bashed for being inefficient due to the long pipeline and whatnot. So are you saying that the long pipeline actually helped ALU and FPU performance by jacking up the clock speed? That sounds wrong, but that’s the best conclusion I could come up with at 5:40 AM.

But they do. Well, not directly, but they document how many units the CPU has, and what instructions each unit is capable of handling. I believe in general you can do 2 SSE instructions at a time on P4 and Athlon, although there are always exceptions.

AMD on its site said that Intel had 4 ALUs and two pipelined FPUs. So you’re saying that what the two pipelined FPUs that Intel had could do the work that 3 pipelined FPUs could do for an AMD? And are the two FPU operations per clock that Conroe can process total? Or is it of one FPU?

I don't think AMD ever claimed that.
The only claim involving 9 instructions is the number of instructions being in execution at the same time, as far as I recall. Which is correct. AMD uses 3 ALUs, a 3-way FPU unit, and then it has 3 more units for address generation and load/store operations, if I'm not mistaken.
So theoretically you can have 9 instructions running at the same time. But you won't get anywhere near that amount with normal code, unless most of your instructions are stalling for some reason. With most code, you probably have 2 or 3 instructions at the same time, on average.

Oh I see what you’re saying. That makes sense. This stuff is getting more confusing. The more I know, the more I know I don’t know. So what really was the killer of the Pentium 4 line? Everyone says pipeline, but I’m not so sure anymore. And I’m starting to get confused as to why a long pipeline is bad. Intel claims that it’s got a highly efficient branch prediction method for the Pentium 4 (and highly accurate). So I’m assuming that the performance hits come when you have a bad prediction and flush the entire pipeline? Or is it b/c the FPU and Integer pipeline’s increase in length also drives down efficiency.

BTW, what is it about Penryn that makes it so secretive? (Other then the 6 MB L2 cache and the 45nm process)

 

[Scali]

So based on what i'm understanding it would be more adventatious to issue every clock? Is there a reason why they don't issue every clock cycle?

They probably can't issue every cycle because of the P4's superhigh clockspeeds.

But would not the P4 have a harder time processing what Conroe can process in the same amount of time? The P4 was also bashed for being inefficient due to the long pipeline and whatnot. So are you saying that the long pipeline actually helped ALU and FPU performance by jacking up the clock speed? That sounds wrong, but that’s the best conclusion I could come up with at 5:40 AM.

I'm not talking about the pipeline length, but strictly about the ALUs.
The ALUs themselves are quite good, the main problem with performance is the pipeline, and the extra latencies/penalties for unpredictable code.
If you're running perfectly predictable code, the P4 will often beat anything else out there.

AMD on its site said that Intel had 4 ALUs and two pipelined FPUs. So you’re saying that what the two pipelined FPUs that Intel had could do the work that 3 pipelined FPUs could do for an AMD? And are the two FPU operations per clock that Conroe can process total? Or is it of one FPU?

Are they talking about the P4 there? The P4 has 2 ALUs, not 4. Technically the P4 doesn't have an FPU at all, at least, not in the sense of x87, but it does have MMX/SSE/SSE2/SSE3 units, which are used for FPU-instructions aswell (P4 was designed to run all FPU-code with SSE/SSE2 code, the x87 is just emulated for backward compatibility).
AMD doesn't have 3 pipelined FPUs either.
AMD just cut its FPU up into 3 separate subpipelines, which can each handle a certain subset of instructions. So you can only have 3 instructions at the same time when each of them is from a different subset. That doesn't happen too often in practice, so the gain is not that big. AMD never had 3 SSE/MMX-units either, only 2, again each processing a subset.
It's also not interesting, since a lot of x87-code is rewritten for SSE/SSE2 already (in fact, x87-code doesn't even work in Windows x64 at all, in 64-bit mode, so all 64-bit Windows software is x87-free by default).
Basically x87 is dead, and SSE/SSE2 is all that matters. The P4 was much better than the Athlon at that, and I expect the Conroe to be even better.

Oh I see what you’re saying. That makes sense. This stuff is getting more confusing. The more I know, the more I know I don’t know. So what really was the killer of the Pentium 4 line? Everyone says pipeline, but I’m not so sure anymore. And I’m starting to get confused as to why a long pipeline is bad. Intel claims that it’s got a highly efficient branch prediction method for the Pentium 4 (and highly accurate). So I’m assuming that the performance hits come when you have a bad prediction and flush the entire pipeline? Or is it b/c the FPU and Integer pipeline’s increase in length also drives down efficiency.)

The 'only' problem with a long pipeline is basically the branch-prediction yes.
Partly I think a lot of code is just written poorly for P4, in that it uses more branches and less predictability than it could... I'm convinced that rewriting software from P3/Athlon to P4 can make quite a difference in most cases.
For the rest, there's a problem of the P4 missing its mark clockspeed-wise. If they could actually reach clockspeeds in the 5-10 GHz range, the story would be different.
They'd have so much processing power, that they could afford the time lost in branching.
And the question is if there even IS another way to reach that amount of processing power rather than using a long pipeline.

So in a way the P4 was quite an ambitious CPU... it just couldn't live up to its designers' expectations (yet?). The Conroe is not that ambitious, it's more of a new-and-improved and rehashed version of current CPUs from Pentium Pro to Athlon64.
Back to the old concept of trying to maximize IPC, while retaining a 'low' clockspeed.
I suppose the Conroe just tries to find the right balance between Athlon64 and P4 for the current state of technology. P4 is too far ahead of time, Athlon64 is getting a bit long in the tooth.

 

[Duke3d87]

I'm not talking about the pipeline length, but strictly about the ALUs.
The ALUs themselves are quite good, the main problem with performance is the pipeline, and the extra latencies/penalties for unpredictable code.
If you're running perfectly predictable code, the P4 will often beat anything else out there.

Isn’t the problem that most of the code is not predictable? And if the branch predictors were as accurate as Intel claimed, it doesn’t matter if the code was branchy b/c the pipeline would not need to be flushed. I was looking at a schematic of the Pentium 4 and from the decoder to the trace cache, you could only crank out 1 uop. If it would crank out as much as Conroe (7 – 4 for complex decoder, and 3 for simple decoder, but it’s more like 5), would performance have increased a lot? Same with trace cache to engry uop buffer (whatever that is?)

Are they talking about the P4 there? The P4 has 2 ALUs, not 4. Technically the P4 doesn't have an FPU at all, at least, not in the sense of x87, but it does have MMX/SSE/SSE2/SSE3 units, which are used for FPU-instructions aswell (P4 was designed to run all FPU-code with SSE/SSE2 code, the x87 is just emulated for backward compatibility). AMD doesn't have 3 pipelined FPUs either.
AMD just cut its FPU up into 3 separate subpipelines, which can each handle a certain subset of instructions. So you can only have 3 instructions at the same time when each of them is from a different subset. That doesn't happen too often in practice, so the gain is not that big. AMD never had 3 SSE/MMX-units either, only 2, again each processing a subset.

It's also not interesting, since a lot of x87-code is rewritten for SSE/SSE2 already (in fact, x87-code doesn't even work in Windows x64 at all, in 64-bit mode, so all 64-bit Windows software is x87-free by default).
Basically x87 is dead, and SSE/SSE2 is all that matters. The P4 was much better than the Athlon at that, and I expect the Conroe to be even better.

I think what AMD was talking about was the Rapid execution engine allowing the Pentium 4 to appear to have 4 ALUs. If AMD never had 3 FPUs rather then two which were broken down to appear as three, why were AMD’s usually faster in FPU operations until the Pentium 4 came along? And I think the Pentium 4’s SSE2 performance was due to optimization. A site had a guide to Conroe architecture and they claim that Conroe beats the Pentium 4 in FPU b/c it has more SSE2 resources whatever that means.

Basically a lot of what AMD posted on its site was biased and favored the Athlon core?

The 'only' problem with a long pipeline is basically the branch-prediction yes.
Partly I think a lot of code is just written poorly for P4, in that it uses more branches and less predictability than it could... I'm convinced that rewriting software from P3/Athlon to P4 can make quite a difference in most cases.
For the rest, there's a problem of the P4 missing its mark clockspeed-wise. If they could actually reach clockspeeds in the 5-10 GHz range, the story would be different.
They'd have so much processing power, that they could afford the time lost in branching.
And the question is if there even IS another way to reach that amount of processing power rather than using a long pipeline.

Isn’t that why when media benchmarks were run on the Pentium 4 it excelled? So you’re saying that if software was efficiently programmed, it would run well on the NetBurst more so then the Conroe and AMD series. What about power consumption? That’s one of the largest problems with the NetBurst series. If you could have a Pentium 4 whose power consumption was on par with the Conroe lines, that’d be amazing and just about impossible if you wanted the same performance as the Conroe. Also, the Pentium 4 always excelled in media encoding, but when the Pentium D came out and was pitted against the X2, it did not do so well. Is it because of a severe bottleneck? I mean if the Pentium 4 thrives on bandwith then even 800 MHz FSBs for the 640 would not be enough.

So in a way the P4 was quite an ambitious CPU... it just couldn't live up to its designers' expectations (yet?). The Conroe is not that ambitious, it's more of a new-and-improved and rehashed version of current CPUs from Pentium Pro to Athlon64.
Back to the old concept of trying to maximize IPC, while retaining a 'low' clockspeed.
I suppose the Conroe just tries to find the right balance between Athlon64 and P4 for the current state of technology. P4 is too far ahead of time, Athlon64 is getting a bit long in the tooth.

I’ve heard it said that the Pentium 4 was before its time. Do you think given more time and resources, Intel can redeem the Pentium 4 and make it to be what it was designed to be? Like take parts from Conroe and integrate it into the Pentium 4 when it comes to FPU? Because if the Pentium 4 was truly before its time, then in the future, I would think that Intel might pull it back out but fully tweaked. I mean they did that with the Pentium 3 series with Pentium-M and now Conroe.

After talking to you, it seems like a shame that the Pentium 4 did not have more time to mature.

 

[Scali]

Isn’t the problem that most of the code is not predictable? And if the branch predictors were as accurate as Intel claimed, it doesn’t matter if the code was branchy b/c the pipeline would not need to be flushed. I was looking at a schematic of the Pentium 4 and from the decoder to the trace cache, you could only crank out 1 uop. If it would crank out as much as Conroe (7 – 4 for complex decoder, and 3 for simple decoder, but it’s more like 5), would performance have increased a lot? Same with trace cache to engry uop buffer (whatever that is?)

Somehow the 1 uOp seems wrong to me, I don't think it's THAT slow. Even a PPro could already do 6 uOps per clk.
Besides, it doesn't matter much anymore because of the tracecache.
Instruction decoding is decoupled from the execution. So the system will keep decoding new code while the pipeline is repeating the same loop.
Since most of the time of a program is spent in loops, decoding isn't really a factor in performance anymore (unless for some reason the loop runs out of tracecache, but that is not very likely, since you can fit 12k uOps into the cache).

I think what AMD was talking about was the Rapid execution engine allowing the Pentium 4 to appear to have 4 ALUs.

Yes, that way their product looked better, I suppose... But it's not entirely accurate, there are only a handful of instructions that are Rapid-executable... for all other instructions, you only have 2 ALUs, no matter how you look at it.

If AMD never had 3 FPUs rather then two which were broken down to appear as three, why were AMD’s usually faster in FPU operations until the Pentium 4 came along?

Simple, the P3-FPU was not broken down at all, you only had a single unit, where all instructions had to be executed in sequence (except for some pipelining capabilities and the fxch-hack in the decoder).

And I think the Pentium 4’s SSE2 performance was due to optimization.

I don't... P4 offers lots of cache, high bandwidth and high clockspeeds. That's exactly what most SSE2-code likes.
I've written SSE/SSE2-code for PIII, P4 and Athlons, and the P4 ended up with the fastest code pretty much all the time, no matter how hard I worked at the code for PIII/Athlon.

A site had a guide to Conroe architecture and they claim that Conroe beats the Pentium 4 in FPU b/c it has more SSE2 resources whatever that means.

Well, if it works like the P4, then it doesn't have an actual FPU either, and uses the SSE2-units. If it has more resources for SSE2, then it also has more resources to emulate the FPU. That would make sense.

Isn’t that why when media benchmarks were run on the Pentium 4 it excelled? So you’re saying that if software was efficiently programmed, it would run well on the NetBurst more so then the Conroe and AMD series.

No, I'm not saying it would be better than Conroe or AMD processors. I'm saying that I think there's a lot of software that is not designed to run efficiently on P4, so it doesn't show the CPU's full potential.
Most media stuff is P4-optimized, and it performs so well partly because media/SSE2 stuff is what the P4 was made for, and partly because the code itself is written well for P4.

I’ve heard it said that the Pentium 4 was before its time. Do you think given more time and resources, Intel can redeem the Pentium 4 and make it to be what it was designed to be? Like take parts from Conroe and integrate it into the Pentium 4 when it comes to FPU? Because if the Pentium 4 was truly before its time, then in the future, I would think that Intel might pull it back out but fully tweaked. I mean they did that with the Pentium 3 series with Pentium-M and now Conroe.

I can't say if the P4 can ever become what it was designed to be. There are just physical limitations with the silicon to overcome. I'm just saying that *if* these limitations will be overcome (or at least the possibilities stretched far enough), then the P4 may once again shine when it scales up to clockspeeds of well over 5 GHz, and finally get into the proper clockspeed/IPC-ratio.
Conroe was designed for a different clockspeed/IPC-ratio, so its technology is not necessarily better for the P4 aswell.

Ofcourse this could be many years into the future, so by then the P4 is completely outdated, and won't be good unless it gets a proper overhaul, but still, we may see a CPU with such a long pipeline once again.

After talking to you, it seems like a shame that the Pentium 4 did not have more time to mature.

Well, in a way it is... it's just a big story of "what might have been". The P4 is the most complex x86 CPU to date (not including Conroe, I can't say anything about that CPU yet, I don't know enough about it), and a lot of technology is really innovative, like the Trace Cache, or the Rapid Execution Engine.
It just blindly crashed into a wall of ~4 GHz, which ended its career rather abrubtly.
Bit of a shame, because there was also a glorious period in its life, in the early Northwood-era.