Wouldn't a successor have to begin development long before the precursor was released, and would they have been able to identify weaknesses in time to be fixed?

(Bold mine)
Now the question is.. what are they comparing Larrabee to? G80? G92? future theorical performance extrapolated from current one, taking in account the ETA for Larrabee?

Larrabee has a few things going for it that I feel should be sufficient to carry it through a revision or two.

CPU designers admit that the utility of symmetric multicore drops to near zero after 4 standard cores, outside of certain lucrative but still limited market segments.

Intel admits there is a need for different methods to further the usability of massively multicore architectures.
In that respect, the work put into Larrabee is work Intel needs to do anyway.

Larrabee's core design may also share the same design philosophy as Intel's Silverthorne core, and in-order 2-wide x86 (besides the vector unit). The core itself is simple enough that design costs are small, with the big difference being in the cache and uncore: areas Intel needs to improve anyway.

I think that means that a fair amount of Larrabee's expense is incremental to things Intel is doing anyway. Better, it's an attempt to get revenue on work that would otherwise not bear fruit for many more years.


The possible upside?
Larrabee's very likely to be a very strong competitor for GPGPU. In addition, it will compete in HPC in a number of areas that AMD's Bulldozer should have gone in (according to early slides showing it's prowess in HPC).

With one design effort, Intel furthers massive multicore design, hurts the revenues of GPGPU, makes some money in HPC and possibly graphics, and sucker-punches AMD's next-gen design effort on two fronts (Three, if we discover Silverthorne is distantly related to it and hurts Bobcat. Via gets nailed too).

Even if Larrabee fails in consumer graphics, it should be of interest to HPC. Even if it fails there, the other benefits would be enough that Intel could swallow a few weak iterations and still do well as a whole.

This might be an Itanium-type situation. As poorly as it did early on, the product is now profitable on an operations basis and it helped kill off several wobbly RISC lines in the high-end. POWER and SPARC are primarily the remaining RISCs that still exist in non-embedded or telecom. SPARC isn't growing and its new products are in a niche (one that Larrabee could also target...).
IBM is working seriously hard to maintain a leap-frog relationship with a design that is far more intensive on all levels of the system than Intel's.

The product should be taped out long before the successor's design is frozen.
They'll have some good ideas from running engineering silicon where some improvements could be made.
Larrabee II should also benefit from the software and driver snafus that might pop up for the design that first wades into the real world.

IMHO it wouldn't be such a good idea, rasterization per se doesn't map well to CPUs.Though I wouldn't be surprised if Larrabee has a hw rasterizer but not a dedicated setup unit, as it can be implemented in software (does Larrabee support double precision math? ...)

Larrabee should support x86, and some slides show it as a system processor, which hints at full support.

Slides on Larrabee indicate it should be capable of 8-16 DP operations per clock using SSE. I'm not sure why there's a range, perhaps it hadn't been decided when the slides were created or there's a different throughput depending on whether the code uses standard SSE or the expanded vector set.
Aside from that, it was stated to support 2 DP non SSE ops.

This extra support does point to the greatest internal threat to Larrabee: the everything and the kitchen sink syndrome that hit the IA64 Merced.

If McKinley is an indicator however, Larrabee II should come about after the "we can do anything" phase ends and designers can focus on what it can do well. This is where things go from pie-in-the-sky to interesting.

I'd strongly disagree with this point of view. Perhaps some (maybe even many) do, but there are some who do not. In general, I think the most aggressive architects have not given up on higher performance. Actually, the most aggressive architects have not given up on higher single threaded performance.

Yes Intel needs to figure out how to get 16 cores to work on a die from a SW perspective. However, that doesn't require a product.

There is a huge difference in cost between an internal research project and a product that you sell to end-users.

Additionally, doing something too early can be very costly if the ROI isn't high enough.

Right now AMD's primary concern should be Nehalem and Sandy Bridge, not Larrabee.

That would be a disaster, the good news is that Intel can survive disasters.

I certainly hope that Larrabee turns out better than Itanium. The last time Intel took their eyes off the ball, they ended up letting x86-64 slip through the door.

DK

Just going by various admittedly dated presentations a while back where both AMD and Intel drew the line for homogenous multicore of big OoO cores at 4-8 for the desktop, with the provision that server and other segments could do with more.

But it does mean Larrabee's design cost is incremental with research that would be ongoing anyway.
Intel has to put the pedal to the metal sometime.
Itanium already showed what can happen if you only rely on internally formulated means of evaluation for a design.

There's a decent chance that it will gain a foothold in a few areas, and it can serve as a bulwark against competitors that are rapidly running out of choices when it comes to competing.
AMD and Nvidia have a high flops part that can establish a niche if not contested, and ceding a potentially lucrative market is handing them free money.

There's more gradation on the scale from internal project to a massive cross-market product ramp.
The plans are tentative enough and far enough ahead that Intel can scale back production and expectations as needed (unless its ray-tracing uber alles marketers go unchecked for the next year or so, that is).

I suspect this is the likely outcome, but if that's the case they may only be off by a year or so.

Sure, but it's not in Intel's best interest to refrain from adding more worries.
It's not Intel's fault that Bulldozer's been delayed into that timeframe.

For AMD's GPGPU line, Nehalem and Sandy Bridge are obstacles, but they are not directly targeted at similar workloads. The order of magnitude performance gap for customers that have tasks amenable to GPU boards won't be removed by the next CPU generation or two.

Larrabee, if targeted correctly, can undercut both Firestream and AMD's attempt to appeal to HPC with SSE5 and its new instructions. This of course assumes that AMD's delay of Bulldozer isn't because AMD chickened out and is yanking its second set of FP extensions Intel refused to recognize.

It would be a disaster if all of that fails, but it's more of a form of graceful degradation from "not so good" to "pretty bad" to "utter disaster".
The failure would be mitigated in part by the fact that a fraction of its expense is overlayed with otherwise unavoidable expenditures.

Intel has to fail to gain a foothold in multiple market segments for Larrabee to fail.
For a complete disaster, it has to fail to garner any devrel or mindshare among developers that serves as groundwork for future software that will most likely tread the same path again.

Depending on the competitive environment, it may only need to keep its eye on the ball part of the time.

I don't seen any yawning gaps Larrabee creates in Intel's product lines, and it goes along way in plugging up a few avenues of attack.

The available evidence suggests to me that Larrabee was aimed more at Nvidia and ATI than AMD, and that the AMD acquistion of ATI and launching of the Fusion project was, in part, AMD's reaction to figuring out where Intel was going.

We just knew more, sooner, about AMD's efforts because it involved a multi-billion dollar acquisition that forced them to talk about them at length in public much sooner, almost certainly, than they'd have done so if that factor wasn't involved.

I heard from a reliable source that Abrash is working on Larrabee as well.

Well, we have one "proven" design (Cell) and one that goes the same direction, but foregoes the things that make Cell work: large local stores instead of a unified (cached) memory structure, and a new ISA.Without a close look at a first sample in action, there isn't much we can say about the validity of having all those cores crunch away in a meaningful manner.