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

[bhima]

As an old hippy socialist Apple user I completely agree with pretty much everything you said. Although some of the ideas that caught my interest in the IBM PPC970 apparently can be found in this latest Intel offering... still I'm mostly in the middle of my upgrade cycle... and I expect quad cores before I upgrade my PowerMac and a second generation of widescreen MacBook before I update my laptop.

Also I would be interested in a Cell / Power based content creation workstation --- but not from Sony, I've given up on them.

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

[kbogert]

Really? In my experience, the only motherboards I've had to replace were intel, one just this last week an 845BG thats only 2 1/2 years old. But I also have two Dell Dimension 800's that I use as servers which are up constantly, so I guess my opinion is in the Pentium 4 era quality went down.

Re:AMD Vs Intel: Round 8

[Otter]

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.

Perhaps (I'm not sure what "this technology" refers to), but so what?

Re:AMD Vs Intel: Round 8

[Anonymous Coward]

I'd like to point out that companies are still ran by people, even if it doesn't sometimes seem that way because the people running them apparently forget this as well.

You can go on as much as you like about them existing solely for the purpose of making a profit but in the end people should behave ethically in everything they do instead of hiding behind artificial constructs.

From this follows that you can actually care about the group of people that make up a company and they can care about you. This is most often apparent with very small shops.

Re:AMD Vs Intel: Round 8

[tayhimself]

I believe that AMD had this technology before Intel ever started in on it.

IBM's Power 4 was dual core. Heck there are already multi-core versions of Power4/5. They do this by having putting multiple dual core dies on the same package (Multi chip modules afaik).

AMD is no longer too concerned with dual core but has moved on to targeting multi core.

See above

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.

Have you even tried a multi-core or SMT processor? Linus (yes him) posts on RWT forums and he frequently fawns over the difference SMT/HT makes in user experience.

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.

OOE has been available since the P5 or Pentium days. Every mainstream processor architecture bar IA-64 (and maybe some MIPS cores) uses it. IA-64 is VLIW and in-order relying on the compiler to schedule instructions. Ahh, the Cell and X360 cores are also in-order AFAIK. But in order execution is the recent trend so to speak not OOE. The late generation PPCs were great OOE processors as well.

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.

WTF is this? This is not how multicore works. Go read something. How does this shit get modded +3 insightful is beyond me.

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.

Ahaha a fan-boy. That explains it. BTW, I've built 3 intel and 4 AMD systems in the last 3 years. I dont know what I will buy next. The dual-core 805 D is very attractive at $135 but a pain to silence.

Re:AMD Vs Intel: Round 8

[Eivind Eklund]

I vote with my money: I consider Intel to behave badly, so I don't buy Intel if there's a reasonable alternative.

This is personal responsibility: I will try to avoid moving resources to a company that behaves badly, instead trying to move they resources where they do good.

Eivind.

Re:AMD Vs Intel: Round 8

[DesertWolf0132]

I get that alot when I relate my story. I also understand that I am a sys-admin and don't always have time to research every detail of each core. It is very possible the board-chip combination I picked was not optimal and thus created detrimental performance. I would often use supplier recommendations and seeing as they are there to sell me something they might not have taken the time to choose the best combinations. All the Intel board/chip combinations I picked using the Intel recommendations and they also tended to be higher end than the AMD systems I built. Like I said, this is in my experience only and not to be taken as enough information to judge AMD poorly.

Re:AMD Vs Intel: Round 8

[Anonymous Coward]

Actually, the problem is probably in the chipset, rather than the processor. Old AMD-compatible chipsets were really flakey and full of incompatibilities (I remember way back when getting an nvidia card to work on AMD was a crapshoot... and only now are there nforce chipsets for intel ;) Not just AMD's own chipsets, but chipsets by via etc, for amd processors were pretty bad.

My own motherboard (I think its around 4-5 years old) uses the AMD768, which has a known errata, which paraphrased, reads like this: "AMD768 occasionally fucks up. We don't know why, and we can't fix it, but we've got a machine with a PS/2 mouse here that it's never happened to." Sure enough, I plug in an old ps/2 mouse (it now hangs from the back, i still use my usb mouse) and the hard locks and drive corruption that would happen every few days if I didn't reboot the machine nightly hasn't happened since.

Re:AMD Vs Intel: Round 8

[99BottlesOfBeerInMyF]

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.

It is interesting that you start your comment by trying to build a dichotomy. Almost all the responses to your comment have been from people who (unlike you) don't care about the companies, only the products and results.

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.

Okay, you've established yourself as a loyal customer who is not interested in evaluating all the options and making an informed and impartial decision. So why should anyone care what you have to say about it? You've just admitted you're both uninformed and biased.

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!

The idea behind capitalism is that people buy the best product, thus motivating companies to strive to be the best. Just buying product from whichever company has a smaller market share is anathema to said ideal.

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.

I really don't understand this thinking. When I need a new system I look at all the available products and pick the best combination for my purposes and price range. I can understand the concept of a strategic purchase, but don't see the case for it here. My own evaluation of the market right now would lead me to look at either an AMD or IBM system for a desktop, AMD for servers, and Intel or IBM for a laptop. I don't care who makes them, just what they can do for me.

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

[pintpusher]

...but I simply was in agony in high school when Pentium 100s costed an arm and a leg.

I'm not going to beat you for choosing AMD over Intel. I'm not going to beat you for claiming that your loyalties will switch on a moments notice. I'm not even going to beat you for getting a well modded first post.

No, no, no. I'm going to beat you for being a brat.

Why? Because when I was in high school, I simply was in agony because 6502's cost an arm and a leg.

whippersnapper.

Re:AMD Vs Intel: Round 8

[evilviper]

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.

You're comparing one brand of motherboard (Intel) with a very large GROUP of motherboards (any Socket-A compatible). For it to be fair, you'd have to compare something like Asus Intel motherboards to Asus AMD motherboards.

That said, I believe the problems I have had with AMD come from the fact that none of the boards are made by AMD.

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.

So, you might as well say that Sony makes great optical drives, while Lite-on makes junk. (Sony re-brands Lite-on drives)

Re:AMD Vs Intel: Round 8

[level_headed_midwest]

"Have you even tried a multi-core or SMT processor? Linus (yes him) posts on RWT forums and he frequently fawns over the difference SMT/HT makes in user experience."

He's right, and it does not matter who is the CPU maker. I have an Athlon X2 4200+ dual-core machine that I built (runs SuSE 10.0) , and have put in some butt time on a dual 2.8 Xeon Irwindale machine that I also built (but it is not mine, I just run it in a lab, and it runs FC5) I have used a Pentium D 820 machine a very small amount (XP Pro), and also a dual 2.0 G5 PowerMac (Mac OS 10.4.)

In all of the cases, the second CPU really does make a big difference in the user experience if you have multiple apps open, which I certainly do and most people do also unless they are gamers. I would say that the Windows machine benefitted most from the second core as Windows tends to bog down for a while after a load has been removed as it has to process the delayed tasks, and the second core did these while the first one was working.

Re:AMD Vs Intel: Round 8

[antime]

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.

The original Pentium was superscalar, but in-order. The big "wow" thing about the P6 was that contrary to everyone's expectation, Intel had managed to make an out-of-order version of the x86.

Re:AMD Vs Intel: Round 8

[oringo]

Mod the parent up! Anyone who has been educated in computer architecture would agree with the parent and know that grandparent knows nothing about it. Thank you for posting, parent, I was going to post a very similar comment but you beat me to it.

Just one addition, branch instrucctions don't hold up processors, memory load and floating point instructions do. The problem with the branch instructions is that the branch decision may come too late, and the penalty depends on the depth of the pipeline.

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

[fastgood]

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.

I've seen a single 2.0GHz duo core processor (T2500) benchmark like a 1.8GHz Sempron (aka 3000+).
Tie score: Not bad for a mobile processor, and not bad for a value desktop chip with just 128K L2 cache.

That was operating off the old premise that good "laptop" processing lags behind adequate desktop useage.

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.

Not me. The dirty little AMD secret we all know is the current outrageous pricing. Proof is documented:

http://web.archive.org/web/20020603180418/www.amd. com/us-en/Corporate/VirtualPressRoom/0,,51_104_609 ,00.html

AMD Athlon(TM) XP (May 2002)
2000+ $193
1900+ $172
1800+ $160
1700+ $140
http://web.archive.org/web/20030602013858/www.amd. com/us-en/Corporate/VirtualPressRoom/0,,51_104_609 ,00.html

AMD Athlon(TM) XP Processor (May 2003)
2600+ $103
2500+ $89
2400+ $84
2200+ $74
http://web.archive.org/web/20040611152643/www.amd. com/us-en/Corporate/VirtualPressRoom/0,,51_104_609 ,00.html

AMD Athlon(TM) 64 (June 2004)
3200+ $278
3000+ $218
2800+ $178
http://web.archive.org/web/20050319092914/www.amd. com/us-en/Corporate/VirtualPressRoom/0,,51_104_609 ,00.html

AMD Athlon(TM) 64 (March 2005)
3700+ $329
3500+ $272
3400+ $223
http://www.amd.com/us-en/Corporate/VirtualPressRoo m/0,,51_104_609,00.html?redir=CPPR01

AMD Athlon(TM) 64 (March 2006)
4000+ $341
3800+ $288
3700+ $238
http://www.amd.com/us-en/Corporate/VirtualPressRoo m/0,,51_104_609,00.html?redir=CPPR01

AMD Athlon(TM) 64 X2 (current)
4800+ $643
4600+ $556
4400+ $467
4200+ $362

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

[Hal_Porter]

If they handing over bloggers to the Chinese secret police I'd boycott them.

FUD and dumping don't justify a boycott, at least to me.

Re:AMD Vs Intel: Round 8

[HoboMaster]

It's just a crapshoot with AMD mobos. As a general rule, I stick with ASUS or MSI boards, as both have treated me very well and been very stable. A friend of mine went through 4-5 different mobos in the course of 6 months. Cheap mobos aren't worth it. On another note, I've got an old k6 350mhz that's been running perfect for over a decade now. Now I'm curious as to what mobo my uncle used when he made it. Summary: AMD mobos are a crapshoot, but 90% of cheap ones are complete shit. Find one that works for you and stick with it. Everyone I know has a certain brand they swear by that works great for them that doesn't work for anyone else (cept ASUS, everyone likes those =P).

Re:AMD Vs Intel: Round 8

[MrFlibbs]

Just to clarify a few things:

1) OOO was not used in the original Pentium. It debuted (for Intel) in the P6 family. This includes the Pentium Pro, PII, & PIII. The P4 is also OOO, but is not a P6 derivative.

2) Super-scalar does not require multiple pipelines. The term refers to the ability to run simultaneous execution units, but these can be fed in various ways. In the Pentium, there were indeed two separate pipelines. However, the P6 dispatches micro-ops (uops) to multiple execution engines from a single pipeline. This is part of the OOO scheme, as the uops complete in a non-deterministic order. The results are held in a re-order buffer and retired in-order.

3)There are various trade-offs between in-order and out-of-order execution. Using the compiler to pre-extract parallelism simplifies the hardware, but a single binary won't be optimized for all CPUs within the same family. For example, upgrading to a CPU with a larger cache may require re-compiling the application in order to take advantage of the new hardware capability.

As for AMD vs. Intel, what's the big deal? AMD processors have been faster for the last couple of years. Intel's Conroe will reclaim the crown when it debuts next quarter. This doesn't have to be a religious war -- just buy the best system that fits your budget when you're ready to upgrade.

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

[Moofie]

Why do I care if it's the AMD processor that's shoddy, or the chipsets that are required to make the processor work? I don't care where the problem is...I care that my PC doesn't randomly reboot itself. If I buy an Intel board with an Intel chip, I'll be fine.

I have the same sorts of problems with my Athlon system, and it's cured me of ever buying another AMD processor. Once bitten, twice shy.

Re:AMD Vs Intel: Round 8

[DesertWolf0132]

I can agree with that. I had an old Gateway box with an Athlon 650 (I lost it in a divorce) that had this weird glitch on the board. Every few times I would boot it the keyboard and mouse would stop working. I called support and the tech said to swap the ps/2 ports they were plugged into. I did and all of a sudden they worked with the keyboard plugged into the mouse port and vice versa. After a while the mouse stopped working so I replaced it with a USB mouse and never had a problem again.

Re:AMD Vs Intel: Round 8

[DesertWolf0132]

Everything from an old copy of PCPro to the latest Professional Diagnostics from Ultra-X. All of the RAM was factory Crucial RAM recommended specifically for that board. That said, it is not entirely unheard of.

Re:AMD Vs Intel: Round 8

[DesertWolf0132]

Thank you. You articulated my point better than I would have.

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

[philthedrill]

I'll post some corrections.

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.

Out-of-order execution has been standard on x86 processors since the Pentium Pro. Itanium doesn't have OoO, at least so far. Its goal has been to reduce hardware complexity by letting the compiler handle the instruction scheduling. As for programmers, OoO is invisible to them. Instructions in our basic superscalar pipeline flow like so:

| Fetch | Decode | Schedule | Execute/Mem | Retire |
| In order | In order | OoO | OoO | In order |

OoO is execution only and programmers have no idea whether instructions are shuffled or not.

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).

No, in most cases, a cache miss. Branch prediction is what allows processors to continue execution speculatively until the results of a branch is known. If a processor stalled on every branch, you have no idea how slow machines would be.

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

You don't need multiple cores to compute both branches. In fact, you don't even want to compute both branches - it's extra hardware and current branch prediction schemes achieve accuracy rates of > 95% (depending on the workload).

Re:AMD Vs Intel: Round 8

[FireFury03]

For example, I have two 5 year old systems, one with a Gigabyte AMD Athlon board, and one with a true Intel P3 board.

I used to like Gigabyte boards ever since I got my old TX board for my P200. But I don't think I'll be buying any more Gigabyte boards for now:

• My server had a Gigabyte GA7VAX (I think) which went up in a cloud of smoke (capacitors blew - lots of smoke).
• My MythTV box has one of the smaller Gigabyte Athlon/VIA boards. WoL doesn't work even though there's an option in the BIOS, ACPI S3 mode doesn't work (it just powers off the whole damned box instead of suspending to RAM), lm_sensors can't get any sensible temperature readings off anything and you can't get temperature readings off ACPI.
• The replacement motherboard for my server is another Gigabyte board. Again, can't get much in the way of temperature or voltage readings with lm_sensors and ACPI won't provide a CPU temperature reading.

Also, all the Gigabyte boards have only the clip-on heatsink mounts rather than also having the bolt-through holes in the board, so some heat sinks and water cooling kits either won't fit at all or require some modification.

Both have insane cooling so the board temps never go over 100 degrees.

100 degrees sounds really far too hot to me. My air-cooled Athlon XP 1900+ runs at ~60 degrees (CPU temperature). My water cooled Athlon XP 2100+ server runs at 30 - 40 degrees. If the CPU temperature exceeds 70-odd degrees the whole thing goes really unstable.

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

[amjacobs]

I think the assertion that designers are "moving away" from OOE is false. Some newer processors are in-order, the Itanium is the main one. But, it's not like designers are moving en mass away from OOE.

Re:AMD Vs Intel: Round 8

[ooze]

I fpeople would buy the better, cheaper processors, then x86 would have been long gone.

Re:AMD Vs Intel: Round 8

[trilliwig]

From TFA:

But for Intel, having multicore in mind doesn't mean quite the same thing that it means for Sun or IBM. Specifically, "multicore" doesn't mean "throw out out-of-order execution and scale back single-threaded performance in favor of a massively parallel architecture that can run a torrent of simultaneous threads." Such an aggressive, forward-looking approach is embodied in designs like STI's Cell and Sun's Ultrasparc T1.

Also, contrary to the first poster's statements, Intel's Itanium architecture (IA-64) uses an in-order implementation, relying on the compiler to extract instruction-level parallelism. So there is a definite trend in the industry to forgo the hardware complexity of out-of-order execution in favor of software methods of extracting parallelism.

Re:AMD Vs Intel: Round 8

[BrianGKUAC]

I'm fairly certain he's not referring to 100 celcius.

Re:AMD Vs Intel: Round 8

[FireFury03]

Using the compiler to pre-extract parallelism simplifies the hardware, but a single binary won't be optimized for all CPUs within the same family.

It's been a while since I looked at the IA64 architecture, but ISTR it addressed this issue by tagging instructions. I.e. an instruction word contains 3 instructions which are executed in parallel and a tag. Other instruction words containing the same tag are allowed to be executed in parallel too. So your basic processor can execute 3 instructions in parallel (1 instruction word), the faster processors could execute 6 in parallel (2 words), etc. The compiler has already told the processor which of the instruction words can be parallelised through the tagging so as processors get "wider" they can just process more instruction words in parallel so long as they have the same tag, thus no recompilation is necessary.

The IA64 architecture really is quite a nice design, just a shame that compiler technology never seems to have caught up enough.

Re:AMD Vs Intel: Round 8

[GWBasic]

Intel publicly demonstrated quad core a month ago: http://news.com.com/Intel+demonstrates+quad-core+P C%2C+server/2100-1006_3-6046880.html?tag=nefd.top. From the article:

Quad-core models are the next step and a further indication that Intel's effort to improve performance focuses more on adding more cores than on increasing a chip's clock speed.

Re:AMD Vs Intel: Round 8

[Nimey]

Meh. I haven't noticed any real difference between the two. Really, the only mainboard failure I remember hitting me was the bad-capacitor problem, which was due to the mobo and capacitor makers cutting corners.

I don't overclock and make sure to keep my machines reasonably cool. I try to use good power supplies.

Re:AMD Vs Intel: Round 8

[Hal_Porter]

The parent post is a perfect into of how to get modded up

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.

Reverse Psychology 101 : Slashdot mods will never mod you down if you say this, because the think that slashdot should be a haven for unpopular opinions persecuted by the corrupt, capitalist main stream media. It also encourages people to back you up if you make a few 'mistakes' in your post and start a huge flamewar.

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.

Yeah, it took courage to type all this in, as well as speed. If Galileo was alive today, he'd be too cowardly to post like this. Martin Luther king would no doubt be afraid to lay into Wintel on slashdot. Remember, your opinions are not mainstream, but that's because the mainstream is dominated by stupid Neurotypicals

I believe that AMD had this technology before Intel ever started in on it.

You're confusing dual core with Core. AMD had the first dual core chip, and it was widely recognised as being a cleaner design than Intels dual core P4. The P4 wasn't designed with dual core in mind, and it's pipeline was too long, because it was designed to get to higher clock frequencies faster. It turns out that the process shrinks ground to a halt because of leakage current, and ultra long pipelines perform rather poorly on desktop stuff compared to processors like the Athlon which are more conventional. So the P4 designers bet on the wrong things.

Essentially Core is Intel learning from the A64 and Pentium M. And prioritising dual core performance over clock frequency from the start. Now they're betting on much the same things as AMD. They've cloned AMD64 too. It's interesting stuff.

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.

Translation : Yeah, I know about how the chip really works, so I don't need to bother with tiresome competitive benchmarking. Everyone knows those are rigged by evil capitalist big companies.

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.

Translation : "I know the technology so much, I don't need to understand details like microop fusion. The P4 sucked and so even though they claim to have moved to a more Athlon like pipeline length, and Intel chips aren't more expensive than AMD and they will probably be more competitive in tests and lower power, that's probably just marketing buzz."

Note the benchmarks I quoted are of Yonah, a low power laptop chip that almost matches the performance of a similarly clocked A64. It's at least plausible that Merom, with more of an emphasis on performance than power will leapfrog Athlon 64 in performance terms in much the same way that Athlon 64 leapfrogger the P4.

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.

Genius again : the image of a poor student, oppressed by the evil capitalists. Vengeful feelings to said capitalists.

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 wa

Re:AMD Vs Intel: Round 8

[default luser]

"Just one addition, branch instrucctions don't hold up processors, memory load and floating point instructions do. The problem with the branch instructions is that the branch decision may come too late, and the penalty depends on the depth of the pipeline."

No. For someone who claims to be educated in computer architecture, you are sadly lacking in understanding. Unfortunately, all you're thinking about is the mispredict penalty.

Floating-point multiplies are FAST these days. Memory load issues can hold up a pipeline, especially if the cache heiarchy has not been designed for high hit rates (too low capacity, bad cache block design, etc), but that's not typically the case these days.

Branches are one of the biggest issues for the x86 32/64 platform to handle because of the non-uniform instruction size, and because ACCURATE branch predictors are SLOW (multi-cycle). What this means is instruction decode + prediction ends up taking multiple cycles, and during those cycles the processor keeps reading instructions as if a branch wasn't taken. By the time you have a branch decoded, fed into the accurate branch predictor, and predict taken, what do you do with all the instructions in the decode pipeline?

You flush them. That's wasted fetch bandwidth, plus you have bubbles in the execution pipelines while the fetch pipes refill. THAT IS COSTLY.

The Pentium 4 uses a trace cache to get around this issue. It keeps a record of all instructions executed in actual branch order, unfragmented, based on their previous branches. Unfortunately, there is a big hit if the trace cache mispredicts or doesn't contain your instructions, because then you have to go to L2 cache. It's not optimal, but it does work well.

The optimal solution? You have FAST but inaccurate branch predictors that can work in a single cycle, and you make fast decicions about branches. You also have to predict the branch target address using a branch target buffer, because calculating it would take far too long. Thus, you can keep fetching immediately, even if the branch is "taken".

The final two pieces to this system are a pipelined accurate branch predictor that can override the fast predictor, and of course, the real branch verification hardware (which causes the pipeline flush you commented on if the direction predictor is wrong). This system guarantees you much less instruction pipe stalls while you wait on an accurate branch prediction. Unfortunately, it is expensive to implement, so most processors use some sort of compromise system (like the Pentium 4).

Re:AMD Vs Intel: Round 8

