Rambus (RMBS)

[cordob]

Something about Cell processors outside graphics.

This may interest some here. I ran into the following text in:
http://www.research.ibm.com/cell/

Single precision floating point computation is geared for throughput of media and 3D graphics objects. In this vein, the decision to support only a subset of IEEE floating point arithmetic and sacrifice full IEEE compliance was driven by the target applications. Thus, multiple rounding modes and IEEE-compliant exceptions are typically unimportant for these workloads, and are not supported. This design decision is based the real time nature of game workloads and other media applications: most often, saturation is mathematically the right solution. Also, occasional small display glitches caused by saturation in a display frame is tolerable. On the other hand, incomplete rendering of a display frame, missing objects or tearing video due to long exception handling is objectionable.

and asked at TMF at:
http://boards.fool.com/Message.asp?mid=22502649

Can somebody here place this in context? What does this mean? Does it mean the SPEs are useless for workstation use, because of limitations which do not matter in gaming?

A reply from RMHJ (a programmer with much processor knowledge) was:(in part)

Pretty much.

Implementing the full IEEE FP standard is pretty onerous, and really isn't ideal for real-time graphics. The standard includes multiple formats (single and double precisions, and optional "extended" precisions), a variety of "special quantities", including NaNs (Not-a-Numbers), things like plus and minus infinities, "signaling" and quiet NaNs, denormalized numbers, a variety of rounding modes (towards +- infinity, towards 0, ...). Even on servers/workstations intended for serious FP work, many of these are emulated (e.g., denorms on Alpha).

Most of these are geared towards getting useful and/or maximally accurate answers in the face of accumulating error, and estimating/limiting those errors. ("Using floating point numbers is a lot like moving piles of sand. Every time you do something, you pick up a little dirt and lose a little sand.")

The considerations for video are fairly different. Double precision (with 52-bit mantissas) are significant overkill for display, and require very large summing trees for fast performance. IEEE single-precision has only a 24-bit mantissa, and is rarely adequate for workstation apps, but is generally adequate for video.

Video usually requires "saturating" arithmetic, i.e., if you add or multiply two things and the result overflows (underflows), the result returned is the largest (smallest) reprentatable value. In IEEE you would get a NaN (or possibly a denorm), and possibly an exception. If you look at the SSE/SSE2/SSE3 instructions for x86, many of these instructions perform saturating arithmetic on 8/16/32 bit quantities. E.g., once you've gone to full-white or full black on the screen, any brighter or any darker are useless.

Maybe for those who have access better to read the whole thread. The conclusion in a later post from RMHJ was:

I don't know that the SPE's don't support double-precision arithmetic, but from the excerpt clipped, that would be the way to bet.

IMO, there's little/no chance for Cell to displace the x86 architecture. (And this has been my opinion for some time.)

=============================================================

I think my initial shock reaction on reading the IBM piece may have been correct in showing that this processor architecture is not very suitable for scientific calculations, i.e. workstations.

Same would then hold for supercomputers.

Of course, as one remarked on that thread, it would be possible to create different Cell processors with different instrcution sets for different purposes.

Cheers
Cor