~2012

Thoughts about parallel computing

De future will be all about parallel computing and asynchronous design patterns. So how are we preparing for this? I'm doing some research into this and gathering thoughts and information in here about this subject.

First of all, our focus for languages is C/C++, Python, Javascript. In the future we might add OpenCL to this. So I'm leaving out odd languages likes Erlang which are specifically build around these issues.

ZeroMQ

The first happy thing I stumbled upon is that the ZeroMQ framework is used a lot in parallel computing and specifically is used for lock free multi threading! So this is another one-up for ZeroMQ!

Already investigating how to do multithreading for the MapperTools app we don't want to copy data if do not need to. This is easily done by passing a pointer or reference. However this limits the message to a single process (a single process can still be multithreaded!) This is important to remember. There is no way to access the pointer outside the app since the operating system won't let you!

In fact ZeroMQ is great again. Since we are aiming for using every device we can, we will never be able to pass pointers to other processes of devices. So this is always done by value. Using zeroMQ as much as we can simpllfies this bigtime since there is no difference between inter-thread, inter-process or inter-device communication. Aint that fun! :)

QT Threading

QT has threading built-in. So you can use that either by sub-classing QThread or by passing your QObject to the thread (moveToThread). Actually this is a general approach used by most, if not all, threading implementations.

Remember this:

"Developers need to be very careful with threads. It is easy to start other threads, but very hard to ensure that all shared data remains consistent. Problems are often hard to find because they may only show up once in a while or only on specific hardware configurations. Before creating threads to solve certain problems, possible alternatives should be considered."

I still have a hard time figuring out the best approach to issuing threads. Running a thread isn't hard but communicating with threads is. Using slots and signals are the best approach in QT but I have a hard time working with parameters. Up until now I have figured best approach for parralel computing is to seperate the preparation of the work and the start of the work. To explain. Most threaded system have a run() function. This run() function is executed by start() automatically. As you can see it doens't accept parameters. So to get your work done in another thread you need to get the data in before run() is executed. This is an approach we could use as a standard. I'd like to call it "parameterless execution".

worker::run() {
   printf(this->printString);
}
worker.setPrintString("blabla")
worker.run()

I think this will be wise in order to get this into a GUI for visualising the programming. Using this approach as a standard pattern will make it easier to move certain parts of execution into a seperate threads.

OpenCL

OpenCL is a C-like programming language specifically to do parralel computation on devices like GPU's and CPU's. For now I think this is too hardcore. Note that openCV also has a openCL implementation!

Python

Python will never do multi-core multi-threading because of the "Global interpreter lock":. There are some ways around this but it usually involves spawning multiple processes. Once we'll get there we probably move to C/C++ anyways. So no trouble here. *http://taotetek.wordpress.com/2011/02/02/python-multiprocessing-with-zeromq/

OpenGL

OpenGL is NOT thread safe. So everything you do in OpenGL you do in the same thread. Don't even try to move it to a different thread. Remember openGL only does the drawing and not the processing! You capture your video in a seperate thread and move a pointer of the pixelbuffer to opengl. OPenGL draws it on screen.