[drinkypoo]

VIA has always been one of the least reliable chipsets. I try to use the AMD chipset whenever possible. Failing that, I'd rather use ALi than VIA.

Re:AMD Vs Intel: Round 8

[drinkypoo]

Intel is fucking sleazy. They weren't even going to replace FDIV-bug processors until the market screamed at them so loudly that they realized that AMD would eat them within a year if they didn't fix it, because no one would ever trust them again. Capitalism is one thing, but if you just follow simple capitalism (buy the cheapest product that does what you want) then you're rewarding bad behavior, too. AMD is simply better at doing what they say than intel, so even if AMD cost a bit more, I would want to patronize AMD.

Re:AMD Vs Intel: Round 8

[drinkypoo]

The problem with your argument is that SMT frequently produces slower results than not using it on the same processor. It might be a good idea, but if it is, it's only highlighting intel's incompetence - good design, poor engineering.

Also, the only time SMT provides a significant benefit is when the processor's functional units are going unused - or, in other words, when the processor is operating inefficiently, perhaps due to bad branch prediction, for which intel is known :P

Re:AMD Vs Intel: Round 8

[pipingguy]

Check your cooling. This is just apocryphal, but AMD chips seem to be temperature-sensitive. A recurring re-booting problem on my dual AMD machine was due to a failing fan in an unused, removeable hard drive tray. It was telling the CPU that there was a failure, which caused shutdowns.

Yes, I use the Windows condoms (updated anti-virus, spyware and latest patches)

Re:AMD Vs Intel: Round 8

[codewarren]

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

That's genius, let's punish the company for making better products and charging less.

Re:AMD Vs Intel: Round 8

[oringo]

Thanks for elaborating my point. What you said precisely explains my point: branch instructions are not slow in nature, but misprediction of branches carries big penalties when you have deep pipelines and slow instruction decoding. Floating point ops are still slow. They are just faster compared to 10 years ago. An integer op still takes much less time than a floating point op. Thanks to OOOE, the speed of floating point ops can sometimes be masked away from users.

Re:AMD Vs Intel: Round 8

[bigbadwlf]

I don't think you sound like a fanboi at all.
Run what's best for you.

I completely agree that competition is a Good Thing, not just for pricing but as long as neither company gets too far ahead of the other, they're also both working like mad to design better products for you and me to use.

As for myself, I've historically been known to purchase Intel for my desktop machines, mostly because I prefer to have my chipset designed by the same company as my CPU.
I recently bought this notebook, and I had the choice between something from the Pentium M line or AMD Turion. In the end I bought the Turion. This wasn't so much because of the CPU, but that I chose ATI graphics over Intel.
I personally feel the difference between Intel and AMD's mobile chips to be negligible, but Intel's "Extreme Graphics" or whatever they call it these days leaves something to be desired.

Sure it's a notebook, but these days that's no reason not to have decent graphics.

In the end, let BOTH companies make enough money to spend on the R&D to develop better products for us all to use, for a price we can all live with.

Re:AMD Vs Intel: Round 8

[TheRaven64]

The Pentium 3/4 were both designed to be inefficient. They achieved relatively good performance by trying to execute any possible code path that could be the correct one, and then throwing away the incorrect ones (between 25-75% of the chip was usually doing work that would later be thrown away). This, obviously, is not a great solution for a chip that you want to work well with SMT. It did, however, give good single-thread performance (which is what most people in PC-land cared about).

Re:AMD Vs Intel: Round 8

[McLoud]

I got the same thing with mine, but it is an Asus motherboard. Try lowering your core voltage 0.5 V and see how it goes.

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

[evilviper]

FUD and dumping don't justify a boycott, at least to me.

I wasn't trying to suggest one at all. I was simply making the point that companies DO respond to how their customers treat them, and have means to "reciprocate your feelings".

Re:AMD Vs Intel: Round 8

[espressojim]

You didn't mention motherboard manufactures, and those have a ton of influence of system stability. Those cheap-ass Via motherboards are just that - cheap.

If you buy a decent mb (nvidia nForce 4 is my personal pick, in a mini configuration to fit in a shuttle xpc), then you're good to go with a rock solid system.

I think the actual processor is rarely the problem, unless you have cooling issues.

Re:AMD Vs Intel: Round 8

[Tracy Reed]

You could also say the car doesn't have a board of directors so terrible analogy. That's not the point. Analogies can hardly ever be taken beyond the immediate context of what is being demonstrated and that is that both companies and cars need something to make them go and without it they stop.

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.

Re:AMD Vs Intel: Round 8

[Psiven]

Thanks for pointing this out. If it's competition from AMD that's driven prices down, than it's reason to buy an Intel not AMD.

Prices for Conroe have been quoted by Intel a little bit. I believe what has been stated is that the top of the line Conroe proc, which is estimated to be about 20% faster on average than an over-clocked AMD 4000+, is actually going to be cheaper.

Must be a result of INtel's large manufacturing quantities. AMD's prices will more than likely go down some as their production capacity goes up.

Re:AMD Vs Intel: Round 8

[LWATCDR]

Well my wife had a PIII that would reboot all the time and lock up. It used an Intel Chipset and CPU.
I think the point is that the chipset issues for AMD are pretty much over now. If you go with an AMD-64 CPU and an AMD or Nividia chipset, use good ram, and a good cooling solution you will probably not have any more stability issues than with an Intel system.
The simple answer is by quality and configure it correctly.

Re:AMD Vs Intel: Round 8

[Moofie]

Thanks for the tip, but all indications are that it's not heat related. Sometimes I have trouble on boot from a cold processor, sometimes it works for days on end before taking a vacation, sometimes it works just fine.

Could it be cooling-related? Sure, I suppose. I'm tired of dealing with it, though, so I'm going to buy a nice newly dual-bootable iMac.

Re:AMD Vs Intel: Round 8

[Moofie]

Uh huh. Or I could buy an iMac, and never worry about it again.

I used to enjoy tinkering with PC hardware. Now it just pisses me off. That's why I am an Apple customer now. I'm willing to pay for less headaches.

Re:AMD Vs Intel: Round 8

[kimvette]

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.

To clarify: it's not Asus (thank GOD) but Foxconn. Were it Asus, specs would change at whim (and never be hinted at in the manual or on the web site) and half the BIOS features would not work, and when emailing for support the reply will invariably be "Upgrade your BIOS" despite your original support query mentioning you have already done this in effort to resolve the issue. Then the next BIOS release, which DOES happen to resolve the issues of the non-working BIOS features, will install just fine but when you reboot you'll get an "error updating microprocessor uCode" message every time you reboot from then on, unless you downgrade the BIOS back to one of the revisions without the much-needed bug fixes.

Thank (insert deity of choice) that Asus does not manufacture Intel boards.

Re:AMD Vs Intel: Round 8

[DrVomact]

FWIW, here's another vote against Gigabyte. I was putting together an AMD system about 6 months ago, and made the mistake of buying a Gigabyte board with NForce 4 SLI. I don't know why...I have no intention of sticking two graphics boards into my PC...it was one of those stupid impulse buys. Anyway, the board runs OK, but has a major heat management issue: the NForce chipset has a thin heatsink and no cooling fan, and there is no room to put one in because the graphics card projects over the heatsink for the darn chipset. The AMD CPU runs incredibly cool--it never breaks 40 C. The chipset, on the other hand, hits 65 when I'm playing games (and I wouldn't be surprised if it went over 70 if I let it).

I installed extra case fans, and glued a little 2" fan where it blows over the chipset heatsink, so it runs at about 45 C...as long as the room doesn't get too warm. So I traded one heat problem (the Intel CPU) for another (the Nvidia chipset), and didn't get what I really wanted: a quiet system. I don't know why the Nvidia chipset runs so hot, but given this fact, Gigabyte should have provided a more massive heatsink and fan--or better yet, a passive liquid cooling setup like the Abit Otes. Bah, now I have to wait for it to break so I have an excuse to buy a new one. I know, I'll disconnect the fans...

Re:AMD Vs Intel: Round 8

[Zeio]

You know it totally agree here. I use Opterons professionally and love the 280's we are using right now. But even in high end server boards, I've had the best luck with the quality with which Intel reference servers and workstations are implemented with.

For example. Chang Sing Song Gung FUTECH Bloody Monster board gets a few BIOS updates and is forgotten. Off to the next chipset. Intel designs are supports for eons, I still have a PPRO VS440FX motherboard with a BIOS that came out MANY years after the board EOLed. I got the board in October 1996, and the last bios was Version 18.00 (eighteen) 8/14/2000, four years later. Talk about support. FYI, it runs Windows 2003 and I got 256MB in that thing.

I've always said to myself, man, what holds AMD back is the "seriousness" of the motherboards. Keep in mind I really favor the Opteron CPU and design and feel that these recent Intel Conroe benchmarks are meaningless until a Conroe machine shows up on www.spec.org. Really. Back to the "not so nice AMD CPU montherboards" argument. Fu Tech Asus MSI Chinatech Chaintech BFG Dinosaur BLOODY Monster LANPARTY motherboards are too "kiddie." Look, this is serious, expensive stuff. I do see chipset fans die on the TAIWAN MONSTER boards way too soon after being born (within a year/or two). I do see firmware/BIOS updates trail off. I do see BRUTAL spelling/grammar mistakes in the BIOS. I do see support for non-Windows operating systems a complete joke when using TAIWAN MONSTER motherboards (Intel has lots of WHQL drivers and LOTS of support for "other" OSes.).

Now with Intel they have a host of problems per board. But they are well documented. This fails, this heat sink retaining mechanism can fail etc. The failure modes of the product are documented and analyzed. BIOS, firmware and drivers are updated well past EOL. Product lines change little, "AUTO" settings are conservative and work stably, and the whole thing feels audited rather than a bunch of goofballs "mixing up the mess" "like bobcats on booze." Check ASUS's site for errata. HAH. And I like Asus ok, but the support framework sucks donkey genitals.

The AMD boards, from Tyan, to Arima/Rioworks, to Asus, to MSI, to Gigabyte, to whomever. Irritating. Even with Supermicro. I see a wild host of chipsets, junk IO, south-bridges, garbage SATA chips, jackass sound chips and general garbage silicon littered about from ATI (GayTI chipsets are horrible), SiS, Via, NVIDIA and whatnot. The only boards I really like are the AMD 8111/8131 boards. They are pure. But they are LONG in the tooth and have AMD hasn't come out yet with a 100% native chipset that does PCI-Express (that I know of.) I've even seen server works getting back into the action lately in AMD land, along with NVIDIA (a HORRIBLE chipset company with regards to Linux, Intel is much better for Linux) I really wish AMD would step up to the plate and banish this random cruft and define a reference platform.

I've had success with the D875PBZ and the new D975XBX is a dream of a motherboard for not much money and offers a great home for the upcoming Conroe. It is too bad that lame CPUs had to be strapped onto the D875PBZ. Its also too bad Intel hasn't learned to put the north-bridge on chip. Intel did dabble with the dark side, when ECC wasn't available. Remember the BX/GX chipsets supporting everything under the sun with regards to RAM? The MCH, the rambus , and all the cheap assed non-ECC capable chipsets with stupid memory limitations (i815 only can take 512MB, what a stupid stupid stupid joke) were very bad, and the reference boards, while well documented and supported, I was angry at Intel for chinsing out the product line. This is serious stuff, it needs to be documented, coherent \, offer a range of features, and be a little bit more premium than a Fry's special.

I've done ok with pure AMD 8111/8131 boards, but always feels they are chinsy. They work well, but would like to see one of those clean 100% Intel designs, like if AMD were to make the whole reference implementation from top to

Re:AMD Vs Intel: Round 8

[twitchingbug]

SMT will generally degrade performance of each single thread that you're running. but if you take 2 threads and run them on an SMT processor, the overall throughput will be faster. if you've stalled on a memory access, which i think is on the order of 100 clock cycles, then you might as well do something useful in those wasted clock cycles. Of course, there's some cost to switching out contexts.. probably about 10 cycles or so to swap out and swap back in. it's that cost that decreases the performance of your single thread. SMT was good for Netburst since clock speed was high and there was a lot of time to do otehr work while you're waiting for data to be fetched from memory - it doesn't necessarily have much to to with bad branch prediction, altho waiting for an instruction fetch from a mispredicted branch may or may not cause a pipeline stall depending on the code and the icache.

Re:AMD Vs Intel: Round 8

[twitchingbug]

The Pentium 3/4 were both designed to be inefficient.

I think it might be more accurate to say that they were optimized for single thread performance. Well the P4 was really optimized for clock speed. :P And you're misrepresenting what the chip is doing. It would take it's best guess at a branch and execute that code. And it would pretty much go thru the same logic as the normal instructions would, except that those instructions would get tagged with some flag that said, "don't commit these results until the branch outcome has been determined." and if it was the wrong path, then it would throw out that code. But i think putting a 75% failure on that is a bit high. From what I remember branch prediction has always been pretty successful. on the order of 95% to (now) maybe 98% accurate.

Re:AMD Vs Intel: Round 8

[wiggle.e]

were they via chipsets or nvidia chipsets? or a mix? i've had bad experiences with via chipsets.

Re:AMD Vs Intel: Round 8

[twitchingbug]

Whoa....

Okay. you gotta separate the what the processor is capable of and what the compiler is capable of.

Camp 1: traditional branch prediction. x86 uses a BTB to see if the branch is taken or not and will fetch that instruction and start executing that branch.

Camp 2: EPIC style - execute both branches at the same time. Throw away the one that doesn't pan out.

I'll get to the compiler optimizations in a moment... but you can see how EPIC would improve single thread performance a ton right? I mean you'd always have the correct branch executed when you got the official result of your branch. Of course the major downside to this is that you waste a ton of hardware doing this, but hey you'll improve single thread performance!

The other bad thing about this, is that there are only so many branches your hardware can do this with - which is why Itanium has a BTB. since 1 in every 7 instruction has a branch, imagine yourself walking down you code path, and all of a sudden you're trying to preexecute not 2 but 3,4,8 paths. You need more hardware support, which is limited so at some point you have to give up and just return to standard branch prediction methods.

okay now compiler time. compilers can take profiling data and knowledge of your processor and rearrange your basic code blocks to optimize performace. Example: Assume that if there's no history for a branch, that the pentiums will assume that the branch is not taken. in code order it can be...

er wish i could draw here, but assume that in code order, code basic block 1 (BB1) has a branch at the end of it. if it's not taken, then it'll got to BB2, if it is, then it'll go to BB3. in your executable the code will be arranged -> BB1, BB2, BB3. Assume profiling information thinks that the branch will be taken most of the time, hence executing BB3. Well this is bad for the pentium since it's branch prediction will assume that BB2 is the next instruction, since the default is to assume the branch isn't taken. So then the compiler can go back an reorder the basic blocks. so your code can look like this: BB1, BB3, BB2 so the default is to fall thru to BB3 - you have to change the branch code and add some jumps at the end of some of the basic blocks, but it will be faster.

incidentally, I don't think modern compilers insert nops in code. I think the processor bubbles the pipeline. If compilers were to insert nops all over the place, then your binaries would be pretty massive.

Re:AMD Vs Intel: Round 8

[evilviper]

That's not the point.

I obviously missed the point. In fact I still do. I guess I gave you too much credit, assuming you were trying to make a point about the inhumanity (amorality as you said later) of corporations.

...both companies and cars need something to make them go and without it they stop.

If that really was your point, it's so banal and inspid that I can't understand why you even went through the trouble of posting it.

Re:AMD Vs Intel: Round 8

[hunterx11]

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

You mean those things that have an almost insignificant effect compared to market forces the vast majority of time? Until Intel starts killing dolphins, only a handful of nerds are going to care.

Re:AMD Vs Intel: Round 8

[spectrumCoder]

Do the gigantic mindless entities that are Nestle and Shell understand and respond to a tiny portion of their market boycotting their goods? They operate in terms of future share price only; if events have no ability to affect this then they won't even appear on their radar. Hence the car/gasoline analogy is good, but imho the premise that boycotting is making a serious dent in the bottom line of Intel or any other multi-national of income is flawed.

Re:AMD Vs Intel: Round 8

[dmiller]

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.

I have yet to see any enterprise server that has had its "chips upgraded" beyond installing a 2nd CPU in a SMP-capable system with only one processor shipped. Never. Not once.

Re:AMD Vs Intel: Round 8

[TheRaven64]

But i think putting a 75% failure on that is a bit high

It sounded a bit high to me too, but that was the figure quoted by the lead architect on the P6 project at a talk I attended a couple of weeks ago.

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...

[Ultra64]

Peter, those are cheerios.

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:Out-of-Order Operation Handling And High Hopes

[rrohbeck]

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

Yes. And a WORM, either the SuperDrive or the more basic Combo drive.

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

[motiz88]

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

Don't want to be seen as an AMD fanboi?

[hackwrench]

Then cut out all the "personal revelation" nonsense. You are trying to write a comparison between an Intel processor and an AMD processor and don't see why you should try an Intel processor first? You like AMD's explanation better? This isn't a matter of who csn write the most entertaining copy. What does the "support the underdog" sentence even mean?

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

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

[Ford Prefect]

Try the mirror-widget-hack. Download the Mirror widget, start it up in Dashboard for a few seconds, then close it. Your machine will then be silent until it's next rebooted. Battery life will be slightly reduced, but not by much.

There was a run-on-startup utility available from somewhere with the same effect, but apparently 10.4.6 has broken that.

processors are more in-order/VLIW now?

[dsn1337]

processors are moving away from out-of-order execution toward in-order, more VLIW-like designs that rely heavily on multithreading and compiler/coder smarts for their performance I have stopped following processor developments recently, but is this really happening? Between Intel and AMD, the only chip I've heard of that was VLIW and relied on the compiler was Itanium, and I don't see why AMD or Intel would risk repeating that mistake* again any time soon. *I dont think Itanium was a mistake because it relied on the compiler or had cool hardware (like hardware support for software-pipelining). I think it was a mistake to push for Itanium when their compilers didn't seem ready to take full advantage of it.

Re:processors are more in-order/VLIW now?

[the packrat]

I'm amazed that no-one has mentioned Alpha before this. Remember how Intel got the dregs of the DEC people? Nice to see some of it surface.

The basic stupid assumption of the VLIW people is that magical compiler technology would appear that would allow them to generate code that made use of the chips. Having software critically depend for performance of non-fixed CPU architectures such as numbers of the various execution units and types is sheer lunacy. Anyway, what the Itanic people forgot was that any advance in compiler technology would benefit the Alpha/OOO folks just as much.

Re:processors are more in-order/VLIW now?

[1000StonedMonkeys]

The Cell from IBM, Rock/Niagra/T1 from Sun and the XBox's CPU all throw away out of order execution to fit more cores on the CPU. Depending on what you're trying to do, this can be good (web servers, database servers), or bad (games *ahem*).

Fry baby!

[EraserMouseMan]

It's probably the laptop's power supply. I've only heard one processor make this sound. And that was when I hooked up the power to my motherboard backwards to my 486 many years ago. ;-)

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

[jonny02]

My iMac intel works like a champ and doesn't make any noises, plus my brother just got a MacBook Pro and his is the same way. I would take yours back.. nobody likes a noisy processor :( And as for the joker who wrote this article in the first place.. How about you get yourself a real computer and then write an article begging for forgivness. The AMD has nothing on the Inel CoreDuo, and I'll go a step further and say that microsoft has nothing on apple. If they're smart, they'll make like usual and steal a grip of code from apple so at least they might be able to keep up until apple puts the next thing out. Don't get me wrong, it's not that i don't like you, i just think that you should go and actaull try something before you trash it. Didn't your mom teach you that, "How can you say you don't like brocoli?, you've never even had it!" something like that... anyway i should get back to work....

VLIW vs. OOO processor info

[AcidPenguin9873]

For one /. user's comparison/opinion of VLIW and out-of-order processors:
http://slashdot.org/comments.pl?sid=174483&cid=145 15546

</shameless plug> :)

OOO? What about AAH?

[m4c north]

and for the dyslexics out there: AAH and OOO

Re:OOO? What about AAH?

[SpinJaunt]

Aah comes after you've burnt off your fingers from an OOO Dell, We call this Redefining Value.

Who needs acronyms like OOOE and VLIW...

[tomcres]

Motorola created an opcode that beats them all: eieio

Sing: "Old Macdonald had a processor farm..."

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

[CountBrass]

I have a MacBook Pro and it is 100% silent.

So the answer to your question is: neither.

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:Apple's noisy Dual Core MacBooks-PCs seeing thi

[level_headed_midwest]

He's right. My old laptop makes that noise whenever I push a lot through a network interface (something more than half of the maximum bandwidth.)

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

[mccalli]

Thank you - a very informative answer.

Cheers,
Ian

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.

Re:AMD Vs Intel: Round 8 - motherboards

[bec1948]

FWIW, AMD has recognized problems with motherboards. Since they don't make them themselves there's lots of variation in design, capabilities and quality control. AMD and Radion and ATI have all initiated programs to bring better qualtity control and consistancy to motherboards for AMD processors. Most of these issues are seen in server class rather than desktop class boards, but the problems are still there. At this point, components and drivers are the main cause of system crashes on X86 boxes. The better the quality of the components the more reliable the computer. Remember, these problems may not appear to be hardware related too. They may seem to be caused by software - blame Microsoft! In order to support the performance capabilities of the next generation of processors all of the components from the big ones like memory and NICs and Storage contollers, to the less obvious ones like mother board layer construction will need to be top-notch.

Re:I'll most likely never buy intel again

[Sebastopol]

Hmm, you certainly do sound like quite the authority, and insightful post has changed my mind. I thank you.

Retard.

Re:Yeah! More Noops

[dreamchaser]

If you'd read the actual article you wouldn't ask that question. Most of the steps they've taken are designed to keep the execution units busy and minimize stalls. How well it will work will be determined when we see real silicon.

Time to sell AMD and buy INTC

[RoboSpork]

If Intels new chips live up to the hype, it will help to restore INTC's hurting stock. It will also help to correct AMDs overvalued stock. A year ago the correct move was to buy AMD, soon I think the correct move will be to buy INTC.

What kind of new chips does AMD have up its sleeves to compete with the new Core architecture?

Re:Time to sell AMD and buy INTC

[GoatMonkey2112]

I hope the AMD stock drops. I'd like to buy some for the next time AMD has a superior product.

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.

Re:I'll most likely never buy intel again

[moof1138]

There was a long period of time where Intel cleaned AMD's clock, and significantly surpassed them both in performance and stability. During that time did you say that you would never buy AMD? If so why did you change your mind? If not, well, that's what you are doing now, it was just as stupid then as it is now.

The truth is that there is a performance competition going on. AMD may have the edge now, but there is no guarantee that they will keep it. There's no way to effectively predict what the CPU world will look like in five years. Loyalists who choose to use inferior technology in the future because they love some company (a company that would happily sue fanboys into oblivion if it would raise their stock price by a penny) are just going to be stuck with a lesser technology and a warm feeling about wasting their dollars on it.

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

[x2A]

Fast charging/discharging of capacitors can make them sing in this way. While there're no moving parts as such, changing in electric current causes changes in electromagnetic field, which is a force, thus can create tiny movement.

Core CPU - Truly a bizarre idea

[the eric conspiracy]

Abstracted from the hacker's dictionary,

core
        n. Main storage or RAM. Dates from the days of ferrite-core memory; also still used in the UNIX community and by old-time hackers or those who would sound like them. Some derived idioms are quite current; `in core', for example, means `in memory' (as opposed to `on disk'), and both {core dump} and the `core image' or `core file' produced by one are terms in favor.

=

If now Intel has gone to using old ferrite core memory to perform CPU functions (maybe because of a huge silicon shortage or maybe to get persistance in case of blackouts due to power failures) I predict that this is finally the end of Moore's law, the game industry, the Internet and pretty much everything else dependent on cheap fast CPUs. A new 64 bit Core CPU will now contain 64 little magnets strung on wires.

Of course if the rest of the industry fails to follow Intel's lead, I sure wouldn't want to be a stockholder.

Re:Core CPU - Truly a bizarre idea

[TeknoHog]

On the other hand, 'core' is also used to refer to individual CPUs on the same silicon die. Thus 'Core Solo' and 'Core Duo' show the same kind of imaginative brilliance that brought us the word processor called 'Word' and the windowed user interface called 'Windows'. I'm looking forward to what the ingenious marketroids think of next.

Re:Core CPU - Truly a bizarre idea

[Blakey Rat]

I like name recycling. Look up the last award-winning movie with the name "Crash" and see what I mean... when my parents said they went out and rented "Crash" I did a double-take.

OOOE

[vlad_petric]

"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 [wikipedia.org] processing used on Itanium. But I'm not sure that was too popular among programmers."

Let's clarify a few things: A processor executes instructions either in-order (including VLIW processors), or out-of-order. The former is much simpler to implement, but the latter is much more powerful. Why? because when you miss in the L2 cache and it takes ~200 cycles to bring the thing from memory, it's good if you can do something else in the meanwhile. This is only a performance thing, btw, the programmer doesn't see it. For the same instruction-set architecture you can have both in-order (e.g. Transmeta) or out-of-order implementations (AMD since K6 and Intel since Pentium Pro)

Most high-performance processors these days use OOO (the processors that 99% of the /. crowd currently use to read and post are out-of-order). The notable exceptions are: Sun SPARC (a few things in their instruction set makes OOO very difficult to implement, like instruction windows), the Itanium (designed specifically not to need OOO, but see where it got it), Sun Niagra (the idea there is that a server works better with many simpler, in-order execution contexts than with one bigger out-of-order contexts; don't try to run other stuff though, as you'll probably be unimpressed), and the console chips. I'd add Transmeta, but not sure if they're still alive.

Whoa.

[BrookHarty]

Core will excel on the types of applications that will make up the vast majority of server and consumer code in the near to medium term. And because it's designed for relatively low core-count multicore, it will help the software industry gradually make the transition to multithreaded code.

Ok, the conclusion is off, single threaded cores are for the desktop. Multicore is when you need the highest connections with the lowest latency. Hyperthreading helps by fighting memory latency, but they havent put hyperthreading in it yet.

Now, after they add hyperthreading back in, add 64 bit support, and virtualization like the p4 line, it will truely be the next cpu for 4 years.

Of course, AMD isnt just sitting back and doing nothing.

AMD is looking better and better...

[dtjohnson]

The Intel 'core' architecture looks like it is focused first and foremost on single-core performance but with improved dual-core capabilities beyond the current 'netburst' architecture which was essentially single-core only. For example, the new core memory aliasing described on the last page of the article doesn't look like it will scale very well with more than two cores and even two cores will have performance hits, although it will be much better than the current Intel dual-core processors. The core architecture apparently uses shared l2 cache, though, while the current AMD design uses seperate l2 cache for each core that mirror via hypertransport link and onboard memory controller. The Intel core approach will probably give better single-core performance than AMD but suffer with dual-core or multi-core. Since most software (and benchmarks) don't multithread enough to benefit much from dual or multi-core, Intel wins. But...if future OS software is more multithreaded, AMD probably wins. Since Windows Vista, .NET 2.0, and DirectX 10 all support sophisticated multithreading, Intel looks like they will still be in trouble competing with AMD, even if AMD doesn't udpate their current design.

Let's hear it for the underdog.

[jinxidoru]

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.

What the grandparent was saying is that it's good to support the underdog for the sake of the future. If Intel comes out with an amazing chip and everyone stops buying AMD, then AMD goes out of business. What happens to development at Intel? It slows. What happens to prices at Intel? They increase. Eventually this will get so bad that it becomes profitable for a second company (which is what happened with AMD in the first place). So, while eventually it works itself out, it sure is hell for the consumer in the middle period.

A great real-world example was the web browser wars of years ago. IE came out as the clear winner. In my opinion, they were the best. As a result, they were pretty much the only web browser out there. Did Microsoft continue to innovate? Of course not! They could make more money by diverting that money towards other products that were in competitive spaces. That's why everyone is switching from IE faster than American youth are gaining weight. How much better things might have been if Netscape had stayed competitive rather than being so soundly beaten.

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:Why So Few Registers?

[Wesley Felter]

IIRC, 64-bit mode has twice as many registers. In general, adding architectural registers increases the code size, which may reduce performance due to I-cache pressure. Modern x86 processors have good store-to-load forwarding so that spills and fills are fast; I imagine Intel and AMD are not very concerned with ease of assembly programming these days.

Re:Why So Few Registers?

[jinxidoru]

I imagine Intel and AMD are not very concerned with ease of assembly programming these days.

It's not the ease that is the issue. The issue is the fact that you have to move things in and out of the CPU a lot more because there are not enough registers. Take a look at the clock ticks involved and you'll see that this is actually significant when doing highly processor based calculations.

Re:Why So Few Registers?

[rrohbeck]

This is slightly off-topic, but can someone please tell me my Intel continues to have so few registers?

