Peter Vandenabeele

How it all comes together ... Na een aantal jaren in diepe embedded systemen (bij Mind), waar ik gefascineerd keek naar bepaalde massief parallelle embedded systemen als enige manier om de wet van Moore door te trekken (bijv. deze Picochip PC102 die met meer dan 200 parallelle cores op 1 chip, 197,000,000,000 instructies per seconde haalt, met een kloksnelheid van amper 160 MHz, of dichter bij huis de IMEC "ADRES" massief parallelle architectuur voor software defined radio, waarmee M4S een start-up aan het opzetten is), zag ik nu in dit zeer interessante interview met Dave Thomas, de auteur van het "pickaxe" boek over Ruby en mede-auteur van "Agile Web development with Rails" (op dit moment even mijn bijbel), wat ik dacht vooral op "application level" te zitten, deze quote:

<quote>
Q (InfoQ): So what makes you think that they would get it right in Erlang?

A (Dave Thomas): Because you don't have to worry shared state. Fundamentally, shared state is what makes threads hard. In threads you have memory that is shared between the different threads and you just synchronize access to it so you have to know where you have to put the synchronize key words and when to use a queue, it's really, really hard to do and what's worse it's almost impossible to debug. Languages like Erlang and I am not necessarily saying Erlang is a solution, but I think it points the way to the solution. Languages like Erlang have a different model of concurrency, in Erlang there is no shared memory, instead everything is done through a message passing. They also have a different model of error handling, in that they tend to say: "Don't do it!" Individual processes function focus on their particular function and then you have totally separate sorts of processes who are responsible for monitoring the world and working out if things have gone wrong and fix it up and getting it working again. so error handling in Erlang is a lot easier too, and as you know, writing multithreaded code with error handling and getting it right is very, very tough. So Erlang is a really interesting language for solving that problem and then on top of that we have another problem and that is Moore's Law is kind of breaking down, this idea that you've always got more performance just over the horizon.

It's true, but now you no longer get it in the same architecture as you used to get it. In the old days I used to get a faster processor, and more memory, and then I'd be happy happy, now I get a 2 core processor or a 4 core processor, or a 32 core processor and suddenly, yes, I've got more aggregate CPU cycles then I used to have, I can't use them, unless I can run things in parallel. So then I'm back to this problem. How do I do that? Do I have to use threading etc? And Erlang gives you a very elegant way of handling that, so it's a lot easier to write multi-core applications in Erlang than it would be in Java or Ruby or C# So long term I think if we're going to continue to rely on this ever growing increase in processor power as an industry we're going to have to switch across to environments that take advantage of that.
<end of quote>

Wel ... dit is de analyse die ik indertijd ook maakte: de enige manier om meer CPU cycles/Joule te halen is veel parallelle processoren op een lagere frequentie laten draaien. Zolang de silicium technologie verder blijft schalen en batterijen de belangrijkste kost zijn, is het echt zinvol om een grotere die te maken, met meer parallelle processoren, die omdat ze trager draaien, veel minder vermogen verbruiken ... maar de gotcha is dat je dit ook geprogrammeerd moet krijgen.

Dus ... even naar p2 gemaild (die onze CTO was bij Mind en nu bij Nokia interessante dingen doet met Linux op portable devices), en als we dan eens niet over "goa" chatten, krijg je dit soort interessante discussies. Voor p2 is dit evident, voor mij wat minder, en ik vond het echt wel de moeite om dit eens eens te publiceren (met uitdrukkelijke permissie van p2).

On Dec 4, 2007 11:02 PM, Peter 'p2' De Schrijver wrote:
> Ha Peter !
>
> On Dec 4, 2007 11:33 PM, Peter Vandenabeele wrote:
> > On Dec 4, 2007 8:52 PM, Peter 'p2' De Schrijver wrote:
> > > Eerlijk gezegd heb ik message passing altijd als het enige
> > > echt zinvolle IPC mechanisme gezien. De rest is veel te primitief.
> >
> > Euhmmm, message passing lijkt mij net iets heel "simpel" (dat net daarom
> > werkt :-) . Waarom noem je die andere systemen "te primitief" (hoe kan
> > iets nog simpeler zijn dan gewoon berichten naar elkaar sturen ... misschien
> > is mijn verkeerde assumptie dat dat nooit de bottleneck is, terwijl
> > messages sturen misschien soms wel de bottleneck is in een real-time
> > systeem...).
>
> Ik bedoel in vgl met andere IPC mechanismen zoals semaforen, shared
> memory, pipes, critical sections ed. Met semaforen kan je enkel
> threads synchronizeren, je kan geen data doorgeven. Met shared memory
> kan je dan weer enkel data doorgeven, geen synchronizatie doen (tenzij
> door continue te pollen, maar dat wil je uiteraard niet). Pipes zijn
> onder unix unidirectioneel en problematisch als je meerdere zenders of
> ontvangers wil hebben. Write atomiciteit is immers enkel gegarandeerd
> als je een write doet die kleiner is dan 1 page. Anders bestaat de
> mogelijkheid dat de data van een andere writer 'tussen' die van jouw
> komt. Aan de read kant heb je het probleem dat de data 'weg' is als er
> 1 reader ze gelezen heeft. critical sections en monitors zijn dan weer
> enkel synchronizatie mechanismen.
> Messages daarentegen zijn veel flexibeler. Je kan gemakkelijk meerdere
> zenders en ontvangers hebben door bv een adres in je message te
> steken. Je kan zowel synchronizatie doen als data doorgeven. Je kan
> messages ook gebruiken zonder shared memory. Semaforen ed kan je niet
> gebruiken over een netwerk. (welja, je kan ze natuurlijk simuleren
> door messages over en weer te sturen :)) Bovendien is messages tracen
> vaak een heel goede methode om bugs te vinden. Vooral bij shared
> memory kan het heel lastig zijn te weten wat er eerst gebeurde.
> Anders bekeken, kan je semaforen, pipes, critical sections en zelfs
> shared memory (niet erg performant weliswaar), allemaal implementeren
> mbv message passing. Het omgekeerde is echter erg lastig of erg
> inefficient.
> Messages sturen is ook niet zo simpel als het lijkt, zeker als je
> queueing hebt. Dan heb je ook een vorm van overload handling nodig.
> Verder is het natuurlijk ook meer werk dan gewoon een semafoor zetten,
> zeker als je bv ook multicast wil. Maar het hogere abstractie niveau
> (en de extra overhead) loont wel volgens mij bij complexere systemen.
>
> Groetjes,
>
> Peter (p2).
> --
> goa is a state of mind

This is what I call "fun" en daarom toch maar even op het net zetten (en het doet me ook terugdenken aan de fun die we met dit soort discussies hadden bij Mind). Hoe de visie van Dave Thomas, bezig met high-level application frameworks en moderne talen, matched met de diepe embedded power optimalisaties die we uit de transistor fysica kunnen afleiden, met daartussen het zich eeuwig herhalende systeem van "communicating processes". It all comes together.