2 Comments

Summary:

Jeff Dean, a Google Fellow who helped develop some of the web giant’s most innovative infrastructure projects, says focusing on one problem at a time is crucial for success


Transcription details:

Date:

19-Jun-2013

Input sound file:

1003

Transcription results:

Session Name: Behind Google’s Evolutionary Leaps.

Joe Weinman Derrick Harris Jeff Dean

Joe Weinman 00:00

The architecture and power performances consumption and everything, so we are privileged today to have one of the deepest thought leaders at Google – Jeff Dean and Derrick Harris is going to have a little discussion with him on stage. So this should be really fantasizing. Please join me in welcoming them.

[applause]

[music]

Derrick Harris 00:25

I should thank you right of the bat I think I owe you a debt of gratitude, because if it weren’t for the map produced paper I wouldn’t have a job wiring about Hadoop all day, so I thank you. But I kind of wanted to open it. I think too it’s kind of interesting as I watch the world at large kind of come around to map producer Hadoop, let’s say that the implementation of the map produces something that might have value – Google has kind of famously for some – more me at least well beyond. The things I want to talk about the transition from the map produce era to now, at Google and what drove these things?

Jeff Dean 01:10

I think one of the things that have caused us to build infrastructure as we were often doing things out of necessity, so we would be running into problems where we needed some infrastructure that would solve that problem in a way that could make it so that it can scale to deal with larger amounts of data or larger amounts of requests volumes and all of these kinds of things. There’s nothing like necessity of needing to do something to cause you to come up with abstractions that help you break through the forms. So map produced was born out of needing to scale our indexing system. We had a large number of phases and all they kind of looked similar in some respects, but we’re doing slightly different computations. But if you look at them we all wanted them to be – each phase to be robust, reliable to be able to be paralyzed off the machines, to be able to run on as many machines as we wanted to throw at the problem and have that happen automatically. And so that was what started us down that path of having these scale abstractions.

Jeff Dean 2:18

Then over time we built other higher-level abstractions that helped us deal with other kinds of problems. Some things like big table came about because we wanted to have – we had a lot of data sets where we had a particular key for data, and then we had lots of different kinds of attributes of data that we would collect over time. One example is our calling system has URLs and then a bunch of associated information about it. I think we have all of the different versions of pages that we’ve corralled over time. We have other processes that are going around in the background and computing what language we think this document was in, or how important we think this page is, computing page rank and so on.

Derrick Harris 03:06

Sounds like the applications drive the engineering, right? As in the case of the–is everything a reiteration on something previous or is a case we say, Here we want to do–how do we build a system that can handle this?

Jeff Dean 03:22

In a lot of cases we do say, Wow we have all of these problems and we really like a system that solves – addresses these four or five problems, because they’re key operational issues for us. Spanner I think is a good example. Spanner is a system where instead of having lots of separate instances of storage systems in different data centers around the world; we have one global main state for data and you can specify for a given piece of data how you want that replicated at a fairly high level.

Jeff Dean 03:51

So you can say things like, I would like five copies of this data, three in North America and two in Europe and then the system takes care of that for you. And so if we need to decommission a data center or upgrade a cluster in Europe the system has the flexibility to move from one European data center to another while satisfying the constraints the people have.

Derrick Harris 04:12

What kind of workloads are you setting up the Spanner for? That’s the epitome of what you might have thought of cloud computing when it started, like it’s in the cloud somewhere. So it’s really in one data center but this is literally – it’s in…?

Jeff Dean 04:24

Yeah. Ironically the first customer we decided to – internal customer – we decided to put them out as our ad system, which was maybe not the first. They’re a pretty demanding customer that don’t want to lose data. So we used it initially and worked very closely with our ads team to get that–I think one of the things about developing infrastructure is that it’s really important to work closely with a small team that is going to be your first customer. Because that rapid iteration you get feedback on which things are working well, does this interface work well – I like this feature – is much better than if you have very separated first use of this thing where you develop it in isolation.

Derrick Harris 05:13

Just so you get a sense of–based on how much these systems scale across applications so as is the first. But you do have a sense of where you might look at–what you might deploy on something like Spanner next? And you build these things with a sense of, we might one ideal use case in mind, but they really have to be easily applicable to many things?

Jeff Dean 05:31

There’s always this tension when building infrastructure. You could try to solve all problems for all people and then you usually end up with something that’s not very good for anyone, because you’ve made too many trade-offs that make it so it doesn’t have a good performance or it doesn’t have some attributes that you might want. It’s good to keep a few use cases in mind, and for Spanner the main use case was people who want to deploy internal Google products across lots of data centers. And we were spending a lot of time prior to Spanner managing different instances of their data and manually configuring – I’m going to run this data center now, and I have another instance in this data center – it’s just a lot of mental effort to keep track of. So Spanner kind of removes a lot of that from a lot of different teams.

Derrick Harris 06:21

I was reading a Google Research Blog Plus the other day about image recognition in photos and I thought it was fitting. It was well we found this new model from this competition with image recognition we just happen to have a system in place for analyzing on a large-scale neuro network data. It’s kind of geeky at the data level, but can you kind of just discuss it, so it’s a big machine learning problem and or not something Google’s been a lot effort into lately it seems. Can you talk about the importance of machine learning and the importance of the infrastructure the systems as a part of that puzzle?

Jeff Dean 06:58

I’ve been working on a machine learning system for the last couple of years that is using neuronal inspired – biologically inspired neuron networks. The idea with this is you have very raw forms of data, it could be pixels in an image, it could be the spectrogram of a small snippet of speech. And you build up layers – each layer kind of builds on the layer below in terms of building higher and higher-level representations of the underlying data. For example on images if you have one of these models the first layer of neurons learns to be receptive to edges of different orientation. So it might be very simple features like is there an edge at this orientation here, or one here? And then as you go up the hierarchy the system automatically learns more complex features. Things like corners or a little bit of an invariance to exactly what angle something’s at, and as you get to the top of these very deep networks you end up with very high level features. Things like does image contain a cat? Which was one of the things we were working on in an unsupervised manner we were training these networks and we found neurons that have actually developed that learned to recognize later an image contained a cat, without ever being told what a cat was.

Derrick Harris 08:22

So that seems like a lot of effort to figure out–to recognize a cat. Where’s the vision? Where do you take this aside from image recognition let’s say, or aside from saying I can search my photos by the animals?

Jeff Dean 08:39

Right, I agree detector is not really a fine integral, but really these kinds of models are very useful in a whole bunch of different domains. So we’ve already deployed a better acoustic model for speech recognition in and Android and iPhone now that basically just drops our word error rate by a significant amount – users really noticed that the speech recognition is a lot better. And a lot of that is attributable to this neuro acoustic model. The image recognition work is deployed so you can search your photos. You can now not tag photos, and you can say, Show me pictures of the beach or mountains or the Eiffel Tower and the system is actually able to understand those things from the raw pixel images.

Jeff Dean 09:27

Then there’s a lot of applications that we haven’t deployed yet that are trying to do language understanding with these kinds of models.

Derrick Harris 09:28

It seems so different when you’re building applications, to look back at search let’s say, or the Google core products from back in the day. And then you start building these very consumer interfacing products–not that search was consumer-interfacing. But consumers recognize when their speech app isn’t working, right? When their speech recognition isn’t there. Consumers– if you’re doing something with wallet, right. These transactions have to be–I would imagine in some of these systems. What’s the mindset when you’re building? Do you have a different application versus another and how you approach that?

Jeff Dean 10:03

I think the perceptual apps where you’re trying to recognize speech and things like that, those are a kind of a different class than ones like accounting or adding systems where you’re trying to be very–be sure you’re not losing any data. The perceptual apps actually have pretty nice properties in terms of you can actually make errors in your calculations and their still pretty robust to that. So you could lose a machine that has a part of your model on it and still able to do a pretty good job of recognizing things. That probably wouldn’t be the case in the ad system or in Google wallet or something.

Derrick Harris 10:39

Yeah, so there’s a case. So it sounds like–you can’t go back to–if I’m billing, if I’m using Google Apps or I’m using speech or something, right. It kind of has to be there because it’s not like a snapshot in time something you can roll back to, right, like the real time. I was going to ask, when you talk about the biologicals networks – we’ve talked about–AMD was on stage talking about alternative server architectures and these GPUs and system chips. How important–do you consider the hardware at all when you build stuff, or how important or is it strictly a software?

Jeff Dean 11:27

For these kinds of models you’re trying to build the best model you can and often that means you need to spread the computation across lots of machines. And these models are very computationally intensive in terms of floating point – operations, kinds of operations. So the more capability a given machine has in terms of floating point operation per second the fewer machines you need to use train a model or apply a model to and so on.

Derrick Harris 11:56

So it sounds like not a big fan of the cell chips and servers or I mean is that…?

Jeff Dean 12:04

For training these models you probably want something that’s a little more computationally capable, but for deploying them it turns out actually running inference on these models where you’re essentially just trying to pass something through it and not have it say what’s in it. That’s actually a lot less computationally intensive. So there’s a nice trade-off here where you can do lots of training of these models in the data center then deploy some of them and link to your cell phone or something.

Derrick Harris 12:30

How difficult is it to get–we hear about this discussion about this shortest of data scientists. We hear a discussion about shortage of distributed system engineers, and then if you get into the high performance computer space – super computers – their talk about this shortage of real deep parallels programing. How difficult to get the people who can come in and build these things? It seems if you it’s across so many fields that are all very complex and difficult.

Jeff Dean 12:59

I think each one of those specialties is hard to find people in and finding people with expertise in many of those different specialties is even harder. But really this a testament to the fact that these skills are in great demand, and our schools don’t produce enough science and engineering kinds of graduates that they could. So anything that we could do to encourage more people entering those fields that will help down the road a bit, but it’s defiantly an important issue.

Derrick Harris 13:34

How does that–when someone comes into Google as an engineer is it a case of they already have a deep knowledge of this or do you say, Hey here’s what you’re going to be working and make it a trial by fire sort of in the field?

Jeff Dean 13:47

We try to pair new people up with areas or projects that are good for their current background, but you also want people to learn these skills. Some people are happy to work in a particular domain or some field of computer science for years, and years. I personally like to kind of move around every few years, just to learn about new areas. I like working in small teams where people on the team have very different skills than what I have and that banter back and forth, and the ability to build something collectively that none of you could do individually is actually a really useful and valuable thing. Because then you pick up some of their expertise, they pick up some of your expertise and it’s a really nice plan.

Derrick Harris 14:33

Yeah. It seems kind of critical too in a day where it’s not just–even in a company like Google has so many different products they need to work together. And so many different devices or avenues for actually distributing your apps. You have mobile development skills or either web or whatever, and just kind of a service side, so….

Jeff Dean 14:55

One thing I think is true is that is you have someone who’s really good in one or a few areas they can pick up something new pretty quickly and that’s kind of a hallmark of someone you really want to hire because they can be very useful in a whole bunch of different areas.

Derrick Harris 15:09

Do you ever look at engineering now at a smaller scale? Do you ever look–one thing I always think is interesting is seeing these startups the Pinterest of the world who came of age in a day of cloud computing. And Amazon web services – do you ever think back on what it would be like–how I guess if you’re starting today you might–how you build something on a not Google scale that can maybe grow? A typical scale, right?

Jeff Dean 15:39

I think that starting something today actually has a lot of advantages compared to when we were – the early days of Google – where we actually had to deploy hardware to run out software. And that’s a really tricky thing if your service is successful and growing fast because you often can’t deploy hardware fast enough. So you really have to end up doing a lot of software optimization and efficiency and redesigning of your systems in order to keep up with demand. I think now if you are using a large cloud provider – the Amazon’s, or Googles of the world – you essentially design your system. And if you need a 1000 machines tomorrow instead of a 100 that’s a much easier proposition than if you have to take 900 machines and wire Ethernet cables yourself.

Derrick Harris 16:29

If there a point where clearly Google wouldn’t–do you see a cutoff point or there a time in a company a provider like Amazon could actually grow to handle – not Google – but something half that size? Would you see a cutoff in terms of just the…?

Jeff Dean 16:46

I think all of these cloud providers take advantage of the fact that not all of their customers are going to need ten times as many machines tomorrow as they do today. So their essentially statically multiplexing the demand, and being satisfy everyone potential for demand with a much fewer number of machines and if everyone all of a sudden went out and bought 10 times as many machines themselves.

Derrick Harris 17:09

I think this will probably be the last question. So I just wanted to ask. We talked about some of the stuff you’re working on, which is futuristic by most standards. What do you see next? Right now you’re doing machine learning, what’s on the horizon or maybe what are the next applications what you’re working on next?

Jeff Dean 17:25

I think this perceptual machine learning is actually going to significantly change how people interact with computing devices. Devices are getting smaller, you’re going to be able to assume that you have a network connection to a big data center from your cell phone, that’s really reliable and high speed and that really dramatically what you’re able to do. Speech recognition is now good enough that I think you can start relying on it and building complicated users interfaces around just speech rather than having speech be something you always have to fall back on something else. And that’ll I think will have pretty significant ramifications of what you can do.

Derrick Harris 18:06

How much of that do you put on the back end Session Name: Behind Google’s Evolutionary Leaps?

Joe Weinman Joe Weinman

Derrick Harris Derrick Harris

Jeff Dean Jeff Dean

Joe Weinman 00:00

The architecture and power performances consumption and everything, so we are privileged today to have one of the deepest thought leaders at Google – Jeff Dean and Derrick Harris is going to have a little discussion with him on stage. So this should be really fantasizing. Please join me in welcoming them.

[applause]

[music]

Derrick Harris 00:25

I should thank you right of the bat I think I owe you a debt of gratitude, because if it weren’t for the map produced paper I wouldn’t have a job wiring about Hadoop all day, so I thank you. But I kind of wanted to open it. I think too it’s kind of interesting as I watch the world at large kind of come around to map producer Hadoop, let’s say that the implementation of the map produces something that might have value – Google has kind of famously for some – more me at least well beyond. The things I want to talk about the transition from the map produce era to now, at Google and what drove these things?

Jeff Dean 01:10

I think one of the things that have caused us to build infrastructure as we were often doing things out of necessity, so we would be running into problems where we needed some infrastructure that would solve that problem in a way that could make it so that it can scale to deal with larger amounts of data or larger amounts of requests volumes and all of these kinds of things. There’s nothing like necessity of needing to do something to cause you to come up with abstractions that help you break through the forms. So map produced was born out of needing to scale our indexing system. We had a large number of phases and all they kind of looked similar in some respects, but we’re doing slightly different computations. But if you look at them we all wanted them to be – each phase to be robust, reliable to be able to be paralyzed off the machines, to be able to run on as many machines as we wanted to throw at the problem and have that happen automatically. And so that was what started us down that path of having these scale abstractions.

Jeff Dean 2:18

Then over time we built other higher-level abstractions that helped us deal with other kinds of problems. Some things like big table came about because we wanted to have – we had a lot of data sets where we had a particular key for data, and then we had lots of different kinds of attributes of data that we would collect over time. One example is our calling system has URLs and then a bunch of associated information about it. I think we have all of the different versions of pages that we’ve corralled over time. We have other processes that are going around in the background and computing what language we think this document was in, or how important we think this page is, computing page rank and so on.

