Migration Comparison Part 1

The simplest traditional technique to break the limits of sequential computing is traditional symmetric multiprocessing: multiple high-end processors as a pool in a same (very expensive) computer are dispatched coarse-grained process to execute, the computing model for each process being the traditional sequential model. Actually, this expensive and technologically limited hardware technique is just an expedient hack to long the life of the traditional centralized "client/server" model that allows the server to manage more requests at once. But it doesn't allow to take advantage of the growing multi-computer networks it relies upon. It can be considered as the stubborn brute-force approach to the problem of parallel computing.

Then comes traditional distributed computing, which is a software implementation of the previous approach, where coarse-grained processes are dispatched over a pool of logically equivalent processors in a computer network. Much better than the above method (that it encompasses, but for the ease of dynamical load-balancing), traditional distributed computing does allow to take advantage of existing and growing computer networks. With some refinement, and the choice of a compromise emulated virtual processor, it can even run on a heterogeneous network of computers.

Traditional parallel computing rather relies on hardware clusters of similar processors to run a same program; thus, contrarily to traditional symmetric multiprocessing or distributed computing, the parallelism is now fine-grained. The problem with it is the high cost of parallel hardware, and its complete lack of adaptativity, as different problems each formalize into different network geometry, that a same parallel hardware cannot all provide at reasonable cost. Thus, unless a particular class of similar problems is in mind, specialized parallel hardware costs too much to be worth it, notwithstanding the evolution of computer hardware that will make such an expensive machine quickly obsolete.

Of course, this traditional parallel computing can in turn be software emulated, as above, from a homogeneous or heterogeneous network of computers, but then, dispatching techniques that were successfully used for coarse-grained computing prove to have too large an overhead for fine-grained computing, all the more when the computer network is heterogeneous as of computer architecture, speed, transmission latency, reliability, security.

If we restate this last problem as that of fine-grained distributed computing in a dynamically evolving network, we obtain migration as a possible solution. If we insist just a bit on the (not yet traditional) aspects of persistence and dynamism in such distributed computing, migration becomes a natural solution: computer objects are migrated in the network, so as to find a place where resources are enough, while respecting constraints of availability to the I/O nodes that request the object and unavailability to unsecure I/O nodes.


This page is linked from: Migration Comparison   Migration Comparison Intro