Monday, March 10, 2014

Lesson about delegation from OpenCL

Using OpenCL and the complexities / benefits that comes with it reminds me of an issue of trade-off in delegation. You can always do things the simple straightforward, serial way but there is a limit of how much and how fast it can finish the tasks. We can scale things better by utilizing more external agents and manage it. However using additional agents means delegating tasks to those agents and manage the overhead and unpredictability that comes with it. This is why the code to achieve the same thing using OpenCL can be quite complex since you need to manage the data and logic that comes to and from those computing units and get them to work together properly.

It's not just cost that is increased though, the risk is also higher. When you delegate, you add another factor with its own set of quirkiness to your system. Each agent you add, you add another risk of it fail in some way and effect the overall system. In OpenCL, certain GPU might not behave as it should, your calculation might fail in certain configuration. So, you will need to add more activities to manage the risk. How it can be anticipated, localized and how the system can cope gracefully when it happen.

So, since delegation is not free it is important that the scale of the problem would need to justify the use of delegation.  You can add more things, method, people to your system, but when it does not fit your scale, it will become a burden since your output, what you get, is lower than what you need to expense. In term of OpenCL, the low complexity or low number of calculation probably not worth the trouble. For example, even when you ding the formula is complex and can be paralellize but if your expected data to be processd is not much, it probably better to just code it the traditional way.

Delegation can be costly and risky, but if you need your solution to scale better, the return can be very much worth it.

No comments: