13:12
When watching Morten's webinar about cloud computing/distribution, some analogy to processing a numerical task on the GPU comes to mind.
- The units (cloud CPU's or GPU "subprocessors") are completely unaware of each others' timing and individual results
- Both are inherently parallel
- They output the result to a common place (screen or the APL that distributed the task)
- In both cases, the transportation of data is very expensive
(In the GPU case, the trasportation from/to the CPU is expensive)
But there are significant differences:
- The GPU outputs it's result to a memory that is nearby (video memory) but yet common, where it sits until asked for by the CPU. In the APL cloud case, there is no such memory, the common memory is at the very start end.
- The GPU has a two-stage calculation (first the vertex shader, then the pixel shader). Both are parallel, but the vertex shader may or may not re-shape the whole thing.
Leading me to think that in order to make the cloud computing really efficient, there should be
- knowledge of the transmission speed between the individual cloud CPU's
- an intermediate (common or partially common) memory bank where the CPU's could output their results, in order to:
- have it handy there for further calculations
The final result should be grabbed back only when the entire calculation is fully completed. As long as it isn't, it should (by som weird autoomation) be able to reside in the cloud.
*Adding to the very beginning:
- All cloud CPU's and all vertices/pixels execute an identical piece of code. All have the same data handy. In the GPU case, there is an external coordinate system that allows the pixel to perform a fn(where am i?). But the cloud CPU doesn't have that, though it may have for example a rolling serial number etc..
So to make cloud computing even more efficient, the environment should be able to denote which peers are nearby and efficient in "local" data transmission. Then an initial split of the data should be sent to that group, where it manages further distribution autonomously.
*peer are nearby each other
... which was the case in the Amazon park, most CPU's were probably on the same copper almost -> very efficient comm locally, but not as efficient if each CPU individually talked to the external "master APL".
