Slashdot Mirror
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.'"
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...
No animals were harmed in the making of this sig.
Well, there was that one puppy, but he is all better now.
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
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.
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.
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.
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.
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...
I am TheRaven on Soylent News
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.
Man is the animal that laughs.
And occasionally whores for Karma.