Derrick Harris 03:06

Sounds like the applications drive the engineering, right? As in the case of the–is everything a reiteration on something previous or is a case we say, Here we want to do–how do we build a system that can handle this?

Jeff Dean 03:22

In a lot of cases we do say, Wow we have all of these problems and we really like a system that solves – addresses these four or five problems, because they’re key operational issues for us. Spanner I think is a good example. Spanner is a system where instead of having lots of separate instances of storage systems in different data centers around the world; we have one global main state for data and you can specify for a given piece of data how you want that replicated at a fairly high level.

Jeff Dean 03:51

So you can say things like, I would like five copies of this data, three in North America and two in Europe and then the system takes care of that for you. And so if we need to decommission a data center or upgrade a cluster in Europe the system has the flexibility to move from one European data center to another while satisfying the constraints the people have.

Derrick Harris 04:12

What kind of workloads are you setting up the Spanner for? That’s the epitome of what you might have thought of cloud computing when it started, like it’s in the cloud somewhere. So it’s really in one data center but this is literally – it’s in…?

Jeff Dean 04:24

Yeah. Ironically the first customer we decided to – internal customer – we decided to put them out as our ad system, which was maybe not the first. They’re a pretty demanding customer that don’t want to lose data. So we used it initially and worked very closely with our ads team to get that–I think one of the things about developing infrastructure is that it’s really important to work closely with a small team that is going to be your first customer. Because that rapid iteration you get feedback on which things are working well, does this interface work well – I like this feature – is much better than if you have very separated first use of this thing where you develop it in isolation.

Derrick Harris 05:13

Just so you get a sense of–based on how much these systems scale across applications so as is the first. But you do have a sense of where you might look at–what you might deploy on something like Spanner next? And you build these things with a sense of, we might one ideal use case in mind, but they really have to be easily applicable to many things?

Jeff Dean 05:31

There’s always this tension when building infrastructure. You could try to solve all problems for all people and then you usually end up with something that’s not very good for anyone, because you’ve made too many trade-offs that make it so it doesn’t have a good performance or it doesn’t have some attributes that you might want. It’s good to keep a few use cases in mind, and for Spanner the main use case was people who want to deploy internal Google products across lots of data centers. And we were spending a lot of time prior to Spanner managing different instances of their data and manually configuring – I’m going to run this data center now, and I have another instance in this data center – it’s just a lot of mental effort to keep track of. So Spanner kind of removes a lot of that from a lot of different teams.

Derrick Harris 06:21

I was reading a Google Research Blog Plus the other day about image recognition in photos and I thought it was fitting. It was well we found this new model from this competition with image recognition we just happen to have a system in place for analyzing on a large-scale neuro network data. It’s kind of geeky at the data level, but can you kind of just discuss it, so it’s a big machine learning problem and or not something Google’s been a lot effort into lately it seems. Can you talk about the importance of machine learning and the importance of the infrastructure the systems as a part of that puzzle?

Jeff Dean 06:58

I’ve been working on a machine learning system for the last couple of years that is using neuronal inspired – biologically inspired neuron networks. The idea with this is you have very raw forms of data, it could be pixels in an image, it could be the spectrogram of a small snippet of speech. And you build up layers – each layer kind of builds on the layer below in terms of building higher and higher-level representations of the underlying data. For example on images if you have one of these models the first layer of neurons learns to be receptive to edges of different orientation. So it might be very simple features like is there an edge at this orientation here, or one here? And then as you go up the hierarchy the system automatically learns more complex features. Things like corners or a little bit of an invariance to exactly what angle somethings at, and as you get to the top of these very deep networks you end up with very high level features. Things like does image contain a cat? Which was one of the things we were working on in an unsupervised manner we were training these networks and we found neurons that have actually developed that learned to recognize later an image contained a cat, without ever being told what a cat was.

Derrick Harris 08:22

