SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Rambus (RMBS) - Eagle or Penguin
RMBS 106.18-4.0%10:01 AM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Scumbria who wrote (22628)6/16/1999 1:56:00 PM
From: Tom Warren   of 93625
 
Does Intel really need Rambus bandwidth?

All of the discussions I have seen tie the answer to this question to processor speed. At some speed the processors demands dictate higher bandwidth and lower latency from the memory subsystem. While this is true, I feel it ignores a couple of very important developments / trends.

First is what I'll call parallelism, the design of CPUs to perform multiple operations per clock. Regardless whether this is implemented as SIMD in SSE for Pentium III, or as 3 floating point units in the K7 this parallelism would seem to demand data at a multiple of any given clock speed. If the processor is going to attempt more than one mathematical operation at a time, the data must come from somewhere. An increase in parallelism implies that bandwidth demand will grow faster than clock speed growth. Every indication is that future processors, such as Wilamette will stretch parallelism even further.

Second I'll call cacheability, how effectively can the data being processed be cached. This can range from data fits entirely in cache to every request is a miss. I believe the desktop PC will see an increasing amount of data that is poorly cacheable. Digitized audio or video data are examples. The data sets are too large to hold entirely in cache and are typically handled once or a small number of times then discarded. It is interesting to note that this type of data is not accessed randomly. In the simplest example it is accessed sequentially. This is important because, at least in theory, one can eliminate latency as a problem. If you know what the next piece of data is that you need, pre-read it. Here again the implication is that bandwidth demand will grow faster than clock speed growth.

If you buy the premise of the above arguments, you may still question how many actual applications fall into this category. Not coincidentally the examples are loosely Digital Signal Processing examples. Few would argue that the DSP area wouldn't grow faster than market. Intel fought off RISC processors in my opinion by incorporating the architectural concepts that it needed to compete. It is now in the process of incorporating those DSP concepts it needs to compete with DSP's as the platform for a variety of multimedia and communication applications.

Most people evaluate cars using peak performance measures; panic stop distance, passing acceleration. These have little to do with the average demands on the car. I don't get on a freeway very often but my expectations of performance at that one instant set the benchmark for acceptable performance when I'm car shopping. I believe that people will also buy computer power based on peak demands, even if they exercise the full power of their computer infrequently.

I expect upcoming benchmarks on camino / rambus and the marketing strategy that goes with it will heavily emphasize applications like speech recognition.

There were postings on Intel and AMD threads regarding memory bottlenecks and speech recognition that I thought were incomplete. The broader implications of the ideas presented have been puzzling me now for several weeks. You may want to check out the following posts/threads. I'm quite interested in any comments you or others may make regarding this reasoning.

Speech recognition joint venture
Message 10015640

Bandwidth requirements / benchmark results
Message 9944519

Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext