Well, I guess those parts are just too absurdly long for anyone to want to comment... :) I would definitely be interested in whether people agree with my views for competitive dynamics/financial prospects on Page 6: http://www.beyond3d.com/content/articles/107/6 - That part is inherently subjective and obviously it's all very debatable, but I still thought it was worth publishing given the article's focus. So, I wonder how many of you think I'm right there or completely off-track etc.?

I think nV is a bit too optimistic here.

Sure, there are new markets for GPGPU but honestly, it's unrealistic to propose those cusomters to use new hardware. From what i've seen in the financial sector a mere 9600GT is sufficient to do the calculations required for stock/option/trade analysis..

that's realistically what any end user wants. a specific API running on a legacy system.

Can you clarify what numbers are being used to determine the value of the CPU business, such as what segments and devices fall under that umbrella?

GPUs wouldn't apply to certain segments, and there are possible sources of price compression that will cut the amount of revenue that is transferable from CPUs to GPUs.
So far, it's been the case that there's at least a 1:4 CPU:GPU ratio or lower, so any forays into GPGPU clustering will bring along a number of CPUs, which will eat into the costs customers will be paying to the GPU portion.
The other issue is the compression of systems.
A GPU system can reach similar performance levels on certain tasks that a much more expensive and larger CPU cluster could hit.
Whatever price differential between a GPU cluster and CPU one is money that has simply evaporated.

I'm still not clear on whether Nvidia's efforts at making GPGPUs robust enough for all kinds of work are complete.
Their idea of validating with conservative memory clocks and burn-in is not what some higher-end segments and large clusters will find sufficient, since it only addresses screening of some device failures and does nothing to handle reliability, fault reporting, or transient errors.

Also, do you have more feelers in the trial markets for these first implementors--the coders and testers who are not being touted by Nvidia?
Issues with getting GPU code that just works, the relative strength (or weakness) of debugging capabilities, the relative dearth of hardware instrumentation and exception handling, and so on have little effect on peak performance but a large influence on whether an architecture will be deemed stable, trustworthy, and worth the trouble.

Intel should start letting more news on Larrabee trickle out in the next few quarters, which I'd expect to have a significant chilling effect on Nvidia and AMD's GPGPU efforts.
Some may simply wait until they can get their hands on a product that can in a pinch be treated like a CPU and could even go without one, if some slides are to be believed.
While there is no guarantee, I'd suspect that Larrabee's CPU heritage will mean it will be capable of exception handling and the chip will be well-instrumented.

Larrabee may not lead in performance, but it may turn out to be a more effective architecture if it can leverage the benefits of the extant CPU platforms.

Yep. :grin:

I've bookmarked the articles, but haven't gotten a chance to read them yet.

Cell processor aiding in search for oil.

http://arstechnica.com/journals/thumbs.ars/2008/07/02/cell-processor-aiding-in-search-for-oil

Thought this was relevant considering all the time spent talking about oil exploration in the article.

Brook+ I have no trouble accepting, but Ct? Jawed

While Ct is promising we only got whitepapers about it, AFAIK Intel has not released it to the public.

One point of view I've seen is that Ct is a kind of functional programming peg mashed into a procedural hole, and that Intel should have just stuck with NESL. I'm really not a languages guy though. I can sympathise with the view that C++ is a mess of objects mashed into procedural too, but I don't feel it in my bones. Sadly, in a way, all three of these approaches appear to be API kludges for C. CUDA's "benefit" appears to be that it is the least distant from C and is really just allowing Cg and C to co-exist without all that nasty 3D pipeline state nonsense getting in the way. At the cost of the shenanigans of manipulating data structures for SIMD width, register file width and memory-coalesce width, not to mention the memory hierarchy dance. Clearly a bit of marketing, there's this paper on financial modelling with Ct: http://techresearch.intel.com/userfiles/en-us/File/terascale/Ct-appnote-option-pricing.pdf Irrespective of arguments over the qualities of the language as a language, it's interesting that in a straight race with a compiler (Visual C++ 2005) there's some formidable speed-ups to be had. Jawed

The SDK for Larrabee is "Native SDK", not Ct, Ct is just a research project .

I heard that, though I wouldn't be suprised if a Larrabee's Ct backend is being developed right now.