Wednesday, May 28, 2008

The COSA Saga

Rockwell Aim 65

I had my initial idea for COSA back in 1980. I had just bought myself a 1 MHz Rockwell AIM 65 single board computer with 4k of RAM. At the time, I knew almost nothing about computers other than that they fascinated me to no end. On the same day my computer arrived, I dove into one of the assembly language programming books that came in the package. In the introductory chapter, the author (I can’t remember his name) covered the basics of how computers work and what a program consists of. He then explained that, unlike a biological brain, which has many slow processors (neurons) working in parallel, a computer has a single CPU that processes instructions one after the other. However, he continued, a CPU such as the 6502 is so fast that it can do the work of many slow parallel processors in a short interval.

Right away, even before I knew enough assembly language to write my first program, it was clear to me that computers were fundamentally flawed. I don’t know how but I immediately understood that a computer program should be more like a neural network. I knew that processors should be designed and optimized to emulate the reactive parallelism of the brain at the instruction level. I also realized that, for performance purposes, the emulation mechanism had to reside within the processor hardware itself.

Good Ideas Don’t Get Stolen

Soon afterward, I mastered assembly language and landed a job as a game programmer at a small company. I tried to explain my idea to other programmers but they either did not care or thought it was a dumb idea. I was stunned by their reaction. I just could not understand how seemingly intelligent people could be so blind to something that was so obvious. Surely, game programmers understood the concept of simulating parallelism with the help of two buffers and a loop. My idea essentially took the concept down to the lowest possible level. It is not rocket science. Someone even told me that, if my idea was any good, I should keep it a secret. I was then reminded of the following quote by computer pioneer Howard Aiken: “Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats.”

No Reason to Change

Over the ensuing decades, I developed a love-hate relationship with computers: I loved their potential but I hated the way they worked and the way they were programmed. I hated programming languages. I still do. I longed to do something about it but, even though COSA is dear to me, I could never find much time to devote to it. Like everyone else, I was busy making a living. Besides, I was preoccupied with another passion of mine, artificial intelligence, which is the real reason that I became interested in computers in the first place. I watched in horror as computer scientists turned computer programming into a complete mess, a veritable tower of Babel. The Turing machine was accepted as the de facto computing model. Hopelessly flawed computer languages and operating systems began to proliferate like mad. Needless to say, unreliability and low productivity wreaked havoc everywhere. A few people in the business began to complain and the reliability industry sprouted like a mushroom. Years later, the problem is still with us, worse than ever. Realizing that the COSA model is deterministic and inherently reliable, I got the idea of using the software reliability crisis as a springboard to promote Project COSA. That worked to a certain extent. A handful of people started paying attention but that was not enough to motivate the leaders of the industry to change to a better model. After all, since they had a captive market, people were making money hand over fist and so there was no real reason to change. Besides, the computer science community (mostly a bunch of old computer geeks who don't know when it is time to retire) still has a firm grip on the business.

Hooked on Speed

Buggy software, high production costs and late product launches took their toll but the industry was resigned to live with the pain. Even if everybody became somehow convinced that a solution to their problems was available, there was already too much time and effort invested in legacy applications to turn the ship around. But more trouble was lurking around the corner. As the complexity of software applications increased, the demand for higher performance also went up. Moore’s law took care of that problem for decades. Eventually however, the laws of physics got the upper hand and it became impossible to increase speed while keeping the chips cool enough. Disaster loomed. The industry could see only one way out of its predicament: multicore parallel processing based on an old programming technique called multithreading. Problem is, programming with threads is hard as hell. The solution is obviously not working and, lately, there has been an odor of panic in the air.

A New Opportunity

The COSA software model is, of course, inherently parallel and has been from the start. In addition, it does not use threads and is thus free of all the nasty problems associated with multithreading. Furthermore, since COSA is signal-based just like hardware components, it is ideally suited to compositional software construction via plug-compatible modules. In other words, fast and easy parallel programming, precisely what the industry is searching for. In the past, I never saw the need to emphasize the parallel nature of COSA. It did not occur to me until about a year ago that the only thing that would convince the computer industry to abandon its evil ways would be the performance issue. I saw it as an excellent opportunity to promote COSA in earnest. I made a lot of noise and a lot of people in the business are beginning to take notice. Still, I am a realist. The computer industry is like the Titanic and nobody can expect it to turn on a dime. There is a lot of inertia that must be overcome, not only in terms of engineering, but also in terms of leadership. And by this I am not talking about leaders in academia. I had long ago given up on the computer science community since I am convinced that computer scientists are the ones who got us all into this mess in the first place. They are not about to accept anything like COSA because COSA will make them look stupid. Only the captains of the industry have the power to decide its future course. I am talking about people like Bill Gates, Steve Ballmer, Paul Otellini, Hector Ruiz, etc… Problem is, trying to get the attention of people like that is like trying to get an audience with the Pope. Oh well. I am doing the best I can and it’s not over until it’s over.

The story of COSA continues. Stay tuned.

See Also:

How to Solve the Parallel Programming Crisis
Half a Century of Crappy Computing
Why Software Is Bad and What We Can Do to Fix It

12 comments:

João Bispo said...

I just found your blog and your project, and some of the ideas are interesting inded, but:

- I searched the website for sample programs (matrix multiplications, a sorting program, something) but couldn't find anything;

- I think introducing a 2D environment in programming has great potential for parallel programs, but using a visual-heavy style is not scalable for medium-to-large programs (there are human limitations in understanding a big number of visual symbols);

- There is a lot of text written in both websites... and a big chunck is about how bad the other people are doing things. If the time spent writing these things could be used to develope COSA, maybe it could advance faster =)

Louis Savain said...

Well, João, Project COSA is looking for a few passionate volunteer developers. This is an opportunity for you to work on a worthwhile project, one that will change the world. Alternatively, you can send me a check for a few million dollars and I will deliver a COSA-compatible multicore CPU (and computer), a COSA operating system and a set of dev tools for you to play with. It should take me about two years or less, given the right resources and talent.

In the meantime, you can take a look at Parallel QuickSort in COSA for an example of parallel programming in COSA.

PS. Regarding your opinion that visual programming is not suitable for parallel programming, I beg to differ. I'm preparing a blog article on the very subject. Stay tuned.

Brian said...

I think introducing a 2D environment in programming has great potential for parallel programs, but using a visual-heavy style is not scalable for medium-to-large programs (there are human limitations in understanding a big number of visual symbols)

Don't neglect that fact that the component nature of a COSA system is inherently hierarchical and provides a natural method of abstraction. Once a low-level component as been developed and its interface described there is no need to "look inside" in order to make use of it.

The same goes for a higher-level component consisting of multiple levels and numbers of subcomponents. Once a given level of component is made and tested, it can be used as a black box. The internals are of no concern. All you need to know is the component's interface / protocol (i.e. component X responds to input A with output B, etc).

A COSA system would have much more in common with a hardware block design than current software models. By construction, there is no way for the internals of one component to muck up the internals of another.

Jeff said...

The QuickSort example is good, but I would like to see how the "Swap" component is implemented. That is still marked as "Coming Soon" ...

Louis Savain said...

Jeff,

Thanks for reminding me to finish the QuickSort page. I got so many loose ends to attend to, it's not funny. I'll try to make some time for it this weekend.

Greg said...

Looks like FPGA assembler. No-one wants to program in that, and the point is that noone should have to - put your efforts into compiling a high-level language down to an FPGA or massively multicore architecture.

Declarative programming is performant enough these days that working programmers very rarely need to consider the underlying machine model, and can instead concentrate on the expressivity and maintainability of their code.


When you devise the compiler to turn high-level declarative (machine-model-agnostic) code into binaries that run faster on your pet architecture than the Von Neumann equivalent (cost-wise!), they'll build the hardware you're dreaming about, don't you worry about that.

Louis Savain said...

greg wrote, Looks like FPGA assembler.

Of course, it looks like an FPGA assembler. It also looks like Verilog and VHDL, not to mention a spiking neural network. I am tired of people dismissing COSA because it looks like a hardware design tool. This is exactly what it is supposed to look like. The whole point of COSA is that software should look and pretty much work like hardware electronic circuits.

Still, COSA is not intended for hardware design but for software construction. There are things that can be done in software that cannot be done in hardware. Random memory addressing and instant module creation are two examples. There is no way anybody is going to use an FPGA tool or VHDL to create a general purpose parallel Quick Sort component. It can be done in COSA.

Regarding your opinion that "nobody is going to program in that", I beg to differ. You obvioulsy don't know what you're talking about. Worse, the last paragraph in your comment shows that you have lost touch with reality. Fist of all, COSA does not eliminate the Von Neumann architecture. Second, how can a COSA compiler create code that runs faster on a COSA computer if the hardware that it is supposed to run on is not built yet? What are you, a comedian?

gaj said...

I still cannot understand why a COSA processor cannot be implemented in an FPGA like Charles Moore's Novix/Forth stack machine has been.

I read your article about how to design a fine-grained MIMD, multicore CPU. Modern FPGAs are easily capable of holding multiple cores. Why not implement a dual-core COSA machine as a proof of concept and every skeptic who reads your articles will be silenced. And if you think it's too hard for one man to take on, why not start an open-source project to build it. I'm sure there's a lot of engineers like me who have been designing hardware and writing software for decades who would be happy to contribute their time and skills to making COSA happen. Linus Torvalds wrote the Linux kernel because everyone he knew was writing micro-coded kernels and he was convinced it was the wrong way to go. But he opened open-sourced the project to make it bigger than what one man was capable of and the rest is history.

Simon said...

I would like to second what gaj has said. I think starting an open source project would be a good way to progress this, maybe targeting an existing ideal dual core software VM. Your ideas fit pretty closely with my thoughts on the deficiencies of modern computers and I'd like to see this furthered, as I'm sure others would given the chance.

Will Summers said...

Hey guys, I stumbled across this website looking for information on graphical programming languages. Right now I work as a compositor but I studied computer programming in college.

After learning the node based workflow in Apple Shake, Nuke, Flame and other high end video composting applications I was puzzled as to why I had never seen such an approach before in computer programming.

Shake started out as a scripting language but it evolved in version 2 to include a gui where functions were represented as graphical "nodes" and data was passed between them using "noodles". You can still jump in and edit the script if you ever need to but everyone pretty much works in this graphical interface.

I disagree with Joao about a graphical interface not being scalable. Because digital composting occurs on the computer all functions arise from basic mathematical operations such as Add, Subtract, Multiply and Divide. When a compositor wants to do something more complicated than this he doesn't have to build his operation out of these basic building blocks every time. He can just call a node that is a higher level abstraction of these functions. (An example of this is that an Over node for putting one image with an alpha channel over another image is really just an Inverse, two Multiplys and an Add node routed in the correct order.)

In this way a node can in reality be a group of a large number of other nodes. Artists share these code snippets on sites like fxshare.com so people don't have to reinvent the wheel every time they want to do something.

I find this method much easier to program than typing text. There are never any errors due to bad syntax or mistyped words. It is easy to see at first glance exactly what a script does by the way it is physically structured even for someone who is just seeing the script for the first time. It is easy to remember where something is placed in 2d rather than is a bunch of text files.

I feel like this method of creating processes is much more natural than typing in text instructions but the only place I have really seen it take hold is in compositing packages, 3d packages like cinema 4d, houdini, and softimage and some audio packages. I often wonder why this is, but I can't imagine working any other way.

Chris H said...

From what little I have read of COSA, it sounds intriguing - but the graphical programming language REALLY puts me off (and I suspect that will be the same for most people). IMHO you'd be better-off with a textual language, and when/if that takes off you can then try to introduce graphical programming (and good luck!).

I even disliked graphical programming for digital logic circuits, because you seem to waste far too much time drawing pretty pictures (i.e. organising where components shall be on your canvas, linking them up without lines crossing like spaghetti junction, deciding what shape your black box will have (square or tall/fat rectangle), jumping into & out of black boxes, etc). VHDL/etc by comparison is a lot nicer, partly because placement is effectively 1D (which line?), links all occur in your head (without getting in the way of each other) thanks to symbolic names, there is only a 1D list of parameters to order for any 'black box' (no shape needs deciding), and you can typically see your entire 1D program (or a larger chunk anyway) all at once - rather than jumping in & out of black boxes.

BTW, hopefully you won't feel the need to insult me (like you did with someone else), just because I'm not yet a convert to all your ideas. (That's a sure way to drive away many people who are potentially interested in COSA.)

rawbot69 said...

Hey

I am reading this COSA stuff- you are right on the money. In fact- i have spent over 100K developing this software and I am a year away from having a system like this at hand. It will have even more stuff that you have mentioned- primarily a visual interface consisting of some crazy good ideas.

Our thinking is practically the same - in fact, the only reason I developed it is for a game- in order to implement an insanely complicated animation system for a 3D character- only to realize that I have been working on something greater.

I have created a visual language and extended the visual programming far beyond the concept you have described.

Its been taking me quite some time- because my functions are thousands of lines in order to make the system SUPER fast.

I really don't care how long it will take me- and I realized this from the beginning that software development industry will never create a fully functional system of this nature within the next couple of decades. I believe you proved me right here, since you are saying you have been thinking about this for quite some time, and nothing even close has evolved.

Also, I believe the industry doesnt have this yet- fully implemented because of the amount of time it would take for 1 person to fully understand and utilize these concepts, even just to execute them and test them out. How about a team of 5 or more? That will take even longer !!! Our team is 2- I write logic- my other guy writes code in C.

This stuff is sooo good and so radical, that no business would have the balls to implement it because it is so unknown, yet we are walking around it- circling around in so many technologies- but never implementing it completely. In fact, the browser array of technologies HTML, CSS and Javascript, SQL - is the only thing that comes close in concept if all put together.

Well - stay tuned. I am bookmarking your site. I will keep u up to date ;)