In order to know how best to orient your data, it's important to know what the hardware will do with it. Hazards can cause incorrect computation, and to get around that potential thread, in-order CPUs manifest workarounds that produce pipeline bubbles and stalls.

We don't normally have to worry to much about read after write data hazards as most compilers will do their best to organise code so that the latency between the operations is filled with other work, but sometimes you need to think about what you're doing otherwise you can end up making it impossible for the compiler to overlay these otherwise uncoupled threads of execution.

The most obvious hazard is the control hazard, where the branch operation requires information and won't be able to prefetch data as it doesn't know which instructions are going to be executed. Branch prediction will start processing one branch, but as soon as the result comes in, if it doesn't match the currently processing branch, it will flush the pipeline, causing in effect a massive bubble of wasted pipeline slots. So, if you can, try to use use branches a long time after you calculate the predicate, such as in shader model branching where both branches of processing are run, and which branch, including which result, is only decided later. See single assignment form for more information on how this is achieved.

read more here:
http://en.wikipedia.org/wiki/Hazard_(computer_architecture)

and static single assignment form:
http://en.wikipedia.org/wiki/Static_single_assignment_form

DATA-ORIENTED DESIGN The hardware will thank you.

Chinese translation provided by KouZhe / Martin Cole

Hazards 16/11/2011:13:58:00