Sunday, April 4, 2010

COSA Vs. LabView


People write to me regularly to tell me that COSA is nothing new and that it's already implemented in a graphical dataflow language called LabView. I beg to differ. What follows was posted earlier on the Rebel Science Discussion Forum. It is my reply to a poster named hcsik who insists that LabView is COSA. I felt it was important enough to repost it here on the Rebel Science News blog.

hcsik wrote:
Nice concepts.
Alas, not as new as one would have liked to believe.

Every proposed COSA feature you find realized in LabView:
"Change-Driven", "causality", and "temporal consistency" (a.k.a dataflow semantics),
"passive and active objects", "cells and components" (called "virtual instruments" with input and output connectors),
"visual software construction", "total overview", and "programming by design" (draw connection diagrams to code).
They seem to offer free time-limited evaluation copies for download; you should really try it out; I guess you'll love it.

LabView saw its first release in 1986.
Nowadays you can purchase specialised hardware with CPU boards dedicated to the parallel code, which don't run a standard OS, but a realtime kernel optimised for the purpose (this should count as a realisation of the proposed "CODA OS").
Nowadays they even offer an FPGA development board to optimally exploit the parallelism of the components you design.
Believe me, I have heard this many times before. You are mistaken. Here are some fundamental differences between COSA and LabView:

Not Dataflow

COSA is not a dataflow language. The idea of data flowing like a stream from one component to another is not a fundamental aspect of COSA. COSA does have reactive data connectors but they are not used for dataflow in the LabView sense. A COSA program consists of actors (sensors and effectors) and the environment (data). That's pretty much it.

Fine-Grained Parallelism

My understanding is that LabView is a high-level coarse-grained dataflow language that propagates variables or data structures from one so-called 'virtual instrument' (a code subroutine or algorithm) to another. COSA, by contrast, is a fully reactive, non-algorithmic, execution and programming environment for fine-grained parallelism. COSA is a software model that redefines the way we build and program our computers. The fine-grained, instruction-level parallelism of COSA is the reason that a COSA program will run slow on existing processors. COSA will require special processors specifically designed and optimized for this sort of processing. LabView seems to run fine on current machines because it is not a new software model. A COSA processor is a pure vector processor and will have no trouble handling any kind of high throughput parallel processing, including the kind of graphic processing now being done with GPUs.

Control Hierarchy and Complementarity

COSA has control concepts like sensor/effector associations, self-activated effectors, sensor and motor coordination principles and hierarchical composition; none of which exists in LabView. A component in COSA is either a supervisor or a slave, a concept that is analogous, at the lowest level, to sensors and effectors. Complementarity is a fundamental aspect of COSA.

Timing and Temporal Determinism

Timing is also a fundamental aspect of COSA, so much so that there are no logic gates in the traditional Boolean sense. The logic detectors in COSA are strictly timed, meaning that they are signal-based as opposed to being state-based. In COSA, temporal determinism is an absolute must. This is the reason that COSA programs, unlike Labview programs, cannot use multithreading since multithreading is non-deterministic by definition. Same goes for existing multicore processors.

As Few Icons as Possible

One of the things that I don't like about LabView is the proliferation of icons. COSA uses as few icons as possible: the connection line, the sensor, the effector, the synapse, the data icon, the component and the component connector. That's it.

Hierarchical Composition
Sadly, however, LabView didn't apparently succeed in solving all the software reliability problems.
Even though the diagrams look nice and simple (when you start...), and it's easy to design simple applications, in the end it turns out that the concepts of LabView (and consequently COSA) tend to lead to even more complex software solutions then the equivalent typical text-based computer languages (which you would call "algorithmic").

Besides, the graphical representation tends to really get in your way with everyday practical software engineering necessities like version control, merging, or simply navigating through a huge code base (you can't easily "grep" for graphical symbols). The development model doesn't scale to large teams, the typical LabView app is a one-man show.
LabView is quite successful in its commercial niche of measurement, production, and test automation, but it's a niche nevertheless.
It is because LabView is doing it wrong. They use the wrong compositional approach and too many icons. The COSA compositional tree will solve all the problems that plague LabView. Top to bottom complementarity (master/slave) is the key to effective software composition and large-scale component reuse.
Ironically, I've personally experienced that the developers which most fervently detest LabView and schematic entry tools are exactly the FPGA guys who would know best how to do parallelism. They swear by their purely textual VHDL development environments.
Again, it is because LabView is doing it wrong. But then again, so is FPGA. All that stuff will eventually be supplanted, in my opinion.

No comments: