Memory access pattern: Difference between revisions

Revision as of 15:40, 13 June 2016

Revision as of 15:48, 13 June 2016

Line 31:

== Approaches ==

=== data oriented design ===

[[Data oriented design]] is an approach intended to maximise the locality of reference, by organising data according to how it is traversed in various stages of a program, contrasting with the more common [[object oriented]] approach.

==== random reads vs random writes ====

An task may have some inherent randomness, with alternative solutions for handling this either through reads or writes, with scatter or gather alternatives. These choices appear in GPGPU and graphics applications:-

==== sequential reads with scatter ====

An task may have some inherent randomness, with alternative solutions where this is handled by random reads + sequential writes [[gather (vector addressing)|gather]] , or sequential reads plus random writes [[scatter (vector addressing)|scatter]]. The scatter approach may bypass the need for caching since a [[processing element]] may dispatch writes in a 'fire and forget' manner, whilst prefetching it's source data. However, it may be harder to parallelise since there is no guarantee the writes do not interact. As such the gather approach is more common for [[gpgpu]] programming.

In the past, [[forward texture mapping]] attempted to handle the randomness with 'writes' (sequentially reading textures). The [[playstation 2]] console used conventional inverse texture mapping, but thehandled inverseany approachrandomness is'on-chip' nowusing EDRAM, whilst data from main memory was fed by DMA. (hence it's lack of support for indexed primitives, and need to explicitly upload a limited number of textures, managed up-front in the more[[display widespreadlist]]).

==== gather with sequential writes ====

An algorithm may be re-worked such that the reads are random [[gather (vector addressing)|gather]] , whilst the writes are sequential. The disadvantage is that caching (and bypassing latencies) is now essential for reads, however it is easier to parallelise since the writes are guaranteed to not overlap. As such the gather approach is more common for [[gpgpu]] programming, where the massive threading is used to hide latencies.