1100 MHz 'Athlon Killer' Due From Intel in December

jeffstar writes "According to this article at The Register, Intel has an 1100 MHz 'Athlon Killer' IA32 chip coming out. Yum, that's the kind of sauce I like." Sounds great. If it comes out - and performs - as promised.

Comments

Pundificaton

[Soong]

1. Megahertz is a dead end

Allready processors are too fast for the rest of the system. This has been alleviated for the last decade by an increasingly complicated system of caches and chipsets. At worst you'll go throgh 3 levels of processor cache, main memory, disk cache and finally disk, for a total of 6 levels of memory. This could go on indefinately but will have decreasing returns, unless the architecture of the computer can catch up to be generally faster. SGI/Cray has done this well.

2. Megahertz == Marketing

Ever since the P2, it's been terribly obvious that Intel just develops to satisfy what the majority clueless consumer wants- a higher megahertz number. The P2 made it blatant by being inferior to the older P's when run at equal megahertz. The only benefit was that it would run at higher megahertz.

Efficiency

No x86 has been really efficent- in many ways. More gates, more watts, more space, more heat. The unfortunate predominance of x86 is leading to space robots being designed with pentiums because Intel can push through to get the chips certified. When multiprocessing becomes a necessity as clock speeds dead end, who will be able to afford the power and large case for cooling that 8-64 P[3-5]'s will need? It's absurd.

Re:clock speed vs parallel design

[Salamander]

The basic formula for CPU performance, from Hennessy and Patterson, is:

• WPI * IPC * CPS

• WPI = Work Per Instruction

  IPC = Instructions Per Cycle

  CPS = Cycles Per Second

Classical CISC architectures tried to maximize WPI, and this limited the other two factors. RISC was mostly intended to maximize CPS, intentionally sacrificing WPI to do so. Pipelining, superscalarity, and branch prediction are all targeted toward increasing IPC in different ways. VLIW and EPIC improve either WPI or ICP depending on how you look at it.

All of these approaches to improving performance tend to have characteristic challenges associated with them. In the current case, you have to deal with the fact that massively superscalar architectures require an instruction stream that keeps all the functional units fed. That means that compilers have to try to resolve data dependencies and competition for functional units, either of which would cause a stall, and also deal with branches which cause bubbles in almost any architecture. It's a very tough problem, which is why chip designers turn to second-order tricks such as speculative/predicated execution and VLIW/EPIC.

Personally, I think that's all a trap because it causes chip complexity to skyrocket and undermines the very idea of RISC. If I were designing a chip, my goal would be to crank the frequency sky-high and make the compiler (or a translating front-end processor such as Transmeta is rumored to be working on) do most of the worrying about how instructions get scheduled. In particular, I'd go for:

• A moderate number of moderately pipelined functional units, with fully exposed pipelines including whatever delay slots are necessary.
• Instructions that specify the functional unit, without on-chip dependency checking and such. If the compiler screws up and issues an instruction before its operands are ready, tough for them.
• Very limited branch hinting. No branch prediction, no speculative execution.
• Lots of on-chip cache, because there's no way memory will keep up. If the tag-check logic can't be made fast enough, maybe an explicit stack or scratchpad on-chip.

Re:Very suspicious

[Anonymous Coward]

The Register article you link to is very significant, but perhaps not in the way you intended. On 15/04/99 the Register reported the following:

Intel is twisting the knife by showing OEMs performance predictions stretching out until late 2000 featuring a Willamette IA32 processor rated at 1100MHz competing with an AMD K7 at a paltry 666MHz.

No specific figures are quoted, but graphs pitting the rival chips against each other show the Willamette 1110MHz scoring around the 50 mark in Winstone98 against the K7 666MHz at 35. On SpecInt95, Willamette reaches 43 against the AMD part's 20.

The same graph shows a 666MHz Coppermine appearing in late 1999, a clear 12 months before AMD is expected to reach the magical figure.

And perhaps more worryingly for AMD, a Coppermine-based Celeron appears in early 2000 (probably at 500MHz and 100MHz FSB with Streaming SIMD) which is predicted to perform almost on a par with the K7 666 reckoned to be due 6-9 months later.

Rather than demonstrating inaccurate reporting by the Register, this report simply presents Intel's OWN predictions.

It appears from this that Intel was expecting AMD to be unable to supply 666 MHz Athlons until Q4/2000! As you can see, Intel's current production is right on target, but their predictions for AMD were way off!. AMD is over a YEAR ahead of *Intel's* schedule. There's no way for them to adjust for this misprediction quickly, so expect Intel to lose a *lot* of market share to AMD over the next year.

My how the tables have turned...

[Special J]

It wasn't even six months ago that people talked about AMD's "Pentium Killer". Now its the other way around. Changes fast doesn't it? Used to be everyone after Intel was trying to make the Pentium Killer. This is the first time I recall in x86 land that Intel is the one making the "Killer".

Perhaps this a true sign that AMD is a legitimate competitor to Intel; not just in the low-end but the high end too. If you didn't think that already.

What's the point...

[.pentai.]

Seriously curious...what would be the point of this for the majority of us? I'm running a single celeron 400 (soon to be dual) and it does everything I want, without problems. Kernel compilations are in the low single digits, I can play any games full speed, why does the average person here need something this fast? We don't, other than possibly being able to say "haw, my computer is faster than yours."

Just some thoughts...though I wouldn't complain getting one of these things for my birthday or anything :P

Price!

[freakho]

It won't be an "Athlon Killer" unless it is competatively priced. Assuming this report is reliable, Intel takes it from paper to silicon, and a lot of other stuff, it still won't appeal to te typical computer buyer (which ain't us anymore) unless there's not too huge a price gap. Which would mean Intel selling under cost yet again, and how long can they keep that up? Fiscally, a long time, admittedly, but I'm talking logically.

fh

Not to sound doubtful....

[mosch]

But I'm doubtful. Intel doesn't have a particularly stunning record with delivering chips early and I'd rather not buy one of their step 0 chips anyway.

Let's see, AMD gets market share and major recognition with a quality product, and now suddenly Intel is claiming that it can suddenly make much faster chips RSN. Whatever.

I'm personally sick of talks of vaporware. I love new technology and reading about the future, but I don't buy my computers based on speculation from unnamed sources regarding the possible date that a chip will get put to paper. It's utterly irrelevant.

Call me when it's in silicon.

Memory latency

[Hasdi Hashim]

1. The register is a rumour mill

2. At 0.18 micron this stuff needs a supa-dupa cooling system. Maybe with sharper fab, you can get this speed

3. Needs very large cache and very wide memory bus and heavy interleaving because the last time I checked the memory is still running at 100MHz max.

If I were you, i'll either get a dual celeron bundle at $799 or a 400 PPC750 with monitor also for $999.

Very suspicious

[hedgehog_uk]

According to the article, the Willamette is coming out 9 months early. So were Intel originally planning on sitting on this chip for 9 months, but forced to release early by the impending 1GHz Athlons due early next year? Is this chip going to be fully tested, or will it contain major problems like those found in the i820 chipset? Perhaps this is just vapourware, designed to put off people who were thinking of buying Athlon systems - this wouldn't be the first time that companies have done this.

I'm left wondering if this article is going to be any more accurate than one the Register ran earlier this year when they said that the 666MHz Coppermine would appear in late 1999, "clear 12 months before AMD is expected to reach the magical figure". Yeah, right.

HH

Adding more pipelines (width) has its own issues

[aheitner]

largely that it's very hard to parallelize code so that you can run it through separate execution units without stalling the processor. With the Pentium's two shallow integer execution units it was possible to hand-optimize your assembly to keep the two pipes filled. But breaking up code that is linear in design (i.e. most programs have a single "flow" and assume linearity of execution as their core model) into parallel chunks is a hard problem.

Continuing down the "more, simpler pipes" path is akin to explicitly parallel chips. It's a hot area of research, and there are some applications for which it might pay off (the ones where multiprocessor machines already pay off, perhaps: servers that are doing several unrelated things at once) but for doing just one thing and doing it fast, faster deeper is probably far easier a problem. Remember, Intel has had problems with the old P6 core (ppro/pII/pIII) because it's already very hard to write a compiler that doesn't stall it left and right.

With all that said, I don't see any mention in this article about the actual design of the new chip, except for some very vague (and likely wrong imho) stuff in the article about Wilamette that's referenced in this one.

Re:clock speed vs parallel design

[David Greene]

While marketing probably plays a (small) part, probably more importantly, the parallelism just isn't there. At least not to any degree that the hardware can see it.

Branch prediction is the major problem. Sure, predicting one branch may work 90% of the time, but when you start talking about wide machines, all of a sudden you're predicting 2, 3 or 4+ branches at once. Your prediction rate goes way down. Fast.

A student here did a study that showed >50% of the processor cycles were spent recovering from branches. And I don't think the study was on a particularly aggressive machine (though I can check that).

The encouraging this is, if we can get around branch problems (and that's a huge if), the parallelism is there. But not where the machine can see it. There was a study exploring the limits of ILP in Spec95 (yes, not realistic benchmarks, but it's what was available). If you assume perfect prediction (yes, completely unrealistic, but this was a limit study) and remove the stack pointer (which is often on the critical path of instruction dependencies), you can get parallelism in the hundreds (for integer programs) or thousands (for floating point stuff) of instructions.

But there's catch. If your instruction window is 10k instructions wide or less (a completely unrealistic size, by the way), the parallelism drops by an order of magnitude or more. The hardware doesn't have enough context to see it. But the compiler does. Think about forking threads on function calls when you can and you'll see where I'm going.

Some kind of model like Simultaneous MultiThreading may be needed in the future. Compaq is working hard on this for the Alpha.

What's important to remember is that we've received the biggest speed boosts from the process guys. Cranking the clock and packing in gates (i.e. cache) does much more than adding another pipeline. Remember Moore's Law.

--

Re:A reliable source told me:

[Anonymous Coward]

Hi, Mike Magee from The Register here (mike.magee@theregister.co.uk) When we use the phrase source, reliable or highly reliable it's because we need to protect the identity of people. How soon, for example, would someone be fired if we published their names and email addresses? We call this protecting our sources. Don't think we make this stuff up -- we don't... Plus, our view is that applying the "sacred principle" of journalism to the IT business is counterproductive. If we had to put every single one of our sources "on the record", they'd say -- err, I signed an NDA... Mike