How we program multicores - Joe Armstrong

thank you Eric [Applause] why don't programs run n times faster if you buy an N core computer then a lot of programmers just thought when multicores came along 4 core computer I can take my code run it on this thing and it'll go four times faster and then they bought these things and they found it wasn't true but the guy called Alex ganar Asst who was the chief he worked with Bill Gates for years and he was a chief scientific officer of America online and they were building a big thing and he decided when the multicores came along he decided to retool all their machine parts they bought these massive multi cause I think they had think I said there were some about 16 core machines I put all this and he did all this and he put all the software on these 16 core machines and hoped that everything would run 16 times faster and it didn't and he was he was very disappointed so so then he started looking at different technologies and different languages and everybody promised that you could make things go faster by using different technology tried all of these things none of them worked and then he tried airline and it worked factor didn't go 16 times faster we did it moderately faster without doing that much effort so it's quite happy about that I want to talk about this and some programming models and I was very taken by Peters talk because he said some things which resonated with me and used some words said that I thought very nicely talked that horrible words simultaneous and parallel and and concurrent and so he's done a bit of the groundwork for me know what Peter's been trying to do is to climb Everest because because making a concurrent memory model is like climbing Everest and and I'm not that smart so I don't want to climb Everest I just want to go up one step there at a time and so I can answer this question here why why doesn't my program run faster when I run it on on and core computer and that's because to do so I would have to write a parallel program it is difficult to write parallel programs extremely difficult to write parallel programs when programmers think about parallel programmers to start which they don't most programmers don't understand the difficulty sorry the difference between a parallel and a concurrent program when one of my books I spent a long time explaining the difference between concurrency and parallelism I've had a blog entry called explain it I had some entries in my blog called explain it to a five-year-old and there's a very simple example of what what parallelism or concurrent is outside when we have coffee there are three coffee machines and if you want to serve coffee quickly you can form three queues behind them and that's parallel concurrent would be if you had one coffee machine and three queues waiting for it and they very politely interleaved as so as they were going to get their coffee so parallel means sort of really simultaneous in the real world but then that's another horrible word simultaneous what I used to be a physicist so so and did quantum mechanics is that so so what does simultaneous mean for what we don't really know we're not talking quantum entanglement and things like that and spooky action at a distance if we forget about that kind of stuff and think simultaneous means what what means nothing in physics there's no such notion there is the idea of rays of light flying around and that happened before that if you saw that you've got the you have two stars explode if you two are stars and you explode at the same time and I'm standing here I will say this star exploded first but if I was standing here I would say this star exploded first so this notion of things happening at the same time doesn't exist in physics and so it's really a very bad idea to based programming models on the idea that you can violate the laws of physics with impunity if you violate the laws of physics when you build a programming language things become very difficult now unfortunately programming languages are divided into two categories there's the shared memory concurrency model and there's a message passing concurrency model and the shared memory concurrency model violates the laws of physics big time and is extremely difficult to understand and the message passing model also violates some laws of physics but it violates far fewer laws of physics that's much easier to understand and so it has this property of single sites where things happen so we don't talk about similar to newer do things like that we talk about single places which consume streams of events and oh quite easy to understand so there are a lot of languages in this latter category that's virtually all programming languages C Python all these use shared memory concurrency and concurrency actually isn't in the programming language at all it's in the operating system and this is kind of interface to it there one or two languages air Langille Exia pony which you've message-passing concurrency and of those I think Erlang is the only one that's kind of stable in the sense you can build large products with it it's been around for a while I think like whatsapp things like Ericsson so the infrastructure Farex is smart data things like that a programmed in in in Erlang and they work pretty well and they have billions of users using these things so programmers I think they don't understand the difference between concurrent programs and parallel programs and they don't like to learn new languages new ways of doing things because they've invested an awful lot of time in learning how to program in Java or C or C++ it's very it's extremely difficult to learn if what's not difficult learn new programming modes you can learn it you can learn a new language in two three weeks I think the syntax but it will take you several years to learn the libraries and the programming idioms and the way you're thinking it's it's it's changing the way of thinking that's the difficult thing it's not learning the language the language is just a syntax so basically all those first language ahead of Java JavaScript C C++ all these things you don't have to change the way you think you have to change the curly brackets and put a few semicolons in there's no difference between Java and JavaScript and Python and Perl they're all imperative languages more or less the same constructs all done more or less badly or well depending on your point of view but the way of thinking is the same and then you have other language families of functional languages of logic languages have constraint languages we've actually got to think differently and that's a barrier to learning programmers actually dislike complexity I think all these I as a programmer dislike complexity simple things which I can hopefully understand and I would actually love to be able to write correct program soon but I've kind of given up the notion of writing correct programs when when we write very big programs so I'm more thinking that if we write big programs they're just going to be errors in them these errors are going to occur at runtime and we have to live with these errors we have to fix them up and carry on and those programs have to evolve I'm not thinking of programs that are put in a machine you stop the machine and you change it they will evolve with time and run forever and there will be lots of errors so they become more like biological systems and we need to we need to understand how such systems work and today I think we've got into a horrible mess because if if you when I used to work at Aris if you walk around the corridors and you listen to the programmers talking they're not talking about how to solve their problems often them are talking about how to solve problems for their tools look it doesn't work or Jenkins doesn't work or how do you know these things don't work and so what problem is solving the main problem the problem is git doesn't work no no no no Ericsson doesn't sell knowledge about git or something Ericsson makes phones and things like that that they sell to people right so we want to make it easy to write parallel programs right we can't writing parallel programs is extremely difficult I just give up the whole idea that it's easy to write parallel programs so let's do something different let's make it easy to write concurrent programs we can we can make it relatively easy to write concurrent programs although we can't write parallel programs and then we can automate the parallelization of concurrent programs and people have tried to do that for years and largely failed I remember the efforts going on from rule the 70s to paralyse Fortran despite massive efforts I think they only managed to automatically gain 15% speed ups despite throwing massive brainpower of the problem it's extremely difficult problem but we can do it with multi cores and how do we do that well instead of letting the computer or some formal system decide the granularity of the concurrency you let the programmer decide that program is quite good at that I think they just identify what they think are concurrent processes and tell the computer don't let an automated system do that there's never been an automated system that can do that successfully I think it's quite easy to do it especially if you're programming something that's modeling the real world ok so the programmer decides the granularity of the concurrency yeah and for real world problems often they are parallel to start with so there's actually not much problem in deciding that granularity I mean if you were if you were building a web server for a million people you just make a million processes one process per person so that's a slightly different way of viewing things that concurrency is inherent to the problems you just need to mirror it in the architecture as a system so so one point I make which people don't really understand is is if you program in C or C++ or Java or something like that and you build a web server for a million clients or a million sessions that is one sequential program that's been persuaded to take care of a million connections by spawning off threads and doing devious things with shared memory and things like that the airline way of viewing that is it's not one process with a million clients using it it's a million parallel processes that know nothing about each other and each process handles exactly one session it's much easier to think about it and ideally we would put these on completely separated machines if we put them on physically separated machines if we have 1 million machines and put one server on each it's intrinsically parallelizable so two parallel eyes things you need to make them independent if they are independent you can horizontally scale them so the reason you can't make things faster if you have this case of massive parallelization is you can't horizontally scale and the reason you can't horizontally scale is because you've got shared memory if you've got pure message-passing you can do that so the granularity of a lot of problems and how you break things into parallel processes can be done by observing the world for real-world problems so here's I don't if anybody has anybody seen the video yes very good so we made a promotional video in 1992 for airline and it's got three people with me and Robert by the by that time the three of us working on Erlang and I say hello Robert that Robert says hello Joe and then I say hello Mike and if you wanted to turn that into some program code you can just map it we start here hello Robert so Robert bang hello Robert Robert receives a message and then he sends Joe hello Joe Joe receives a message which is he says hello Mike and we base that on observation so the code here is pretty much isomorphic to what we have observed so if we look at this picture text so so how many processes would we do to model this answer three the three people involved it wouldn't be five it wouldn't be seven it must be three in a lot of problems the mapping of the problem on to the concurrent structure can be done by observation right and this is what call Hewitt course physics modeling this is in here it's a description of reactor model so one parallel operation in the real world equals one parallel process very simple you just observe what's going on and then what do you do well what the airline system does is to make that into an efficient program you the programmer does this first step here describe the problem as a set of concurrent processes is rather easy spread the processes over the course that you've got available to do the job and then you measure and is it fast enough yep you're happy and if it's not fast enough you've got two alternatives you can manually map the processes over the course because you know more about it than than anything else or you can change the concurrency model maybe introduced more concurrency or let's go well help again so how do you spread the processes over the course well that's tricky that's that's very very difficult and fortunately all the people who program in our Langille one of these like don't need to do that because there are two or three people at ericsson who know how to do that so instead of having everybody who programs in a language have to do that it's better that you've got one or two people who really know how to do that if you were programming in C++ every single C++ programmer in the planet has to solve this problem which is an extremely difficult problem and probably get it wrong if you're programming in Erlang richard green and a few other people know how to do this and they know all about spin locks and knows what Oh T P this is C stands for open telecoms platform which is he kind of it's what you get along with this is this is Donna Ericsson has been like the difference between UNIX and C you could say the OTP is like UNIX and C is like airline so the airline programmers say they know nothing about how multi-core processors work they haven't a clue and the people who write the schedulers and things like that two or three people on the planet know how to spread this over the cause now scheduling is actually a very difficult problem if you're on the constraints talk Christian gave on Monday this np-hard problem if you have it's a knapsack problem if you want to pack these things into what have we got here ten jobs on eight processors is three point seven times ten to the sixteenth though it's N it's an np-hard problem and fairly reasonable if any there's not enough time in the universe to solve these problems it's very difficult so the best thing to do there is not do it this way at all but make sure that you've got lots of little processes packing huge big rocks into containers it's very very difficult but pouring sand into containers is really easy so if you think of processes like little grains of sand and you think of processors like big barrels that you have to fill up and filling your barrels up with sand you can pack them very nicely you just pour them in and it all work filling it with huge big rocks isn't going to work and when we program in C++ or any UNIX system actually which is which uses P threads it's like packing rocks because these a massive great things they they are the smallest size of a process was what is it somebody tell me 100 kilobytes 64 kilobytes something like that these are big rocks which we can't pack into memory nicely because the memory management hardware they really want very small processing and pack them nicely so how do we make it easy to write parallel programs all don't confuse programmers with a lot of different things just have three primitives which are in the language itself and not in the operating system so the three primitives are spawn which creates a parallel process send sends a message to that process and receive which receives a message and receive is a pattern matching operation in fact you don't send it to the process you can think of a process as something that's got a little mailbox and you can think of messages as items of mail and the send operation is the postman who sends a message and pops it in the mailbox and the receive operation is somebody walking to the mailbox and looking through it and pulling out what they want and then going and do something when they've done that they go back to the little mailbox sort of open it up and see if there's anything to do and it's all very nice because the process it's doing that is purely sequential and we understand sequential programs much better than we understand parallel programs when we implement this the Elling virtual machine compiles this down to single in struggle it's a it's it was originally a bytecode interpreter it's now it's a word interpreter but but these are single instructions send Sporn receive were in my original airline single bytes the hardware people didn't make those instructions they made completely different integer loads and stores and moves and tetes and they have all these instructions that I don't want and they don't have the instructions I do want so when you're designing a high-level language you say oh well I don't yeah I don't care what instructions see that machines got because he's a far too complicated for me to understand I will invent an instruction set which makes it easy to make my high-level language so for example if you look at the if you look at the JVM the simple state machine got almost the same architecture as the dotnet machine that's the simple push and pop stack machine very easy to understand and they all go back to 2v it's P code machine the simple snack machine with pushes and pops on and then what you do is you emulate that in a program and people like Christian with his nice compiler project work out how to map the instructions that you didn't want sorry they work out how to map the instructions that you did want onto the instructions that you didn't want because the instructions that you didn't want are the ones that the hardware people have given you because they never talked to the high level programming language designers if they did they would be like jars more in and make the the fourth chip that's got the instructions that you do want right so a Lang doesn't have any of these it doesn't have shared memory it semaphores and mutexes and monitors and spin locks and critical regions and futures and thread safety and all these horrible things which are incredibly difficult to get right just just make life easy by having pure message passing we just send messages they're copied in their entirety with no no messing around with pointers you either get the entire message or you don't the failure semantics are the same as in the real world if you send a message to somebody that either gets here or it doesn't end you'll never know which is just like the world behaves so you have to ask yourself that why do we do pure message passing oh and isolation these things got to be isolated as well well actually there's one programming model now one thing that I've always thought is kind of crazy is that we have different ways of programming systems depending on the scale of the system so if you're programming an application on a single core machine on one computer you program it one way and then as your problem gets more complex maybe you exceed the capacity of this single computer you want to program it on two or three computers instead of one and suddenly the entire programming model degenerates you've written it in such a way that you can't run it on two computers so the way we the way we start to write a lot of programs is first of all we write them on one computer maybe the capacity of that computer isn't and we we buy a more and more powerful computer and we scale it up when we scaled it up and then one day suddenly we can't do it anymore on the one computer we need to use two computers but suddenly we can't run our program on two computers because we've written it in such a way that we can only run it on one computer but if we had written it from the beginning using message passing between isolated components on the single computer then when we put it on multiple computers it's going to scale nicely so I really don't want to program these different things in different ways I don't want to program this in well here's a is a nicely you showed this very beautiful diagram this the way we program that you writing a small program and then looking at the architectural things I have to do it to turn into a big program I would suggest we should start by writing a big program and then scale it down to the case of a small program so if you if you if you were going to imagine you're going to write a sort of web youth sort of service or of Internet of Things thing or one of these things there will be two ways of doing it one is you could say well how many what should I do I mention this system for well we said 100 users or something you may get 400 users and then you deploy this thing and you find woke up a thousand users so to have to then start scaling this thing up and that can be very difficult I would suggest it's much better to start saying so so how many users could we have why don't now I usually say start with 10 to the 10 to the 50 users because they're attentive ten to the fifty atoms on the planet we say ok so let's assume that every atom wants its own web server or whatever and and so we make the address space to work for 10 or you might do it for the entire universe but that's daft but you'd start off with some unreasonably large number and then you make your architecture to work for that and and then it's going to be and then you scale it down to your 10 users it's still going to work for 10 users because you could be dimensioned it to work for 10 to the 50 users you scale it down to 10 users and it works very nicely of course that will be less efficient than somebody who started with the problem say I will make a system that handles 10 users whoops what happened I pressed a button by accident oh oh goodness sorry so when you're showing off this stuff the Erlang stuff come to the C++ stuff the first reaction of people will say ah yeah but my C++ thing is five times faster or 10 times faster or 30 times faster than the Erlang thing and I said yes but you're only doing it into the main that's on scale when you go into this big domain you'll but you will see an opposite effect and that that appears to be true basically cuz you can't build very big systems in C++ because you have to start addressing the same problems that we have addressed in Erlang so for example if you deploy a system with billions of users over a long time scale it's going to be impossible to keep it consistent you can't change the software by stopping the system changing all the software and restarting it you have to live with evolution you have to live with errors errors will occur we're moving to an age where we'll have light emitting diodes sending messages to each other why life I going in 10 20 gigabits per second in each light bulb there will be a processor that's probably 100 Cray ones computational equivalents and we will build this massive super duper message-passing supercomputer which we do anything we feel like we just got to kind of think of something you learn and nobody actually think of anything useful to do with this so we could we can remotely control a kettle or something like that but we've got this fantastic structure we want a program in the same way in a scalable way so so with pure message parsing we we can handle failure I'll talk more about that later because I've got some separate slides about that so the details how did the original airline work made it a good design decision round about a long time ago about 1980 you know in or something like that and was every process should have its own stack and heap and there should be no shared anything no shared garbage collection no shared anything at all that turned out to be a very good decision strange enough robert robert knight who who would then working on airline always believed that one day somebody would come with an application where we needed shared memory and and what we would do when that day came well if they came through something what would really need shared memory because it's not efficient enough then then our strategy will rewrite it our way and hopefully it will work and if it doesn't work then we will give in and do some shared memory and we never did it never happened oh well it's not quite true well I've got eight stables for building massive databases because you don't really want to copy the entire universe if you're if you've got a database representing the entire universe and you change something in it well you can't make another you know the universe is everything so it's not like to unit world basically from brain universes but we couldn't access him anyway so the original reason for this has got nothing to do with scalability and it's got nothing to do with performance it has to do with fault tolerance and the problem with shared memory is not Peter suggested the problems with proving or demonstrating what would happen when you go into a critical region my problem with shared memory is not so much that you can't correctly lock things and go into critical reasons it's what happens if a program is in the critical region and crashes because it's changed the memory in some way and then it crashes well sure a monitor can detect this fact and it can tell the other process ok so now it gets removed from the critical region the second process comes along and said well I have but what happened to that other process well people like Eric Scott will have got transaction memories for that oh that's great that will solve your problem yes but it doesn't solve it at scale it solves it locally so I still got that problem at scale when I've got something in Sweden talking to something in America where do I put the shared memory I mean do I put it on a submarine in the middle of the Atlantic or there it doesn't exist it's two different memories talking to each other so failure failure is difficult to do failure have to ask yourself what happens how do i how do I write fault tolerance software what happens if the entire computer crashes I'll talk about divide by zero in a thread and talk about the entire computer crashing well you need two computers or more than two computers if you want to be very fault tolerant and so did you take two computers let one computer take over if the other fails and so on they can they can fix up the errors for each other if you think about that it's impossible a third if the shared memory if there are dangling pointers on to the remote machines you can't do that but if you've got pure mess apart you just send everything over in messages you you can handle failure you just make sure that what you send to the other machines is sufficient to recover from if a failure should occur and you monitor what's going on SMP like this came a little bit later and now we actually had physically separated cause and so basically the same the same model that ran on a single core was now running on a multi-core type architect repellent processor architecture and there's some special things called schedulers and their job is to move the processes between the cores at regular intervals so they interrupt the system now and then and move the processes and tinker around with these things and hopefully if you've done a good if they've done a good job you don't you spend a small amount of time in oops I'd need to stand here point this you spend a small amount of time here and a large amount of time here you're monitoring what's going on and moving things around and the goal actually is slight later but the goal in the Erlang system is that if you have written your application with with a reasonable balance of processes and you have n cores that it would speed up by not 0.75 times n without you doing anything so that would mean that if you if you have a hundred core computer hopefully it will go 75 times faster without you're doing anything to the program that's almost equivalent to saying well let's say the 25% of the work it's going to be done in this horrible bit where you're actually deciding to move things around remember the earlier slide what I said you can you can pin processes that's that's where you say well because I know how my problem works I'll actually stick these things on this corner and I use the scheduler to move them around I'll tell it and there is it's been speculated although it hasn't been demonstrated that well some of the network on chip architectures it would be sensible to do things like TCP things on the chips on the edge of the chip and then put the database in the middle of the chip or something like that and sort of move the me then actually pin them to the right course because there are memory issues and there a propagation delays you want to go through a cause and things are there it's not really a good idea to do that because you then venue by pinning things onto course and things you you haven't made your software future proof so when a new architecture comes along you can forget about that and you'll have to redo it so it's better just to let the system do that for you right so err Lang is just here's some CPUs five CPUs each one's got its own memory and these little colored regions they're the shared memory and then there's some sort of tree of locks and things detail I won't bore you with the details but they're kind of complicated so what does this migration logic what is it do it does load balancing process migration schedules into process message passing and the goal of all of that is to make a small core that can move things around and that it's non locking and as as much as it's possible so once we've isolated the computations put them on separate course on separate physical computers we get four additional benefits I mean the first benefit is reliability because if the probability of failure in a given time for one computer is ten to the minus three then if you have to the probability they both fail in the same time interval is 10 to the minus six so if you want 109 reliability you just get 34 computers get them all do it in parallel really easy but a key to all of this is independence that you really do have completely isolated computations in fact that level of reliability also be isolated power supplies and everything else because the planets power supplies aren't going to be tending their 9910 what reliable I mean they're going to fail every million years or something so scalability we can easily scale horizontally of all the processors are independent and we can use that to solve massively parallel problems so massively parallel problems are extremely common the world wide web the Internet is a massively parallel problem it's in its nature has two billion people talking to each other and I think Ericsson says that we 50 billion connected devices all sort of chatting to each other so we do have 50 billion things just all going on at the same time so it is already parallel it is already distributed and is already sending messages the DAF thing is with programming in languages which which are semantically completely different to that it's not a good idea at all makes it artificially difficult we also by isolating things and using message passing we make them simpler because it's easier to understand small things that exchange messages than it is to understand big things that don't exchange messages and the reason is pretty simple if you have a black box and you want to understand the behavior of what's going on inside the black box all you need to do is observe the inputs and outputs and tie them down and write down some equations and some some reasoning about what's going on inside the black box and of all the principles of computer science I think my favorite one is this principle of observational equivalence the two systems are equivalent if you cannot distinguish them on a basis of observing the messages are go in and out it doesn't matter how you've programmed the inside of the black box you can program it in Fortran or COBOL or JavaScript or C++ or anything else it's totally irrelevant for that I did it behaves the same way that's very nice because describing what's going on in the interface is considerably easier then describing what's happening on the inside and of course if we were to open up this thing it should be compositional right so inside this black box we should find more black boxes and we would recursively describe the system and it becomes compositional and we can immediately if we want to do that in hardware or software that at every level of abstraction that's saying okay I need three parallel processes at this level of abstraction to model listen to write the program pride now all these things are just communicating with messages this is actually how I build build hardware we get chips they all run in parallel they're all clocked and they all run in power we connect we wire them up to go in your words it is not how most people make software it's how but I'd like some type make it that way just make these processes have more or less like chips you just wire them up together this works it's very nice another benefit of doing it this way of sending messages and things is we obey the laws of physics I used to be a physicist so I like that so I'm saying we've a Basel laws of physics so what what laws of physics are we obeying well first one is it messages propagate at all less than the speed of light unless we believe in quantum and all of anybody do bells experiment yesterday I did know nobody all asleep well it's good fun it's a big massive experiment of bells hypothesis to see if quantum entanglement work that was done yesterday all over the world I participated in it by hitting naught someone's on my computer at random causality this is a nice principle if B depends upon the state of a an A or B a separated space then you must send a message to B before we can do anything you you know you can't do anything until you've got some information that has changed another law facing simultaneity in two different places in the universe impossible we can only talk about simultaneous things when we're at the same point in space-time and and there's a deal of confusion about this most of the problems in say for a computation to take place the program and the data have to be at the same point in space-time if from different points in space-time you can't perform the computation see if I forgot to move the data to the program we're going to move the program to the data or can move no for them to somewhere in between and what we traditionally what we conventionally do is we move the data to the program which is why we have huge big server forms we don't move the program to the data that's it stupid because all of this costs energy and it's actually daft sending gigabytes of data to a data center to be analyzed when the program analyzes it may be a few kilobytes what's more sensible to send the program to the data what might be even more sensible to send them both somewhere in between to optimize latency or security or whatever you want the other disadvantage of sending data to somebody server if you have to reveal your data to not only the people analyzing it but to all the security agencies in the world will have a quick peep it it to see what it is at the same time but if they send you they'll analysis program you don't need to reveal your data to anybody so if not more sensible to keep your data to yourself and ask for the programs from the service not the other way around it also avoids the problem I've been blackmailed by Apple and Google and all this in who will store all your images and cloud somewhere and then charge you 100 dollars a year in order not to delete them and of course message parsing or I should say that we only have to make this point because it people don't understand that we we don't really understand how things are now we understand how they were the last time somebody told us so I don't I don't know I don't know if my wife is healthy and and in good health and everything but the last time I saw her she was I mean she might be dead I don't know but I'm living in this illusion that she's quite happy and working where the bank at the moment but of course she might be dead but since I don't know that fair happy don't think she's dead I would be have to leave the lecture rather rapidly if I got a call and of course Alan Kay who coined this term object-oriented programming I like this mailer I talked to him a couple of weeks ago I interviewed him and we're in great agreement the big idea of object-oriented programming is messaging and this this it's not about abstract data types and classes and methods and all this horrible structure it's about messaging and the one thing that object ordered languages are Java and C++ don't do is messaging which is rather strange so why I tell people that airings the only object-oriented language there is because he does messaging properly right does all this work yes well I mean it's a good question um yeah so I am when I was working arity so well did you have to change the original design to make your program go faster if they say no it just went faster then I would say it does work I was at one meeting where we had a Thai Lyra 64 computer 64 core machine and done I can't member applicator tip sack or something on it and we had this meeting and I said the student had done this thing and it went 33 times faster on a 64 call machine without them changing the software at all and management were not replaced then why why doesn't it go sixty-four times faster you got a 64 call machine and then I said well are you pleased that it goes 33 times faster or unhappy but it doesn't go 64 times faster and I said well we're unhappy that it doesn't go 64 times faster and I said well just remind me that other project that was doing my C++ how much faster does it go and so it's still stuck at 1 it doesn't go any faster at all so I think we did achieve a small goal there and our goal was some I said that earlier to go seventy five point seven five times faster if you've got the right concurrency modern written your program in a reasonable way but that responsibility is the program is no automatic systems can do that for you you have to look at it figure out what concurrency you need that's all of this work yeah well it looks for things like whatsapp Clara and Sweden Ericsson I've just added I was in China that was three four should be invited to China last weekend and the Alibaba which they say is the biggest web site in the world uses a lot of air like to do it and and I went to a company called Ezz mob which is sort of the Chinese whatsapp we have very surprised when are they inviting me there and yeah work for that kind of doesn't work for I mean I know your talk couple years ago you don't like super ways of inverting matrices and things by sort of jiggling around and working out the time slots it doesn't work for that kind of stuff but most people don't want to well I don't know I'm going to say most programmers don't want to invert matrices and things but and anyway they'll use a library to do it if they want to jiggle around fast but they want to write these funny web things so does it scale nicely would here's whatsapp this was a presentation given in well I remember the earth Duvel this has 2012 it shows the scaling of whatsapp whatsapp written in all the servers written in LA and they were quite pleased about this and scales nicely and then last week I I learnt this this guy from Easy mob showed a slide because I had an airline afternoon in Beijing and I was sir and here this is the sort of company I never heard of it I think they consider themselves to be the Chinese what cell but they don't do a service to the end-users they do this thing here they provide a platform which is written in Erlang to connect apps together and there's a paid service and a free tier and in China 80 2149 apps are written using this back-end and I thought no 89,000 uses no 89,000 apps and those apps are serving over a billion users so so they're kind of in this whatsapp space in it in its scaling quite nicely so this stage I think we should say well what you know where are we going and what problems ought we to solve Alan Kay says we should just throw all this stuff away and start again from scratch I think if we were to do that we would not make the mistakes we've made in the past well one of the things you didn't say is you know why don't you just sort of throw all this stuff away and do it properly or what we've come to it properly we could make another attempt at doing so we've now got super computers absolutely everywhere and we're loading them down with legacy software which is probably bugging in incorrect and we haven't a clue what it does or how it works it was written with specs that nobody can understand and it's a complete mess it's one of the big problems well want to minimize energy store stuff forever well not forever until the Sun becomes a red giant we certainly don't want to lose our history but by putting everything into the cloud we rather tragic in two or three hundred years if we're to go back and say well then where's all this stuff little we're sorry we put it in the gutter and I was minded of Peters response I I met her I was a photography book and I met her high up technical I think that's a technical chief it facebooked I said so what happens to all our pictures and stuff that we take when we're dead you know how how are we going to find you know people could have find a relative something's going to find this in two hundred years time and he said that's a very good question so and they didn't have an answer to it actually so I'm kind of worried that we will lose all of history forgot to figure out a way of storing it for a while a security we need to figure out how to make these systems secure the system at the moment is very brittle if people it's not this it's attackable if if if the attack rate is higher than the repair rate we could destroy the entire internet so these people have installed Trojans in light bulbs and fridges and ions and dog feeding devices once they've taken control of those things I don't know if you can get control back because there doesn't appear to be at upgrading mechanism for very cheap devices so once these things have been pirated they're pirated forever if they can put new stuff in and attack it quicker then we can knock these things out we could potentially knock out the entire internet and then you'd have to close off whole bits of it and quarantine it it would be like it would be like the Black Death it would cause millions of deaths and the only way to do it would be to quarantine it and rebuild up something from scratch this is a real problem actually we need to figure out how to make systems that evolve and we need privacy and then because all these things are removing jobs we need we need economic models that take into account of the fact that we can do a lot of things with computers instead of the people right so what do we want what would I like the hardware people to do hi I would like hardware these things that are a single byte in my language or a single instruction I would like them to do that in hardware - I'd like a synchronous message passing I'd like all the parsing of the messages to be done in hardware that's where most of the time goes just put some FPGAs or some VLSI to parse JSON or XML or whatever the crap is that you send in don't do it and software at all do the message cues in Hardware do the failure detection in hardware do some secure data lockers in hardware give me cryptographic checksums in hardware and small CPUs with lots of instruction was a few instrument need not ten instructions will do I don't need lots and I need actually a bit of memory quite a few megabytes and I'm sure Peter be happy if we just had machines with ten instruction to make life a lot easier for everybody want low-power want session types and things to describe the boundaries of what's going on we need evolution mechanism so so we run systems forever and they will just grow we can change them in time and we need together with security as they evolve we need to make all this secure so I think that's these five minutes quest I think this I think Eric was that meant five minutes I believe so any questions I know there's one up there but do we do we have any from the floor hello Peter so the the message passing abstraction is a very attractive one it's a very clean one but I'm forever struck by the fact that our systems actually end up being a stack of alternations we have hardware which is implemented with message-passing interconnects on which the architects build shared memory abstractions on which you build message-passing abstractions on which presumably other people build distributed shared memory abstractions so I don't I can't see either of these is more fundamental so if if you're building these large systems above a message passing base I imagine but I ask you whether in fact you've pushed a whole bunch of complexity into the distributed protocols and I've written some pretty hairy distributed protocols they weren't easy to understand just by virtue of being written in messages and their failure behavior is not necessarily easy to understand so what do people end up actually building I think when they're doing these big things but the problem with figures are based on message passing is yes you do want check memory to some extent and then you get into one or two basic abstractions you need to build on top of that for example leadership election is one of these critical abstractions you need to do that is something that is horrendously difficult to understand and to implement and get correct we don't even know if they are correct and so it's I think better to hand that problem over to some theory people and say okay could you could you kindly prove that this algorithm is correct for us and we'll be one of these little building blocks that were used to build things and then I would say to people if possible can you re are koteki or system so you don't need for example leadership election or global memory quite often you can re are koteki or problem such as you don't need to do that so for example if if if my bank account details were held at me and not the bank it would be much easier it's the fact the bank is doing it and I can access it from different channels makes it insecure so if you can change the architecture to you don't say the kind of black magic and magician magician has sort of done something waved his hands and changed the problem slightly to make you one that's tractable but yes something that it's offered for these large-scale distributed systems so I've heard talk some people at Google describes a enormous number of different services they have interacting and all to answer our web query so if they were building that inner line do you think that would be particularly simple oh no but you see I think it would be simpler if calculate gives give us a nice example he said well if if you have central servers and you are some things you leak a lot of information about yourself to them so so if you go to a as I want to book an aircraft or you know I'm going to go on holidays I want to book a higher car a hotel in an aircraft and I go to some booking site and say of them robot this aircraft trouble is everybody spying on me and listening to this and advertising services coming in so when I when I go and try and buy a higher car they already know that I've do that and that they model their things according to that because as you do computations you're leaking stuff all the time so it's a card here it says much better to keep all the day to yourself and see if you want to if you want to book an aircraft you could go to the you know 10 airliners that you're prepared to fly with and say can you give me your little program that I could run on my computer that whose validity is half an hour or 10 minutes and you can run that locally and then you can tell them and you can get the hire car and get the hotels and you can do all this you don't leak any data nobody knows what we're doing you're just requesting programs so I think I think if you kept all your data to yourself which is your which you make the point in your lecture if you have the single point where all your data it's much easier and that single point should be you should be and your wristwatch or somewhere you can have all your personal data they you shouldn't put it in you shouldn't let Apple or Google or anybody else own that and you shouldn't let them provide all the services for you you should define what the data is and then you should get your substrate interfere there will still would be this problem of how it interacts it is not going to go away those are essentially synchronization problems but maybe we should be getting an integrated religious questions so you have a couple of questions on the screens on the Left one so what do you steal what the data do you still have if you put airline on a single shared memory machine Linux machine what I thought is you good what are you here to program Syrian easier to program easy to program yes but but the failure is the same is yes yes yes and then you can develop your I mean the nice way of developing probe you develop it on one machine and then you just deploy it on multiple machines it will have the same semantics only the message passing times with the latencies will change but everything else will stay the same so what's your opinion about the enterprise bus architecture that does is now does it blessing me I think that's a marketing term rather than anything else I've never really understood what enterprise bus architectures are they they show very they show block diagrams like like Peters first diagram which I never really understood what they are and I've never actually worked with an enterprise bus architecture I don't really know I have a question myself so I know that you know you started peeing in your pants in the middle of the 80s I've never peed in and it took a long time it really took a long time before Airlines started to get adopted outside of the group it was a big struggle it was quite depressing at times what what was the big game change what why why did people suddenly start to use airline outside was it because this happened before multi Cory wasn't month ago they did that what started it outside was Erickson banning it because that led to his becoming open-source and when it became open-source it started spreading so that was the main reason why it started and then it's kind of picked up over the years [Music] usually it's it's been something like whatsapp I mean what's happened to quaff it was written in a line by twelve inexperienced programmers and they sold that company for nineteen billion dollars and that gets a lot of positive publicity there were some newspaper articles that saying that freelance airline programmers were the highest-paid programmers in Silicon Valley and that it's that kind of stuff that causes it to spread so it's positive publicity and things like that it's always been a bit of an uphill struggle because because you have to think slightly differently and you know it hasn't got it has got a different syntax and syntax worries a lot of people but but also certainly multicores has helped helped a lot as well in option because this was a lot about scalability that you talked about here right I don't know if it helped us such a minute it's all happening at the same time so you can't really point to any I think it was more the horizontal I mean we could scale out horizontally without multicores and it was that kind of scalability that was was first beneficial I think I mean what's happened using using sort of thousands of machines horizontal it's a horizontal structure that they can build in a convenient manner that attracts them to it perhaps not so much a multi-core bit as such it's let's do one last question from from from the wall there so do airline programmers do they have to manage star starvation is that it could they potentially create a stove a cake or they're dead look problem it's surprisingly I mean everybody said well can you prove the absence of deadlock or light you know live lock and things I don't know no we can't of course does it happen in practiced often I would say it's incredibly rare it's a surprise in practice it happens surprisingly infrequently and and I think one of the reasons for that is that the libraries with some generic libraries which implement servers and decision dream and sort of supervision trees and things like that written in such a way that that won't happen with them if they won't then you won't get deadlock and things like with them okay I mean if here it can happen in practice doesn't happen much and usually if it does happen it's easy it's pretty obvious what's happening you can find out pretty quickly and fix it so I think we'll transition from from questions or all the columns thank you much [Applause]

Channel: RISE SICS

Views: 52,933

Rating: 4.9391637 out of 5

Keywords:

Id: bo5WL5IQAd0

Length: 58min 52sec (3532 seconds)

Published: Thu Dec 01 2016