So that seems like a lot of effort to figure out–to recognize a cat. Where’s the vision? Where do you take this aside from image recognition let’s say, or aside from saying I can search my photos by the animals?

Jeff Dean 08:39

Right, I agree detector is not really a fine integral, but really these kinds of models are very useful in a whole bunch of different domains. So we’ve already deployed a better acoustic model for speech recognition in and Android and iPhone now that basically just drops our word error rate by a significant amount – users really noticed that the speech recognition is a lot better. And a lot of that is attributable to this neuro acoustic model. The image recognition work is deployed so you can search your photos. You can now not tag photos, and you can say, Show me pictures of the beach or mountains or the Eiffel Tower and the system is actually able to understand those things from the raw pixel images.

Jeff Dean 09:27

Then there’s a lot of applications that we haven’t deployed yet that are trying to do language understanding with these kinds of models.

Derrick Harris 09:28

It seems so different when you’re building applications, to look back at search let’s say, or the Google core products from back in the day. And then you start building these very consumer interfacing products–not that search was consumer-interfacing. But consumers recognize when their speech app isn’t working, right? When their speech recognition isn’t there. Consumers– if you’re doing something with wallet, right. These transactions have to be–I would imagine in some of these systems. What’s the mindset when you’re building? Do you have a different application versus another and how you approach that?

Jeff Dean 10:03

I think the perceptual apps where you’re trying to recognize speech and things like that, those are a kind of a different class than ones like accounting or adding systems where you’re trying to be very–be sure you’re not losing any data. The perceptual apps actually have pretty nice properties in terms of you can actually make errors in your calculations and their still pretty robust to that. So you could lose a machine that has a part of your model on it and still able to do a pretty good job of recognizing things. That probably wouldn’t be the case in the ad system or in Google wallet or something.

Derrick Harris 10:39

Yeah, so there’s a case. So it sounds like–you can’t go back to–if I’m billing, if I’m using Google Apps or I’m using speech or something, right. It kind of has to be there because it’s not like a snapshot in time something you can roll back to, right, like the real time. I was going to ask, when you talk about the biologicals networks – we’ve talked about–AMD was on stage talking about alternative server architectures and these GPUs and system chips. How important–do you consider the hardware at all when you build stuff, or how important or is it strictly a software?

Jeff Dean 11:27

For these kinds of models you’re trying to build the best model you can and often that means you need to spread the computation across lots of machines. And these models are very computationally intensive in terms of floating point – operations, kinds of operations. So the more capability a given machine has in terms of floating point operation per second the fewer machines you need to use train a model or apply a model to and so on.

Derrick Harris 11:56

So it sounds like not a big fan of the cell chips and servers or I mean is that…?

Jeff Dean 12:04

For training these models you probably want something that’s a little more computationally capable, but for deploying them it turns out actually running inference on these models where you’re essentially just trying to pass something through it and not have it say what’s in it. That’s actually a lot less computationally intensive. So there’s a nice trade-off here where you can do lots of training of these models in the data center then deploy some of them and link to your cell phone or something.

Derrick Harris 12:30

How difficult is it to get–we hear about this discussion about this shortest of data scientists. We hear a discussion about shortage of distributed system engineers, and then if you get into the high performance computer space – super computers – their talk about this shortage of real deep parallels programing. How difficult to get the people who can come in and build these things? It seems if you it’s across so many fields that are all very complex and difficult.

Jeff Dean 12:59

I think each one of those specialties is hard to find people in and finding people with expertise in many of those different specialties is even harder. But really this a testament to the fact that these skills are in great demand, and our schools don’t produce enough science and engineering kinds of graduates that they could. So anything that we could do to encourage more people entering those fields that will help down the road a bit, but it’s defiantly an important issue.

Derrick Harris 13:34

How does that–when someone comes into Google as an engineer is it a case of they already have a deep knowledge of this or do you say, Hey here’s what you’re going to be working and make it a trial by fire sort of in the field?

Jeff Dean 13:47

We try to pair new people up with areas or projects that are good for their current background, but you also want people to learn these skills. Some people are happy to work in a particular domain or some field of computer science for years, and years. I personally like to kind of move around every few years, just to learn about new areas. I like working in small teams where people on the team have very different skills than what I have and that banter back and forth, and the ability to build something collectively that none of you could do individually is actually a really useful and valuable thing. Because then you pick up some of their expertise, they pick up some of your expertise and it’s a really nice plan.

Derrick Harris 14:33

Yeah. It seems kind of critical too in a day where it’s not just–even in a company like Google has so many different products they need to work together. And so many different devices or avenues for actually distributing your apps. You have mobile development skills or either web or whatever, and just kind of a service side, so….

Jeff Dean 14:55

One thing I think is true is that is you have someone who’s really good in one or a few areas they can pick up something new pretty quickly and that’s kind of a hallmark someone you want to hire because they can be useful in a whole bunch of different areas.

Derrick Harris 15:08

Do you ever look at engineering now at a smaller scale? Do you ever look at–one thing I always think is interesting is seeing these startups the Pinterest of the world who came of age of in cloud computing and Amazon web services. Do you ever think on what it would be like–how if you’re starting today you might–how you build something on not Google scale that can maybe grow to Google scale?

Jeff Dean 15:38

I think that starting something today actually has a lot of advantages compared to when we were the early days of Google where we actually had to deploy hardware run our software. And that’s a really tricky if your service is successful and growing fast. Because you often can’t deploy hardware fast enough and so you really have to end up doing a lot of software optimization and efficiency and redesigning of your systems in order to keep up with demand. I think now if you are using a large cloud provider – The Amazon’s or Google’s of the world – you can essentially design your system. And if you need a 1000 machine instead of a 100 that’s a much easier proposition than if you have to take 900 machines and wire Ethernet cables yourself.

Derrick Harris 16:29

Is there a point where – clearly Google wouldn’t – do you see a cutoff point? Is there a time in a company – a provider like Amazon could actually grow to handle – not Google – but something half that size? Would you see a cutoff in terms of just a…?

Jeff Dean 16:46

I think all of these could providers take advantage of the fact that not all of their customers are going to need 10 times as many machines tomorrow as they do today. So they’re essentially multiplexing the demand and being able to satisfy everyone’s potential for demand with a much fewer number of machines and if everyone all of a sudden went out and bought 10 times as many machines themselves.

Derrick Harris 17:07

I think this will probably be the last question. Just wanted to ask – we kind of talked about some of the stuff you’re working on which is futuristic by most standards. What do you see next? Right now you’re doing machine learning – what’s on the horizon or maybe what are the next applications, and what are you working on next?

Jeff Dean 17:25

I think this kind of perceptual machine learning is actually going to significantly change with how people interact with computing devices. Devices are getting smaller, you’re going to be able assume that you have a network connection to a big data center from your cell phone that’s really reliable and high speed. And that really dramatically changes what you’re able to do. Speech recognition is now good enough that I think you can start relying on it and building complicated user interfaces around just speech rather than having speech being something that you always have to fall back on something else. And that I think will have pretty signification ramifications of what you can do.

Derrick Harris 18:05

How much of that do you put on the back end versus do you put on the device? It seems like you’ve got your computer in your–and on the…?

Jeff Dean 18:18

Yeah. It’s a tradeoff. You have a kind of a weak but a very low latency computer sitting in your hand. And you want to do some amount of computation there for interactivity and then you want the ability to all of a sudden when I say something burst and use a thousand computers, or 10, 000 cores to recognize what I said.

Derrick Harris 18:42

That’s the last follow up on that, they’re going to cut us off.

Jeff Dean 18:45

Thank you so much.

[applause]

You’re subscribed! If you like, you can update your settings

firstpage of 2
  1. Jeff was great, but who was that idiot asking him questions!
    What a waste of an opportunity!

Comments have been disabled for this post