Guest Blog

My Conclusions on Parallel Computing

We have been dealing with parallel computing for some while now. Some of the ideas we had at the start proved to be wrong while others are only becoming relevant in the near future. No doubt about it, parallel computing was pushed and forced into the mainstream of computing just as Object Oriented was in the previous millennia.

Some History: Hardware

State-Phase Programming

It has been relatively easy for us to follow the path of a serial application. The flow of the application is managed by the Stack. This makes the execution flow of a single process to be managed by CPU hardware. Today we face the need to execute several processes in parallel and thus have several execution paths at the same time. This is harder for us to manage and keeping track of this flow is complex. The hardware accelerated Stack is no longer sufficient for us and the Stack-Trace is no longer the state of the application.

Stateful Programming - A Case Study

One of the basic tools that a programmer has in multi-core programming and parallel computing is the state maintainability. A serial application has only one flow and therefore the Call-Stack (list of nested function calls) is in a way the application's state. In a parallel environment this is clearly not the case because there are many threads with many Call-Stacks at the same time. For example taking a snap shot of a parallel system in order to reproduce a bug requires the states of all running threads, sometimes processes, and sometimes even the operating system.

Stateful Programming - a key element

A key feature of Object Oriented Programming is code manageability and reusability, key feature of Procedural Programming is flow manageability. A key element in flow manageability is Stateful Programming. This methodology is very common with Procedural programmers and is very uncommon with Object Oriented programmers, but it is easily applicable.

The Value of Infrastructure



Much have been said about parallel computing and parallel programming. There are many methods to approach this area, such as using low level API, many types of libraries, language extensions, and so on. The best approach is the one that out-lived time and stayed with us through the different generation of computer technologies. These are the Infrastructures. Not just any infrastructure but some specific types.

Locks Are Bad!!!

Students are tought to use Locks such as MUTEXs and Critical Sections. We are also told that a MUTEX is a type of Semaphore. This is all very bad!

When we lock we practically try to make sure that the resource is locked to a single core. - We have a multicore CPU but we try to make sure that all work with a resource is done using only one core. Why?

CPU Auxiliary Cores

If you had ever attended my lectures then you already know that parallel computing is not an add-on or a library that we use. It goes much deeper into the system design and architecture. Many times when we go for lunch after a session about multicore programming people identify parallel methodologies in the every-day environment. When you do this you know that you are starting to really understand parallel computing. A simple example is lunch itself: Someone is taking your order and before or after the orders of other people at your table. The order includes the main course and the salad.

Is DOS the ideal parallel environment - Part IV

This is the fourth and last part of this article. Previous parts surveyed Windows User Mode and UNIX. Part 3 of this article covered Windows Kernel.
The discussion is how parallel are these operating systems and we save the best for last: This last part of the article raises a surprising question 'Is DOS the ideal parallel system?'... or is this question really that surprising?

DOS

Páginas

Suscribirse a Guest Blog