Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 -- Ignore unavailable to you. Want to Upgrade?

To: NightOwl who wrote (73293)	5/20/2001 8:42:47 AM
From: SBHX	Read Replies (1) \| Respond to of 93625

NightOwl, The soa thing and a few more like it was a purely engineering solution to a problem that was always there and made worse by this granularity loss problem. In a sense the prefetch instruction(s) of SSE is another way to solve it. If the actual memory traffic to do the same task is doubled moving across memory types, being able to schedule it ahead of time is probably a great way to deal with the extra latency, yet taking advantage of the higher throughput -- but it also means that your memory throughput has to be MUCH higher to make up for the loss of efficiency or else the calculations in between memory fetches have to involve enough time for the data to all arrive. Actually, there isn't a great variety of these SOAs being coded, I think there was suggestion for only two or three variants eventually : 1. (X1, X2, X3,..., XN);(Y1,...,YN);(Z1,...ZN);{The rest1-N} 2. (X1,Y1,Z1,FILLER);(X2,Y2,Z2,FILLER);...(XN,YN,ZN,FILLER);{The rest1-N} 3. A hybrid between SOA and AOS where there are long bursts of needed data, followed by other unneeded data, then long bursts again. What is interesting about this is that it forces the game developer to either create geometry content in a non intuitive format, or generate them from their own objects in a different way. It certainly put a stop into another popular early idea that was supposed to take hold --- the idea that these geometry data (vertices and indexes) can be stored as pregenerated objects on the CDrom to be passed directly to the 3D accelerator, hence minimizing the need for cpu processing, and data movement or pack-unpack-mangling. (Yeah right, I can just see intc and amd falling over themselves to push a way to use slower cpus and halve memory bandwidth requirement<g>). As a further dramatic culmination of this drama, when the mpeg encoding people finally got hold of the super-secret sum-of-abs-delta instruction in SSE, they told intc that that wasn't the real bottleneck --- computationally it might have been, but you actually gain significantly more from the prefetch (if it worked properly). <g> This is not necessarily bad, just different, but I can see that this is not helping the academic encouraged vision of progression in computing that allows all that data abstraction and object oriented stuff that was supposed to hide this.