Thursday 23 January 2014

Programming the IoT = Programming Parallel Computers

It's well-known that Moore's Law is over for single-CPU processing, and that the only way forwards is multi-core and parallel processing.

So given that, the way that we program these chips may have to change. Obviously, if you can easily split your application up into parallel, independent threads then you're fine to carry on programming in single-threaded Java. That's Web servers, of course. Even if your application has inter-dependent threads, you may still be able to battle on with the corresponding Java code and win.

But for any interesting interactive application, different programming models and languages are needed to take away the pain of properly exploiting parallel hardware - to make all that threading code go away in the same way as Java made all that memory management code go away.


The Internet of Processor Things

Now, at the same time that we're considering putting large numbers of small processors together in the same box, we're also considering scattering large numbers of small processors all around us - the sensors and actuators of the Internet of Things.

In fact, there could be more of those processors per hectare as was planned for in the extrapolation of the Moore line: in your 2014 house you may have 16 processors in Things and mobile devices, but only a couple of quad-core desktop machines. And the same ratio may hold true in the work environment. This ratio of scattered processors to co-located ones will probably only get higher.

Indeed, why do we need all the processors to be in the same box? Not all the processes need to share the I/O to the user, so it's mainly the need to communicate through a single physical memory and disk.

Which is the main problem with scattering: the processors have to wait longer to communicate. But we don't even know if that's a problem: it's application dependent. And in a future where your applications are sensors and actuators, multiple mobile devices, Augmented Reality, immersive Virtual Worlds and gestural interactions, it could be that wireless data exchange is perfectly good enough.


Declarative Programming

Either way, whether you're programming scattered or co-located processors, you should be able to program without worrying about concurrent thread interactions and process distribution.

You should be able to program independent active and interactive objects without needing to know yet whether they're microns or miles apart. Only timeouts should change. This isn't RPC [pdf].

Imperative, threaded programming will have to give way to Declarative programming - where we tell the computer What we want, not How to do it - it will be up to the implementation of the language to handle the mapping to threads and then to processors, local or remote.

Since we don't know right now what ratio of scattered to co-located will turn out to be best in general or in specific applications, a programming model like that in Cyrus, that lets us split and recombine our active objects with perhaps only minor code adjustments, will have a massive advantage.



2 comments:

  1. Do you think that Swarm Intelligence will be an important approach for this Cloud of Things as opposed to the Cloud of Servers?

    ReplyDelete
  2. I think it's going to be hard enough feeling in control of things as it is..! But yeah, that's what people are talking about, isn't it? Scary but exciting. The Object Net is a pretty good way of modelling autonomous interacting distributed things.

    ReplyDelete