Into the Core - Intel's New Core CPU

Tyler Too writes "Hannibal over at Ars Technica has an in-depth look at Intel's new Core processors. From the article: 'In a time when an increasing number of processors are moving away from out-of-order execution (OOOE, or sometimes just OOO) toward in-order, more VLIW-like designs that rely heavily on multithreading and compiler/coder smarts for their performance, Core is as full-throated an affirmation of the ongoing importance of OOOE as you can get.'"

Comments

AMD Vs Intel: Round 8

[eldavojohn]

Ok, so I know I'm going to get a lot of AMD people agreeing with me and a lot of Intel people outright ripping me to shreds. But I'm going to speak my thoughts come hell or high water and you can choose to be a yes-man (or woman) with nothing to add to the conversation or just beat me with a stick.

I believe that AMD had this technology before Intel ever started in on it. Yes, I know it wasn't really commercially available on PCs but it was there. And I would also like to point out a nifty little agreement between IBM and AMD that certainly gives them aid in the development of chips. Let's face it, IBM's got research money coming out of their ears and I'm glad to see AMD benefit off it and vice versa. I think that these two points alone show that AMD has had more time to refine the multicore technology and deliver a superior product.

As a disclaimer, I cannot say I've had the ability to try an Intel dual core but I'm just ever so happy with my AMD processor that I don't see why I should.

There's a nice little chart in the article but I like AMD's explanation along with their pdf a bit better. As you can see, AMD is no longer too concerned with dual core but has moved on to targeting multi core.

Do I want to see Intel evaporate? No way. I want to see these two companies go head to head and drive prices down. You may mistake me for an AMD fanboi but I simply was in agony in high school when Pentium 100s costed an arm and a leg. Then AMD slowly climbed the ranks to be a major competitor with Intel--and thank god for that! Now Intel actually has to price their chips competitively and I never want that to change. I will now support the underdog even if Intel drops below AMD just to insure stiff competition. You can call me a young idealist about capitalism!

I understand this article also tackles execution types and I must admit I'm not too up to speed on that. It's entirely possible that OOOE could beat out the execution scheme that AMD has going but I wouldn't know enough to comment on it. I remember that there used to be a lot of buzz about IA-64's OOOE processing used on Itanium. But I'm not sure that was too popular among programmers.

The article presents a compelling argument for OOOE. And I think that with a tri-core or higher processor, we could really start to see a big increase in sales using OOOE. Think about it, a lot of IA-64 code comes to a point where the instruction stalls as it waits for data to be computed (most cases, a branch). If there are enough cores to compute both branches from the conditional (and third core to evaluate the conditional) then where is the slowdown? This will only break down on a switch style statement or when several if-thens follow each other successively.

In any case, it's going to be a while before I switch back to Intel. AMD has won me over for the time being.

Re:AMD Vs Intel: Round 8

[archen]

f there are enough cores to compute both branches from the conditional

I don't see how that could really be useful. I mean if you were computing instructions on a one by one basis, then perhaps that would work, but you fill the pipe then find out it's the prediction is wrong so you go to the other cpu, however when you look at the bigger picture you realize that you are essencially crippling one CPU by dedicating it to doing something other than actually processing.

Intel's CPU branch prediction is already known to be better than AMD's. I think the bigger news is that the pipe will be cut down by half of the P4 to 14. If they can keep the processor fed (and perhaps move the memory controller on die like AMD has), then Intel may finally be able to end the spanking session they've been recieving by AMD.

Re:AMD Vs Intel: Round 8

[tpgp]

I will now support the underdog even if Intel drops below AMD just to insure stiff competition. You can call me a young idealist about capitalism!

Hmmmmn, I think I'll actually call you someone who needs to read up a bit on both idealism and capitalism!

Also, on a somewhat note - never care about a company, because the company cannot reciprocate your feelings.

If Intel comes out with a better, cheaper processor tomorrow, don't buy the AMD one, buy the intel one. Their is no point treating a company like a person.

Re:AMD Vs Intel: Round 8

[DesertWolf0132]

As you fear a beating from the Intel side after what I say I fear I will receive a beating from both.

In my personal experience the AMD chips have been the fastest systems I have ever owned. My problem with them is the boards made for them (this is personal experience only) tend to become unstable after a couple of years. Intel boards, in my experience, stay stable longer.

For example, I have two 5 year old systems, one with a Gigabyte AMD Athlon board, and one with a true Intel P3 board. Both run Slackware. Both have insane cooling so the board temps never go over 100 degrees. The Athlon board system will occasionally reboot for no reason. The Intel board system has run for months without ever needing to be touched. The last time I brought it down was for a power outage that lasted longer than the battery on my UPS. I have tested everything on the Athlon system. The power supply is solid, the hard drive is new and the second one I have installed, none of the controllers test bad, and while it is running nothing tests bad using diagnostics. Then it suddenly reboots.

One would think this an isolated incident but I have build 6 Athlon systems in the last 5 years for friends and only two are still stable. All of the Intel systems I have built with true Intel boards in the last 15 years are still running including a 486 DX/2 66. I know this is personal experience only and not a good enough sample to make any real judgement but as for me, I pick Intel. That said, I believe the problems I have had with AMD come from the fact that none of the boards are made by AMD. If AMD made a board up to the same standards as its CPU I believe my opinion would change in a heartbeat.

You may commence my flogging now...

Re:AMD Vs Intel: Round 8

[amjacobs]

It's entirely possible that OOOE could beat out the execution scheme that AMD has going but I wouldn't know enough to comment on it. I remember that there used to be a lot of buzz about IA-64's OOOE processing used on Itanium. But I'm not sure that was too popular among programmers.

There is nothing new with Out of Order Execution. It's been implemented in all the Pentium cores as well as AMD chips from the K6 (I think) on up. In fact, the reason why going to multi-core designs is necessary is because it is difficult to extract any more instruction-level parallelism (ILP) from code using additional hardware techniques. (For instance, some new hardware may increase performance by 3%, but add 10% area to the design) Itanium, which is an in-order processor, shifts the ILP extraction to the compiler.

The article presents a compelling argument for OOOE. And I think that with a tri-core or higher processor, we could really start to see a big increase in sales using OOOE. Think about it, a lot of IA-64 code comes to a point where the instruction stalls as it waits for data to be computed (most cases, a branch). If there are enough cores to compute both branches from the conditional (and third core to evaluate the conditional) then where is the slowdown? This will only break down on a switch style statement or when several if-thens follow each other successively.

Processors can already do what your suggesting. All modern cores from AMD and Intel are super-scalar. This means that there are multiple pipelines running in parallel. If you have two pipelines, you can compute both of the possible results from a branch and discard the incorrect value. BUT, you cut your maximum efficiency by half. (You are using 2x the resources to get 1x the results) You wouldn't want to do the same thing with separate cores for a variety of reasons. Instead, using separate cores for separate threads provides an immediate performance improvement without the need for major code revisions.

I don't think you'll find anyone who is against using OOE. Ideally, you would want a processor that combines good hardware techniques (OOE, branch prediction, prefetching) with a good compiler/ISA (maybe some sort of VLIW, but I still have my doubts about the compiler feasability). The key for AMD and Intel is to find the right balance of hardware and software techniques that provide the best overall performance.

Re:AMD Vs Intel: Round 8

[evilviper]

If Intel comes out with a better, cheaper processor tomorrow, don't buy the AMD one, buy the intel one. Their is no point treating a company like a person.

Clearly you've never heard of a boycott, picket, or any other similar form of consumer revolt.

Re:AMD Vs Intel: Round 8

[BeBoxer]

What sort of tests have you run on it? My home machine would misbehave occasionally, with random applications crashing. I tested it with Memtest86+, and it didn't find any problems. Since I run Linux, I tried repeated kernel compiles next. Doing that, I found it couldn't manage more than two or three complete compiles without the compiler failing. In my case, re-arranging my DIMMs cleared it up. But since one of the DIMM's was bought at fire sale prices at a computer surplus show, I don't think I can blame my crashes on AMD. What's my point? I don't know, other than saying that memory is a ripe place for problems and it's not unheard of for diagnostics for a specific subsystem to not pick up problems.

Re:AMD Vs Intel: Round 8

[Anonymous Coward]

If Intel comes out with a better, cheaper processor tomorrow, don't buy the AMD one, buy the intel one. Their is no point treating a company like a person.

You missed his point entirely. You're advocating a short-term, passive outlook, while the GP is advocating a long-term, active one. If you buy whoever is less expensive now, you get the benefit of saving money on this purchase and every purchase from them until they decide to raise prices. And that will be shortly after they snuff all the competition out of existence. If you buy from whoever is the underdog, you'll likely get a less expensive item now (since they have to cut prices to get attention away from the market leader), and in the future, you'll see healthy competition where everyone (including the market leader) has to lower prices. And that makes all of your purchases less expensive overall.

It's not "caring about a company". It's evaluation of a company's credentials and market position. The word "care" is just used as a shorthand way of saying that. In context, it makes perfect sense. In the context of a person, "care" is a term of affection or affinity. In the context of a company whose product you're planning to purchase, "care" is a term of satisfaction with the product and acceptance of the purchase terms. And on that level, a company can reciprocate your feelings and "care" about you as a customer.

Re:AMD Vs Intel: Round 8

[antime]

If there are enough cores to compute both branches from the conditional

I don't see how that could really be useful.

Doing it with multiple cores would probably be a waste, but isn't that what the IA64's predicated execution is all about? To avoid pipeline bubbles it executes both paths from the branch, and once the branch condition is known the results from the not-taken path are thrown away.

Re:AMD Vs Intel: Round 8

[vondo]

I suspect you are right. My problem seems to be with the VIA KT333/400/600 series of boards. I manage about 40 PCs at work and at home an almost without exception over the last 3 years, the failures have been these boards. The boards are a mix of 440BX, VIA KT, Intel 865 (I think), dual Athlon MPs (the old ones), new NForce 4, and a few other chipsets. The (assumed) VIA problems put me off Athlons for quite a while, which is not good for AMD.

I say assumed, because I think twice we tracked it down and it was the MB. After that, we just replaced the whole MB/CPU/RAM combo since it's not worth trying to diagnose and replace one old part.

The 440BX boards are tanks. They are running 450 MHz P3s 24/7 for about 8 years now and have ~0 problems.

Re:AMD Vs Intel: Round 8

[dpilot]

>Guess what, Intel doesn't make motherboards either. They contract with Asus or another company to sell their
>motherboards with the Intel brand on it.

Two points:
1. Intel design chipsets for their CPUs. AMD designed one, a while back, and otherwise relies on 3rd party.
2. Intel may well have designed, engineered, and spec'ed the board, regardless of who makes it.

So this is really a statement that Intel has better control of delivering their CPU capabilities to the end user than AMD, independent of the raw capabilities of those CPUs.

Re:AMD Vs Intel: Round 8

[ciroknight]

I believe that AMD had this technology [wikipedia.org] before Intel ever started in on it.

No offense, but you lost me right about here. The Athlon 64 and Opteron (and the Clawhammer/Sledgehammer chips as a whole) are fundamentally a whole different direction than the Core Duo. While they're aiming towards the same goals (really damned fast x86 code execution), they get there in two entirely different ways.

The idea behind the Athlon 64 and Opteron chips were to attack Intel where it would hurt them most, the midrange server section of their business. AMD realized that Intel sells more of these machines, and the maintainance contracts on these machines mean that they're going to keep coming back to you for more of them, even 5 years down the line when your chips are virtually "obsolete". This is broadcasted very loudly in their choice to integrate a memory controller onboard their CPUs; in order to upgrade chips with an integrated memory controller, you have to replace the whole board, and managers aren't going to want to do that very often. Your chips are cheaper overall (because they don't have to have external logic to drive the memory controller anymore, and they were cheaper to begin with), but it locks you into AMD as a company, and locks you into that chip (a slam dunk victory for AMD).

The Intel Core philiosophy was something completely different; it was reactionary in the sense that the Pentium 4 and Netburst were sputtering to the end of their performance gains, way earlier than Intel could have prediticted. But at the same time, Intel has always been known to make great mobile chips, and the Intel Core Architecture was built on a mobile chip platform. It was the logical choice, even in March 2003 when the Pentium M/Core Architecture first made itself available to the world as Banias. The Athlon 64 didn't even make itself available on the market until April (Opteron) or September (Athlon 64) of that year.

Better late than never? Yeah, of course. But the point is, the Opteron was meant to be a server chip and take back the market from Intel and is completely succeeding. The Core chips were entirely meant to be Mobile chips, and due to technology trickledown, we're starting to see that Mobile chips are just as much at home in desktop computers.

And, I know you werent' trying to make yourself out to be a complete and total AMD fanboy in your post, you entirely came off that way, especially without knowledge of the product itself. I don't care particularly for either company, just the fastest chips I can possibly get my hands on, and right now that's the Athlon FX, but in a few months that's going to be Conroe.

Re:AMD Vs Intel: Round 8

[TheRaven64]

Have you even tried a multi-core or SMT processor?

...

OOE has been available since the P5 or Pentium days. Every mainstream processor architecture bar IA-64 (and maybe some MIPS cores) uses it.

There is a big difference between SMT and multi-core. SMT provides multiple contexts in a single core. This is very useful for reducing latency and increasing throughput (two things which are usually a trade off).

SMT improves throughput since any kind of hazard in one instruction stream, the CPU can continue to execute instructions from the other one(s). It also works particularly well with branch miss-predictions, and anything that requires a memory access, since the CPU can continue doing useful work while it is waiting for the memory controller to return.

SMT improves latency, since it reduces the cost of a context switch. Context switches between scheduled threads executing in SMT contexts are free. This reduces the number of context switches required overall, which can dramatically improve latency.

It is worth noting that many of the advantages of SMT are the same as those of OoOE, and so good OoOE is not as important when you bump up the number of contexts, since you are no longer stalling if instructions are scheduled in the wrong order.

Oh, and for reference, all (most?) of the SPARC CPUs are in-order, as is the Cell and the PowerPC used in the XBox 360. They are all a lot more mainstream than IA64...

Re:AMD Vs Intel: Round 8

[default luser]

Right, there are two camps for the "high-end" branch prediction concept:

Camp 1: devise adaptive, multi-component prediction systems that offer both fast and accurate branch prediction. Waste hardware purely for branch prediction.

Camp 2: Use the compiler hint if available, otherwise execute both paths, and throw away the incorrect processing path. It seems cheaper on the surface, but you have to realize: all that extra fetching to process both paths in reasonable time mean more fetch bandwidth and more execution units required just to keep up.

Obviously, if your code contains lots of branches that cannot be predicted by the compiler hints, the Camp 2 solution is going to perform worse. The advantage of active branch prediction is that you never have to recompile the code to keep the branch hints "optimized" if your datasets change.

It doesn't really matter which camp you choose, because both camps waste space on a Branch Target Buffer (predicts the TARGET of the branch) anyway, and that's often more costly than the branch direction predictor. Even the Itanium has a BTB, that's how it can instantly start executing the "branch taken" case.

The Itanium is just taking advantage of a serious architectural flaw to perform branch prediction. Even modern compilers are inserting 20% or more "noops" into the instruction stream, why not take advantage of that underutilization. On any other platform, it would be a very stupid approach to branch prediction.

Re:AMD Vs Intel: Round 8

[Tracy Reed]

Those forms of consumer revolt deny the company money. Just like denying a car gasoline this will cause the company to eventually stop functioning. I think the OP made a very good point. There is no point in treating a company like a person. Companies are also completely amoral.

Re:AMD Vs Intel: Round 8

[evilviper]

Those forms of consumer revolt deny the company money. Just like denying a car gasoline this will cause the company to eventually stop functioning.

The car, however, doesn't know you're going to stop giving it gasoline if it doesn't do what you want, and can't possibly respond. So TERRIBLE analogy. A company is certainly far closer to a human than a mindless machine.

Re:AMD Vs Intel: Round 8

[bigpat]

Also, on a somewhat note - never care about a company, because the company cannot reciprocate your feelings.

If Intel comes out with a better, cheaper processor tomorrow, don't buy the AMD one, buy the intel one. Their is no point treating a company like a person.

Well, the poster specifically said he did not care about either company, just that there was still competition. And I think there is a assumption of parity when you suggest buying the product from the company with less marketshare.

Especially, as you find yourself buying a greater volume of products or more frequently, the overall health of the market is an important consideration in your self interest. It is foolish to let yourself become locked into just one Vendor or manufacturer for a class of products that you buy regularly. Or to support one company to the exclusion of others to the extent that you will be left with no real choice down the road.

People need to understand the effects of their purchasing decisions both on a personal and corporate level. Sure if there is a clear basis of superiority for less cost, then go with the better choice and hope the competition picks up in the future. But if all other qualities are nearly equal then buying from a competative company that happens to have less marketshare will go a long way towards ensuring a healthy marketplace.

and this is why...

[escay]

overheard at the intel core processor design lab:

"Brian, there's a message in my cereal! it says OOO..."

Re:and this is why...

[greypilgrim]

Dammit if you're gonna quote Family Guy, at least do it properly!

"Brian, there's a message in my Alphabits. It says 'OOO'"

"Peter those are cheerios."

See, it's just not as funny if you forget the Alphabits part.

Out-of-Order Operation Handling And High Hopes

[digitaldc]

Do you think that when we open up a new Apple(TM), we will find a Core(TM)?

Re:Hey Wait

[G)-(ostly]

Just for that, I'm never buying Intel again either.

Re:Apple's noisy Dual Core MacBooks-PCs seeing thi

[mccalli]

Er, wouldn't that be the fan making the noise? CPUs have no moving parts.

No, it's not the fan. It's the CPU's idling mechanism, specifically its power-saving attempt. Up the CPU activity to around 5% and the noise goes away. I'd like to know if that's endemic to dual-core Intels at the moment, or if it's an Apple-specific problem.

Cheers
Ian

OOO? What about AAH?

[m4c north]

and for the dyslexics out there: AAH and OOO

New Intel marketing slogan?

[MECC]

"You can give your heart to Jesus, but your ass belongs to the Core!"

Re:Apple's noisy Dual Core MacBooks-PCs seeing thi

[tayhimself]

Ian. These are often inductor coils on the MB power circuitry making this noise. Go to silentpcreview.com forums and search for coil whine. It happens in PSU coils or/and more frequently on MB power circuitry coils. It is a combination of components that causes it and unfortunately there is not much you can do other than change the PSU/video card etc which are not possible on a laptop. You can douse the coils in electronics grade silicone (which is acid free) but I am not suggesting this. Send it back for servicing if they take it.

Re:Why AMD is better than Intel

[Anonymous Conrad]

Intel's CEO is an economist, while AMD's chief might actually have a clue how a chip works...

So what? Running big business is not the same skillset as chip engineer.

The CTOs, now *they* need a technical background. CEOs certainly don't, that's what Harvard MBAs are for.

Article summary

[Animats]

Here's the short version:

• Intel has a new x86 CPU coming out. It's basically an improved version of their last few CPUs, but because fabs have improved, they can fit more execution units in.
• The wide "vector"-like instructions now have real 128 bit execution units.
• There's a new branch prediction scheme for loop exit, which seems clever.
• Hoisting of loads from an unknown address is now performed more speculatively than it used to be, at the cost of some complexity in the retirement unit.
• The author of the article has no clue that the retirement unit is the hard part. That's where all the hard cases end up being unwound.
• No benchmarks yet.

That's what's in there.

Re:Article summary

[Hannibal_Ars]

"Hoisting of loads from an unknown address is now performed more speculatively than it used to be, at the cost of some complexity in the retirement unit."

I think you mean, "hoisting of loads above a /store to/ an unknown address." If you're going to pretend to school little old clueless me about the complexities of memory reordering and retirement then at least learn the difference between a load and a store.

Why So Few Registers?

[jinxidoru]

This is slightly off-topic, but can someone please tell me my Intel continues to have so few registers? I have done some assembly work on x86 and it is always such a chore because I spend 75% of the time moving data in and out of registers. I would love to at least be able to do a double for loop without having to move my iterators. It's just so frustrating.

Re:Core has OOOE?

[default luser]

That would be due to several "lessons learned" as Intel developed Itanium.

1. The instruction overhead due to extra hint bits, etc, means Itanium instructions are much larger than x86 32/64 instructions. With the addition of poor branch performance (read: more wasted instruction bandwidth), the need for large, high-bandwidth caches makes Itanium expensive.

2. The compilers have not caught up. EPIC lacks OOOE, and has poor dynamic branch prediction hardware, so it is at the mercy of the compiler.

Core retains Intel's original insights made with the P6:

1. x86 is hard to decode (takes more silicon), but it takes less bandwidth than other instruction formats. Bandwidth is even more expensive than the cost of more complex decoders, just look how expensive it was for Intel to add full-speed cache to the original Pentium Pro, and how pricey the Itanium is with huge, fast on-chip cache.

2. OOOE + Branch Prediction + internal RISC is king. One reason the original Pentium never performed well is because it could RARELY execute more than one instruction per cycle. Thus, it performed like a fast 486 unless the code was recompiled as Pentium optimzed. The P6 was designed to avoid the reliance on compilers to improve performance, as it could optimize code in any condition. Funny, we didn't start seeing Pentium-optimized code on the market until the P6 started taking over.

Core is just a logical extension of this concept. The predictor is more accurate, there are more instruction decoders, more ALUs and SSE units, and more retirement units. The only reason Core seems to groundbreaking is because we didn't see it in small, evolutionary steps.