3 ms·

But even in dataflow architectures (for example, the float4+float4 example) there are places where you want the different paths to meet. That's where synchroniz

But even in dataflow architectures (for example, the float4+float4 example) there are places where you want the different paths to meet. That's where synchronization (a barrier) is needed, as both results need to be available before the operation can be stared. Of course in the case of SIMD this nicely happens internally in the hardware so nothing can go wrong, but in more complicated cases, for example if you're programming CUDA you need to care about it sometimes. I agree that an alternative hardware architecture could probably solve this, but that is taking it a bit far and doesn't help solving any immediate problems.

scott_s 15y ago
Even if you have merged paths in dataflow and you don't need a barrier, it can be difficult to reason about. Specifically, it's difficult to figure out what a legal result even is.
kd0amg 15y ago
But even in dataflow architectures (for example, the float4+float4 example) there are places where you want the different paths to meet. That's where synchronization (a barrier) is needed, as both results need to be available before the operation can be stared. A dataflow architecture should be doing this in hardware -- don't issue an instruction for execution until all of its operands have been reported. The point is that it's not something the programmer needs to be explicitly concerned about.
- Daniel_Newby 15y ago
  A dataflow architecture should be doing this in hardware -- don't issue an instruction for execution until all of its operands have been reported. There is still a need for application-level synchronization. For example, to keep the same money from being withdrawn from a bank account twice.
- wladimir 15y ago
  "should be", yes, let's move our problems to the hardware guys. I'm all for it. But hardware takes long to develop (if practical at all; a hw implementation might become to slow and expensive), and even longer to be mainstream, so I don't really see changing the hardware as a solution.

scott_s 15y ago

Even if you have merged paths in dataflow and you don't need a barrier, it can be difficult to reason about. Specifically, it's difficult to figure out what a legal result even is.

kd0amg 15y ago

But even in dataflow architectures (for example, the float4+float4 example) there are places where you want the different paths to meet. That's where synchronization (a barrier) is needed, as both results need to be available before the operation can be stared. A dataflow architecture should be doing this in hardware -- don't issue an instruction for execution until all of its operands have been reported. The point is that it's not something the programmer needs to be explicitly concerned about.

Daniel_Newby 15y ago
A dataflow architecture should be doing this in hardware -- don't issue an instruction for execution until all of its operands have been reported. There is still a need for application-level synchronization. For example, to keep the same money from being withdrawn from a bank account twice.
wladimir 15y ago
"should be", yes, let's move our problems to the hardware guys. I'm all for it. But hardware takes long to develop (if practical at all; a hw implementation might become to slow and expensive), and even longer to be mainstream, so I don't really see changing the hardware as a solution.