Because you need to change the instruction set to address more registers, which sacrifices backwards compatibility. Once you go down that path, you might as well revamp the entire architecture and have a backward compatible execution mode - or so it seems. Intel tried that with Itanium and failed. If you want full performance for the old architecture, you can only devote a few transistors to the new one, which means it can't be very much different than the old one. That's what AMD got right. Small evolutionary steps, architecure-wise. Maybe we'll end up with CPUs that have half a dozen excution modes with slightly different instruction sets like in the minicomputer days. Or (shudder) loadable microcode - not just once before the boot like today, but during execution. Like Prime with an instruction set optimized for FORTRAN, another for COBOL, and another for C (which sucked because the hardware was bad at byte-wide memory accesses.)

Re:Why So Few Registers?

[jinxidoru]

Good comments, but I disagree that you would have to change the instruction set. You would have to add to the instruction set is all. Adding an instruction to "mov" into some new register, say "egx", would not make the current instructions stop working.

Re:Why So Few Registers?

[jinxidoru]

No

Re:Why So Few Registers?

[theantipop]

x86 only assigns so many bits to address its registers (3 bits to address 0 to 7, I believe). Increasing this amount leads to a different bit count in the control aspect of the CPU and would cause older CPUs without this functionality to be unable to run this code.

Intel needs asynchronous chip

[zymano]

http://www.pbs.org/cringely/pulpit/pulpit19980402. html

Re:Intel needs asynchronous chip

[non0score]

When I was an undergrad, I knew this grad student whose research topic was asynchronous chips. Guess where he's at now? Yep, Intel, working along the same lines as what he did in grad school. So I'm pretty sure Intel's always been researching and working on these asynchronous chips (or bringing their benefits into their more "traditional" chips).

Re:Intel needs asynchronous chip

[zymano]

Interesting.

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.

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

[motiz88]

Alright then, guess my reply was uninformed and out of place. Thanks for the explanation.

Re:Core has OOOE?

[JollyFinn]

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.

No what makes itanium expensive is that they target a niche which buys only itaniums between 2000 and 4000 USDs the lower end itaniums don't sell. The extra cache is cheap. The instruction cache bandwith is cheap. Its the decoding and scheduling thats 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.

The strength of dynamic branch prediction has nothing to do with epic, except that epic has more ways to completely avoid branching, but there is no reason for settling anyweaker branch predictor than x86. The pipeline is wider and shorter, so branch missprediction penalty is in terms of instructions is about same.

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.

You got it totally wrong. The original Pentium Pro was expensive since the CORE was huge due to x86 support and they couldn't test the core before assembling it with the huge amount of cache, then they lost the silicon area of both cache and core when core failed. Itanium has relatively small core compared to x86. The cache can be considered as maximum of 1/4 of its area for yield purposes these days probably even less. There is something called redundancy used there, and they right now get 4 as much silicon per dollar than when pentium pro was made as addition. As for 60000mm of silicon costs under 3000$ for intel. So they sell their highend itaniums over 50 times the montecitos (next gen HUGE itanium) silicon costs. And montecito will be made in 0.9 process that is getting phased out of x86 production. So die areas comparisons are not equivalent since that process has already a great yield for producing x86 over a year. While 0.65u has twice the transistor density, and has lower yields with big dies than the old process

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.

This doesn't really bring anything new to the table, there is big difference between this and itanium situation. Nowadays there is something called Java. All java gets optimized on new itaniums when virtual machine is improved. Also people do recompiles, since most of the time itanium is running either HP-UX shipped with machine or linux. All the itanium generations from first to now to next itanium generation have been and will be 6 instructions wide. The improvements have been in and will be cache systems and more functional units to have more relaxed issue rules. This compares to 1 instruction wide to 2 instruction wide pentium on a time when performance critical code was written in assembler. So basicly all newer itaniums run faster on code that was optimized for older itaniums, simply because improvements where made in that way. SOME improvement is left on table without recompilation but not huge amounts like in pentiums case. We don't see transition from 6 wide to 12 wide execution which would be equivalent to 486->pentium

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

[LordKronos]

Interesting. I've experienced this before and always assumed it was caused by the CPU fan. I figured the reason it changed with CPU load was due to the fan adjusting its speed based on CPU load.

Not just the chipset, but not the proc

[einhverfr]

I have gone back to using Intel for most of the systems we sell for exactly these reasons. We have had several systems we have sold with AMD's architecture which have become flakey after a period of *months.* One one case, it was unrelated to the mobo or the proc (bad fans) and so I am willing to discount it.

However, in the other cases, the computers would display really odd problems. Linux systems would reboot, Windows systems would blackscreen, etc. One thing all the problems had in common was this: I could not reproduce the problem in my office by plugging in the affected system in there.

I therefore concluded that the problem was that lower-end AMD-supporting Mobo's seemed to be skimping on capacitors, so that in some deployments, they would flake out when the power conditions were not exactly right. Note, replacing the PSU did not resolve the issue, but placing the systems on UPS's did.

Re:Why AMD is better than Intel

[einhverfr]

I think it is really great when a CEO knows enough to have intelligent conversations with the engineers though. Economics and knowledge of the technology go hand-in-hand.

I have never met either CEO so I will pass on judging them.

Cores are independent

[butlerm]

Processor cores do not "talk" to each other on such a low level as to be affected one way or the other. Unless instructed otherwise with special fence, barrier, or lock instructions contemporary CPU cores do not order memory operations for the benefit of other cores at all.

The relevant design issue is where do you want to be on the spectrum of core complexity vs. number of cores. If you simplify the cores, you can fit more on a single die, but single threaded performance suffers. If you make the cores more capable, you can fit fewer, but single threaded performance improves. The first strategy befits busy servers, the latter strategy personal computers and workstations. Many workloads aren't effectively parallelizable, so anything reasonable that can be done to improve single threaded performance is usually effort well spent.

Interesting.

[LWATCDR]

I remeber when I thought the Pentium Pro was a failure since it wasn't faster than the Pentium unless you recompiled and cost a lot more.
Maybe Epic has a future. But you did bring up one point. I would love to see a system like IBM used with the OS/400 become part of Linux.
The System 38/AS400 used an idealized ISA. When software was loaded onto the AS400 it was translated from that ideal ISA into what ever that machine happened to us for a CPU. That is how IBM managed to migrate from the CISC cpu of the System/38 to the Power based CPU of the AS400 without the users having any real issues.

If Linux ever got a system like that in place then what CPU you where using really wouldn't matter. Porting would be come a non-issue.

Re:Interesting.

[JollyFinn]

No its called bytecode.

Re:Interesting.

[LWATCDR]

Byte code is very close in concept except that on the AS/400 it is compiled at install time while java byte code is compiled at at runtime or is interpreted. If there was a JVM that cached the results of the JIT to the disk and then used that out put for future executions of the program it would be very close to how the AS/400 works. The other difference is I would want it to still be a Posix program. It wouldn't depend on java's class libraries but would be used for all linux libraries and executable.

I blame VIA

[YesIAmAScript]

There was no way to make the VIA KT133A systems stable. It wasn't AMD's fault. It's maddening too, because you can almost get them stable, but not quite. I had two different KT133A motherboards (one Tyan, one Asus), no difference. I finally replaced mine with a later KT (KT266A?) and it became stable.

Look up the problems with soundblaster sound cards, they exhibit the problem, but it wasn't Creative's fault.

I've had the same experience as you. I've alternated Intel and AMD, and except for the KT133A they've both been good. The Intels in general have been a bit more stable, but all have been okay except that one chipset.

I recently took apart my P3-1000. It was flawless and cool from day one.