The U of K work is fascinating, and though perhaps not directly related to hardware object technology, there are some noteworthy similarities and differences. To learn more, have a look at their website, www.concurrency.cc. My observations to follow...
You're back...now, my observations? It was interesting to see the occam language in use in 2010. I looked at it in the '80's, when we were evaluating the Transputer chip for a parallel processing system for graphic rendering. I recall all of our team members were very impressed, but we went with standard 32 bit processors, for the usual reasons: software compatibility and reliable chip sourcing. I find it interesting that such "outside" computing ideas keep surfacing, ideas that are profound but do not catch on due to market forces or the inertia of old ideas.
From watching the U of K video, I culled that occam implements communicating concurrent processes. The effect is like wiring electronic circuits, or piping in Unix. So naturally it lends itself to graphical representation as a block diagram with connecting lines showing the flow of data. I gather they plan on doing a drag-and-drop graphical programming environment. Cool stuff. Hope to go have a look next time I am in Kent! No kidding!
How does this compare to hardware objects? If one were to run a multitasking environment like this on an Arduino, you have one processor running many processes. With hardware objects, you have many processors each running one process (by the way, according to my definition, each hardware object has it's own processor).
Pros and cons? With a single processor, you have the problem of fitting the capabilities and cost to the problem at hand. A good fit might use 70 to 80 percent of the chip resources available. But typically, resources will either be under-utilized, or (much worse!) you will run out of resources just when you are on the verge of getting the system working.
With hardware objects, the door is open for the gadget to grow. OK nit-pickers, not absolutely true. But generally speaking, a multiprocessor system will more easily scale to fit the problem at hand. Want to add a text display? Just plug one in. With the single processor system, you'd be adding the text display code to your project, then hoping it would fit into the memory available, and hoping that the time required to process would not break your application.
With a multitasking system, as more processes are added, the processes already running will likely have to slow down, changing the behaviour. This won't happen with hardware objects, as the process owns the processor, so the exact behaviour of each object is known no matter how many objects are in the system.
One last thing, lest I start sounding like an overly-biased evangelist. While a hardware object system is not limited by processor resources, it _is_ limited by communication speed between processors. This is becoming frightfully clear to me. It is the crux of the matter, really. I'm working on it.
Actually, all points I would agree with. In our own work, we're interested in (and have) runtimes that dynamically take advantage of multiple cores. The Arduino is a good platform for us because it keeps us honest (forces us to stay small, reasonably efficient), and it has a large userbase. Truly parallel hardware is more interesting, and languages/runtimes that can dynamically take advantage of changing resources are, likewise, interesting.
ReplyDeleteAnd Arduino has become so popular, I gather there are 120,000 Arduinos out in the field now.
ReplyDeleteTo my recollection, part of the beauty of Occam is that it is designed to scale to however many processor are running.
Another point I find interesting about your work is how you built a miniature byte-code interpreter. I have taken a similar approach, based on the assumption that this would ultimately result in a more efficient implementation, memory-wise.
And I really do travel to Kent, fairly often!