>> Stewart Tansley: Okay. Good morning, everybody. Are we on? Yes. I think
so. So I'm Stewart Tansley. I'm just the host for this session. I'll hand it over
quickly to Seth Goldstein.
Professor Seth Goldstein has been one of the most stimulates professors I've
worked over the past years. It's been a real privilege the amount of interest and
things that he gets up to.
He describes his research domain as systems nanotechnology. We're going to
get two tastes of this, both today with this talk, the brain in a bottle talk, and then
tomorrow he'll talk about some of his other work in the same sort of area, but a
different context.
So please come back if you enjoy this talk, tomorrow at the same time in the
same room. So without further ado, let me hand over to Seth.
>> Seth Copen Goldstein: Thank you, Stewart. Thank you for having me. So
this is a particularly good place to give this talk, because Microsoft paid for some
of this reasearch. Thank you.
So this is sort of a brief introduction motivation because I actually haven't talked
about this here before and also a little bit of a status report about where we are.
And the person who is doing most of the work is Billy Bay Trapison (phonetic)
who is a graduate student that's being co-advised by myself and Carlos Gustrom
(phonetic).
So this is a plot I'm sure everyone here has seen from Hans Mordic (phonetic)
who basically tries to associate some kind of computational power to various
biological organisms and Hans and others have basically sort of calculated that
the human brain has the equivalent computational power of 10 to the 8 MIPS or
10 to the 14 operations per second.
I'm going to explain why I think that's a really terrible metric, but it motivated me
to think about, you know, maybe one of the reasons why AI is really hard is we
just don't have enough computational power, so is it possible to build a system
today that would be a tool for AI researchers among others, but that was the
original motivation, that would enable or facilitate AI research and understanding
the brain.
So what I would like to propose is to build something to that scale, that physical
scale that little box maybe a meter or two, one or two cubic meters that has about
an order of magnitude more computational power than at least what people
estimate the human brain has. Okay?
So let me give you some brain facts in case you don't know. And by the way, it's
a small group. I'm happy to be interrupted at any time.
So the brain's not that heavy, it doesn't take up that much space, it doesn't use
that much energy, and it crams a lot of stuff in there, about 10 to the 11 neurons.
To me the most interesting sort of brain fact is the number of connections per
neuron, the number of synapses. So basically every neuron is connected to
about 10 to the 4, 10 to the 5 synapsis.
On average some areas of the brain are much richer than that, and some are
significantly poorer, but this is a good average, and so we'd like to target
something that has on the order of ten to the 14 connections. And these things
are really slow, 10 hertz about, and yet it's sort of pretty amazing.
So you can use various methods to calculate what the computational power is,
you can look at the capacity. And so the neurons, the speed of the synapse, the
amount of energy being used, you could look at the visual system which we
understand really well, compare it to the number of opps it takes to do vision on a
processor and extrapolate. Anyway about 10 to the 8 MIPS is what you get.
Some people argue this is way underneath it if you sort of think about each
protein as a processor, but I think that's probably a bit extreme. Okay. But I
think it's a bad metric, okay. And so the question I have is what is the best sort of
system architecture to think about, so I want a metric to evaluate an architecture
that would facilitate AI research and research that would help us understand how
the brain works, okay?
And I think that just getting more MIPS and FLOPS is not the answer. Buying 50
or 100 or 1,000 Blue Jean Ls or Ps or whatever they're up to now is probably not
going to answer the problem. So my thesis is that while MIPS and FLOPS are
good connectivity is better.
In order to evaluate that thesis, we need to really build this machine, and I'll talk a
little bit more about that later.
So today in June, I guess, the Blue Jean down in Los Alamos got to about a
petaflop, which about 10 the 6 megaflops, and basically everybody focuses on
these. This thing is a road runner, so we would need about 10 to the 4 of these
to get the same number of opps per second. You couldn't use all those floating
point opps but that's the way they get their opps.
But I think what's really important is the connectivity. So these Blue Jeans, this
Blue Jean, the roadrunner is made up of 17 what they call computational units or
computer units or something like that, and each one has a 288 port finiBand. So
in other words, it's very connectivity poor, at least between these big cabinets.
And even inside the architecture if you look at it, it's very connectivity poor, so the
message volume is small. You know, we think about balancing machines in
terms of how much memory for each gigahertz or megahertz or whatever it is,
and there ought to be something like that to say given certain processing how
much connectivity would we like to have.
Okay. So the important neurons, it's about 10 to the 5 connections for each
neuron, so it's about 10 to the 14. And the other thing is we probably can't afford
to just get 1,000 of these Blue Jeans to get us there, because this one takes
about 4 megawatts, so 4 gigawatts would be sort of problematic, and this is the
most power efficient supercomputer that exists by a factor of like three or four.
Okay. And the next four down the list are all by IBM, too, in terms of power
efficiency.
Okay. So what I want to do is build what I call a brain in a bottle just because it
sounds good, it's actually in a box, but something that's fairly small and focus on
the connectivity. Okay, and scaling.
So one of the sort of paths on how I got here is I'm very interested in sort of
stochastic processes, particularly in manufacturing. And so I'm looking at
something that's a much, much less expensive than Blue Jean, which is highly
engineered.
So what I want to do is sort of build these very simple processors, let's say
they're packaged in a sphere, I'll explain how that packaging works in a little bit,
and then you sort of drop them in the box or the bottle, and then that's your
system. Okay. And so somehow that makes it, you know, sort of robust
because the construction method requires robustness, it didn't work at all if it's
not robust, and makes it fairly inexpensive and easier to scale. You just drop
more nodes in.
And so I'm going to use this sort of soccer balls and icon for my processor, think
of it being about a millimeter in diameter or less. Right now, I think we would
probably make these easily today at about 600 microns in diameter and then
there's going to be some wires and I'll explain how those wires work later. Okay.
So if I really want to put a billion of them in there, then just for packing to make it
easier, I probably need two cubic meters, if I actually did it right I could get it into
a cubic meter. It's about a cubic meter. Okay.
So I'm going to explain how to build these spheres first and then I'm going to go
through some numbers to convince you that this is reasonable and I'll talk about
the networking and then some algorithms. Yes?
>>: (Inaudible) back to (inaudible) when you set up this sort of straw man of
connectivity where the finiBand is only 280 parts. But I mean it's much faster
obviously than the snap connections. And I mean virtually each thing can talk to
each other thing, you know, at 10 hertz or whatever, probably.
So is there a reason you didn't want to pursue this type of architecture even
though it -- I mean effectively you still can get that kind of connectivity, just really
slowly, I guess.
>> Seth Copen Goldstein: So I guess at 10 hertz, the thing is we have to do a lot
of other simulations, too. I haven't done the analysis that says if I want to give
like if I want to divide this up into, I mean obviously this isn't the right way to use
this architecture but if I want to divide this up in 10 to the 11 processes that we're
all talking to each other, what kind of message volume could I sustain? I
probably should, I think it's pretty poor. But I don't know. That's a good
(inaudible).
>>: I agree that what you're doing (inaudible) but.
>> Seth Copen Goldstein: Well, partly. Yeah, so I'll do that calculation and I'll
get back to you. That's a good calculation for me to do. There's nothing you can
get around this.
And I also, you know, this is a scalable technology, so I'd like to put a small brain
on my desk and so we could do that. So it's the other thing. Okay.
So let me explain how we're going to make these things and actually shameless
plug for tomorrow, this same basic technology is going to work for Playtronics as
well.
So I want to make this as inexpensive and as small and lightweight as possible,
so for thermal properties I want to really sort of do away with the packages if I
can.
So what I'd like to do is sort of print my chip on some basic silicon and then make
that the package. So somehow I've got to turn this flat thing into a sphere just
because it's easier to think about spheres. We could think about dyes, but I don't
know how we're going to get the network that way.
So the thing is is that a thin film of silicon is actually flexible, it's not rigid. And so
if I just take the silicon on top of this silicon and insulator, on top of the insulator
and the typical SOI wafer, it's very, very thin. And actually you can engineer the
stresses, and this is not my idea, this is Rob Reed's idea from the air force
research lab.
Instead of printing your dye on some type of rectangular form, print in it this
flower shape, you can engineer the stresses here so that when you get rid of that
insulator and you get left with this very thin silicon, it should -- oh, yes, so we're
going to put our dye on here. It should curl up into a sphere, and actually we're
in the process of making some of these. This is actually a really old picture, but
we can actually make Rob can make and my graduate student, I can't make it,
but we can make these little spheres.
And there's in a one millimeter diameter, assuming we can close this space off,
we have enough area here to put some -- a lot of stuff here, right? It's about
three -- it's about two square millimeters of area, surface area that we can use.
Okay. So this is our little sphere and so in a 90 nanometer process, so this is
sort of ancient already, the kind of stuff you can imagine putting in that area is
something like an arm 7, quarter of a megabyte of memory, so this is a little
under power in terms of the amount of memory we have. And then all the
support circuits you would need to distribute power, which I'll explain how that's
done in a minute, and we fill the middle, we curl it around let's say a super
capacitor which has the energy for about a billion instructions, and then they
transfer energy between each other.
Okay. And these are today's numbers. These energy numbers make these
things run a little hot and I'll explain how we're going to get it cooler, but, you
know, if we go down to let's say 45 nanometer process and we have a lot of room
for extra memory, for instance. I don't think we need any more processors.
So let me talk about the power a little bit. I think partly one of the things I like
about this project is it motivates a bunch of other research as well. So to really
scale this up, we probably need to reduce the power, and we have to consider
two things, the dynamic power and the static power and once we get them to the
45 nanometer node or below, the sort of leakage, current, the static power
becomes the serious consideration.
So there's a couple of ways we can do that. One is we can use less hefty
processors than an arm 7 and put a bunch of them on each one of these dyes,
so essentially just use parallelism to slow the clock right down. That allows us to
lower the voltage.
And the other is to use better circuits. Before I started doing this kind of stuff, I
spent a lot of time thinking about asynchronous circuits, and they are much -they're less power hungry. Yes?
>>: (Inaudible) does that mean something ->> Seth Copen Goldstein: Well, in the way the arm 7 works when they quote it
on their data sheet they say you can, you know, depending how fast you want to
run it, it's going to be a certain number of microwatts per megahertz, okay, and
these are all basically single instruction issue, one instruction per hertz.
But I will start talking about joules. But picojoules per instruction.
So there's lots of circuit techniques around, and it's not just for building large
scale systems that people care about power, everyone cares about power, as I'm
sure you all know. And so there's lots of standard seamless low power stuff,
there's lots of asynchronous circuits. I think exploring reversible computing is
interesting, but we don't really need it.
So for instance, if we just stay on this industry trend, so for instance Todd Austin
in Michigan has this processor that he fabbed at 130 nanometers and .6
picojoules per instruction, so it's about three orders of magnitude of what people
standard get today. If you include the memory in this, that's three picojoules per
instruction. And there's no reason why we can't get to about a 10th of a picojoule
per instruction. This is all well within the realm. And this is about 130
nanometers so we can shrink this significantly.
And so if we do get to .1 picojoule per instruction, then 10 to the 9 MIPS, that will
be one order of magnitude more than what Hans says the human brain would be
about 100 watts.
>>: (Inaudible).
>> Seth Copen Goldstein: This is static and dynamic. Of course at 130
nanometers, the static is a smaller component. But if you look at the curves, you
can see that as you boost up the frequency, so the static is not as much of a
proportion as it would be today. And so we, that's certainly something we'd have
to consider. So when we go down to 45 nanometers it's not going to get four
times better. We're not going to win that way. Maybe it will get twice as good.
>>: (Inaudible).
>> Seth Copen Goldstein: You mean my brain? 25 watts. Approximately. But
well I'll talk about cooling in a second. Let me just talk about delivery, how we're
going to deliver a power to this because we've got all of these things thrown into
this box, there's no power plugs for each unit.
And we actually need this sort of head room, so 100 watts from computing and
communicating is going to require more power dissipation, because you've got to
distribute the power and the method we're using is not that efficient.
But imagine that we have these spheres and they're in contact with each other,
so we could potentially set up some kind of communication path that way. We're
not going to actually do that. But if we put on the surface of the sphere, we code
it with the dialectric and right under the surface we have metal plates, then when
two of these spheres come together what we have is let's say this is blue one is
one sphere and the pink one is another sphere, the plates form these capacitors
across that interface. So if I put an AC current on the blue guy, it's going to
transfer a load over to the pink guy.
Okay. So these guys are actually far apart, but when they come together, they
form this capacitor. And we have actually demonstrated this, so we can get this
to work.
So you can imagine I have power in one guy, I've got to get power to the next
guy and so I essentially sent him a packet of power and then he can continue to
route that and so the power distribution problem becomes his networking
problem to make sure everybody is getting the right number of packets they
need. And it's sufficient enough that we won't spend all of our time just routing
power.
So the surface provides the initial thing and then it sort of filters out to the right.
So this is just one scheme. There's other schemes you can consider using.
Okay. So so far we have like an XM MIP machine which is sort of cool, but the
units only communicate locally with each other, and that's not very interesting. It
takes a long time to go from one end of this machine to the other. Okay. And as
I said, I think connectivity is the key thing for -- that's my thesis, anyway, for
enabling this kind of research.
So we're going to attach wires here that are about 10 diameters long where the
sort of the basic unit here is the diameter of the processor. All right. And these
wires will be coded with a fairly resistive material. So when two wires cross and
connect, they're going to create a highly resistive contact, but not so resistive, it's
not a perfect insulator that they can't -- actually a signal on one will get
transmitted to a signal on another one.
So imagine here then that we have let's say these nodes, four nodes, A through
D, and their wires are connecting at these big black blotches. We can engineer
that resistive coding and the signal strength that we put on the wires so that we
can choose whether or not when a node puts a signal on this wire it is
successfully transmitted through one or two contact points.
So the idea is to do it so that there's two contact points, that a signal put by A will
be seen by B because there's one contact point, it will be seen by C because that
goes from A is wired to B is wired to C is wired, but it will not be seen by D. Let
me just illustrate this with a little graphic, right.
So imagine I use an AC signal on A, it goes through this resistive coupling to B,
the blue wire and the amplitude of this signal gets shortened and then it gets
shortened some more but it's still more signal than noise and by the time it gets
to the rest of the machine it's basically just noise.
Okay. So if we had sort of uniform one centimeters lengths and a uniform
distribution, then every node, just do the basic math, gets about 10 to the 6
neighbors.
>>: Are you (inaudible) straight lines to (inaudible).
>> Seth Copen Goldstein: Yes. So it turns out I'm going to show you some
really data in a second from our simulators. But 10 to the 5 is well within sort of
stochastic process.
Now, I don't really understand how to do this, so it could be that it's not -- you
know, it might be 10 to the 4, I don't really know. If the wires are sort of -imagine that we start out the box is water and we create hydrophobic wires, put
them hide phonically, they're basically going to want to stick out.
So as we drop these things in, the wires will mesh together, the ones on the
bottom will be all sort of bad, but as you get in the middle there's a lot of
connectivity. Yes?
>>: (Inaudible).
>> Seth Copen Goldstein: Yes.
>>: (Inaudible). They may not, they may have the repulsion?
>> Seth Copen Goldstein: No, if they're both hydrophobic, they're going to want
to -- oh, they're both hydrophilic, yes, that's true, that's an issue. I hadn't thought
about that.
So there's going to be a lot of -- there might be some repulsion, but we're going
to neat to sort of glue them down because I'm going to use the extra space in this
box to pump coolant through it to keep them cool enough and if I don't glue them
down, they'll go all over the place. You so the gluing, you can arrange it so that
there are the chemicals on here and with small electrical contacts we can
essentially weld them together.
And so the fact that they might not come, they might not naturally want to stick
together is probably okay. Yes?
>>: (Inaudible) actual biological brain is the ability to prune and regrow those
connections and change the circuitry that way. Are you going to emulate this in
software, per se, or how are you going (inaudible).
>> Seth Copen Goldstein: First step, do it in software. In the long run, and this
is now, you know, there's so many grand canyons I want you to jump over
believability here, so this would be like grand canyon number two, but there are
like molecules that if they change their confirmation, they change their
conductivity and they can change their confirmation with high voltage differences
like protaxians, for instance. I don't know how familiar with this ->>: (Inaudible).
>> Seth Copen Goldstein: Yeah.
>>: The other one so is you've got, you know, 10 diameters. One of the other
things you get in the biological break beneficial is this very long axle connections.
>> Seth Copen Goldstein: So axle -- I mean this is to give you, I mean this is a
calculation you can do like with a pencil and paper. If I start making it a little
harder it is a little harder to actually figure it out. There's a mean distribution of
10 diameters, there will be some wires that are shorter and some that are
significantly longer, and actually what we thought about is we can have 10
diameters worth of copper, think about it, as copper exposed and then some
insulator in between, so you can sort of leapfrog around.
So these are all -- to me, these are all like second order bits. If we could get the
basic thing to work doing that stuff is quite easy.
>>: (Inaudible) resistors than you are through the processing constructions.
>> Seth Copen Goldstein: You mean, am I going to be generating more heat
and power going through the wires than I am going to be processing
instructions? Probably.
>>: (Inaudible) resisters.
>> Seth Copen Goldstein: Oh, resisters, I see. Well, the whole process of doing
the communication is going to be very power hungry. Let's say in order of
magnitude more than the process.
>>: (Inaudible) based on connectivity that you choose the connectivity means
(inaudible).
>> Seth Copen Goldstein: I want as rich connectivity I want and I don't know
how else to get it.
One way to think about these things is it's sort of like anisotropic wireless.
Essentially these are like wave guides, right, that make -- and I don't want it to be
isotropic, I don't want to just talk to my neighbors, I want to be able to reach
across large distances, and so this allows me to do that.
If someone can come up with a better scheme, I'm not wedded to this scheme,
this is just a straw man proposal that I think -- you know, if I do this by
simulations, it looks like it works, the chemistry people say it's not completely
farfetched and so -- but I'd rather have a better scheme. This is going to be a
little power hungry.
Okay. So we have with the help of you guys, we built the simulator to
understand what the structure of this thing would be and then to run our
algorithms on it, so at the very beginning we have to actually we'd like to see
what the structure of the wiring graph is and how the nodes get laid out, so what
we do is we sort of simulate randomly dropping these nodes into a box, and then
to see what the wiring graph is, we sort of voxelize this thing up into voxels that
are significantly smaller than the diameter of a node and then run the wires
through it in a random process.
So the wire, you know, enters this voxel and then comes out in a straight line in
the voxel, but we can sort of -- so it bends around and we can sort of simulate at
a rough get of what the structure of this thing would look like.
In general, for all the simulations I'm going to show you here, all the wires are
exactly 10 D long and they're completely conducted. I mean there's no insulator
among any of that surface. Yeah?
>>: (Inaudible) these spheres, you also know how to make these wires in.
>> Seth Copen Goldstein: I know how to make the wires. Knowing how to put
the wires on the spheres is still something of an issue.
>>: So it's not just a question of (inaudible) some kind of wire thing on this
sphere head, it's something more (inaudible).
>> Seth Copen Goldstein: No. There's some things that we've been throwing
around, but I don't have any good -- I mean, you know, they're sort of small and
how to actually attach the wires is of question.
What I'd like to do is I'd like to grow them out of each fear, that would be the best
thing to do. But I don't know how to do that yet. I mean, there are ways that you
can think about doing it.
>>: (Inaudible) very much like the growth you see on rechargeable battery.
Have you ever looked at that?
>> Seth Copen Goldstein: No.
>>: So one of the things you run into was a NiCad battery in particular is as
you're charging it, the act of charging it causes metal to migrate from the plate
into the electrolyte.
>> Seth Copen Goldstein: That general process I do understand.
>>: Yeah. And eventually, you know, you get a shorted cell.
>> Seth Copen Goldstein: Well, you could think about electroplating these
things, starting out with a C, you could think about doing some kind of a catalytic
growth like the way now to their silicone wires and the nanoscale. So there's lots
of different (inaudible).
>>: (Inaudible).
>> Seth Copen Goldstein: Yeah.
>>: (Inaudible).
>> Seth Copen Goldstein: The first nano -- yeah. So anyway. So there are
processes I could think about, but I haven't -- I'm not betting on any one in
particular.
Okay. So these also all these numbers I'm going to show you are for something
with a million processors. So we can't really simulate more than a million today
just because that's on a like a 48 gigabyte machine. You guys want to give me
some more memory that would be good.
But because we also run programs on each one of the nodes, we need a fairly
big system here.
So for a million nodes with the wires about 10D, then, you know, most of the
nodes have about 2200, 2400 neighbors, so it's a big set of neighbors, even
curling around and doing that.
And they have -- this is the number of unique neighbors they have, so the wires
make lots and lots more contacts. So there's a lot of redundancy in all of those
connections that you have. And there's a fairly big distribution.
And the problem with trying to really evaluate this scheme with just a million
nodes is there's too many of them on the surface. What I'd like to do is actually
do this thing for a million and then cut away the ones that are out there, the
surface to volume ratio will be much smaller when we get to a billion nodes.
But even so, it's the neighborhood size is pretty large, so that's good. If we look
at the number -- so a contact point is sort of the physical connection, a hop is a
logical connection, and to get from one end of this box to another, it takes
about -- well, once, you know, takes about 12 hops.
So this is just a, you know, picking pairs at random and seeing how many hops it
takes to get from one to the other, and it's a cumulative distribution. So once we
get to about 8 or 9 hops, almost everybody can communicate.
Okay. That sort of makes sense, the wires are -- I mean you can sort of do
what's up. You have lots of neighbors. You can always go in the direction you
want to, the nodes are -- the wires are at when they're completely stretched out
are about 10 diameters and the box here is like, I don't remember how big the
box is. We could calculate it, though. 70 or 80 diameters or something like that.
Yes?
>>: (Inaudible) knowledge of how the connectivity graph so you can final the
optimum path between 2 (inaudible).
>> Seth Copen Goldstein: Yeah, this is just, if I was doing the offline routing
algorithm, how would I do it. Yeah, this is -- I'm just characterizing it. And I'll do
some more of that. But I'll show you the real (inaudible) in a minute.
Okay. So one of the big problems with this network, the big problem with this
network, is the randomness is all good. I mean, you know, if I've got two nodes
that are both sharing cross a single wire, they interfere with each other. It's like
all the problems you have with the wireless. Hidden receivers, hidden
transmitters, all that kind of stuff.
So either the communication is going to have to be fairly sparse or fairly smart.
Sparse you're okay because it's not going to be a lot of people competing for it,
or if you're smart. And one of the things that we haven't gotten to but is on our
list is looking at things like Rodica's (phonetic) work on desynchronization. So
you've got a bunch of nodes that are all sharing some communication bandwidth
and what you'd like to do is make sure everybody who wants to communicate, K
of those, they get one Kth of the bandwidth. Right.
So, you know, you've got let's say 100,000 people sharing a wire, it's not quite
that bad, but only like 50 or 1,000 of them want to communicate, so you'd like to
get one-fiftieth one-thousandth of a bandwidth, not one-millionth of the
bandwidth. You don't want to just do time division, multiplex in a stupid way.
And this desynch algorithm is very cool, and they sort of self organize and the
speed in which people can join and leave and get the piece of the bandwidth they
want is very fast.
And the other thing that's nice about this algorithm, I see you guys should invite
her out here to give the talk, is that it uses constant memory. So memory is a big
concern of ours, right, the nodes have very little memory. So I'm going to tell you
how we're going to address that in a little bit.
So let me just show you. We built this tool that sort of visualized the simulated
brain we call it an FMRI tool of course because why, you know, we want to. Let's
see. So I think this is the right video. I'm supposed to go down here. Where am
I supposed to go again? This thing here? Okay.
So what you're looking at is sort of the nodes and the wires. The nodes fade
away a little bit. It's 3D, so you're not seeing all the way deep here. And this is
running basically sort of a test thing to get our basic, you know, A and B are
neighbors, they're one hop away, and I want to get them to communicate.
Every node is trying to send a message to every single neighbor that it has. And
they're all doing it at the same time. So this is sort of worst case kind of scenario.
When you see this rash of red breakout it's because two people are stomping on
each other. When you see blue, it means the wires are being used to
successfully transmit data. And if it's black, then there's nothing happening on
that wire for a second.
And so in the binge, at the very beginning, everyone just doesn't know what to
do, they stomp on each other, sort of the whole thing turns red, then the basic
backoff algorithm starts to recover and then you see patches of red and lots of
blue and that's basically the way this thing then runs until you get to the end.
So it takes I don't remember how long this takes to get everybody to have sent a
message to everybody else. But it takes a reasonable amount of time but not
ungodly amount.
And of course as you make progress and fewer people -- you know, more people
have actually satisfied the thing and they're quiet, then it really speeds up
towards the end. Yes?
>>: (Inaudible).
>> Seth Copen Goldstein: Yes. These are the node. They're much bigger than
they look like.
>>: So (inaudible)?
>> Seth Copen Goldstein: We drop the nodes in randomly using gravity to pack
them, and then the --
>>: (Inaudible).
>> Seth Copen Goldstein: Right.
>>: (Inaudible).
>> Seth Copen Goldstein: No.
>>: All right. (Inaudible).
>> Seth Copen Goldstein: I don't believe that we want -- we need to or want to. I
mean, if we could actually -- I mean, there are -- so if we didn't have the wires to
contend with, then we could drop them in and sort of shake them and get them to
form an absolute lattice, and that would be useful.
But the wires are going to -- never happens, right, because the wires are sitting
there, the nodes are going to roll around, they're not going to -- and I actually -the more space we have in there, the easier it is to cool. So I'm not upset about
it.
And then two cubic meter box is not that big. We'll be able to get many more
than a billion nodes at one millimeter diameters. Okay. Any other questions?
This video -- this tool is totally great for trying to diagnose problems, not that the
algorithm isn't working but it's too slow, and so you get to sort of visualize it and
see, it stays red for a really long time or something like that. You can sort of
hone in on the spot that you want to focus on, try and figure out what the graph
structure looks like. It's just a lot of data.
So it's not as much data as the people who are looking at a real brain half, but it's
a lot of data. It's also fun to play with.
Okay. So you don't need that. Okay. Whoops, I'm now on the wrong mode
here. Okay. So that's the basic communication. I'm assuming for my power and
heat dissipation calculations that like 50 percent of the volume is in the spheres,
20 percent is in the wires, and the rest is left over for coolant then I'm going to
pump through. So if I use FC 77 and like a commercial pump, I can totally keep
this thing cool, getting about 10 to the 9 MIPS. So one order of magnitude more
than the brain.
And this is the completely commercial kind of pump that I can buy. So you could
get it at least in order of magnitude better than that. If you're going to ask me -yeah?
>>: (Inaudible) wire connectivity be strained? How do you keep wires
connected?
>> Seth Copen Goldstein: Like I said, we're going to do these welds. Right.
We're not going to just let them free float around because that wouldn't work.
There's a lot of pressure. Yes?
>>: (Inaudible).
>> Seth Copen Goldstein: I don't know. That's a discussion we were having
before. I'd like to grow them, but I don't know exactly how to do that.
>>: (Inaudible).
>> Seth Copen Goldstein: No, no, no. You could do that actually but the
connections would be very poor because then you have to captively couple or
resistively couple directly from the node to the wire and that might require us to
lose a hop or have to use much more power. So I'd like it to be free essentially,
energetically, to go from the node to its first wire. Yes?
>>: Using a conductive fluid?
>> Seth Copen Goldstein: The problem I have with that is that it's too isotropic,
so everyone just gets to talk to their neighbors, you know, just decays with the
resistivity of the fluid. And that might be interesting, but I don't think it will give us
the interesting structure we want. Yes?
>>: (Inaudible) assembly solve the problem with the wires getting (inaudible).
>> Seth Copen Goldstein: Slurry assembly? I don't know what that is.
>>: Where you take a hydrophobic, hydrophilic in a fluid.
>> Seth Copen Goldstein: Oh, yeah.
>>: And they eventually through geometry and the attraction process give a
pretty good (inaudible).
>> Seth Copen Goldstein: This is between wire and node.
>>: Maybe sure that the connection to the wire ->> Seth Copen Goldstein: Yeah, I see.
>>: Mates to it.
>> Seth Copen Goldstein: So that's one possible way. Yes?
>>: (Inaudible).
>> Seth Copen Goldstein: No, it's not ice tropic. Certainly not random, but it
looks sort of random, right.
>>: Some brands are more random.
>> Seth Copen Goldstein: Right. Different parts are more random than others.
Yes?
>>: So the brand there is some global signalling through this chemical whatever,
and your drawing, whatever it was, then of the connectivity would have
(inaudible) made me think would it be possible to have some sort of global
signalling like a slow down a little bit now because everyone's talking, okay, now
you can speed up, or something -- you might be able to sort of optimize it a bit
like globally?
>> Seth Copen Goldstein: It's possible.
>>: Adjusting (inaudible) I mean what kind of (inaudible) you would need. Like
you'd have to maybe start manipulating the liquid that they're in with little bits of
chemical or something. I mean I don't know what. That's the (inaudible) does it
right?
>> Seth Copen Goldstein: I'm not sure. We can have like thermal sensors on
there, everyone can slow down when it got too hot. That's probably a good idea.
Yeah. I mean, there's lots of things. Again, these are second order. Let's see if
we can do the first order things first.
>>: (Inaudible) local and the global.
>> Seth Copen Goldstein: Yeah, I think that is interesting. One of the things
that's actually very interesting about the brain is the amount of surface area there
is, where it's all folded up. And we could do something similar to that. There's
no reason why we only have to have the outside be the -- you could imagine you
have fins that are providing something and then the mean distance between
people and the global communique is that you can globally communicate to
everybody on the surface at once could be reduced. That might also provide
other benefits for power distribution.
I don't know how it influences the wires. But so there are other schemes that you
could think of.
Okay. So at this point, what do we have? We have something that's brain like, I
guess. That's probably too strong, actually. Brain inspired. So we have this one
millimeter diameter units, they're running somewhere between one and 100
megahertz, if I'm using sort of stuff without lots of improvement and getting down
to the sort of one picojoule range or one megahertz or less.
We have a way to communicate and do power distribution and these wires give
us this sort of rich graph, okay? We have about 256 gigabytes of memory so you
can see it's a terribly memory poor system. This is one of the problems. Yes?
>>: (Inaudible) running over the wires.
>> Seth Copen Goldstein: I don't know.
>>: You don't have any idea yet?
>> Seth Copen Goldstein: No. Close to DC.
>>: Okay. So very low frequency?
>> Seth Copen Goldstein: Well, no, I take that back. That's completely wrong.
For doing power distribution we're getting, we're very close to DC. On the order
of kilohertz.
Those things I forget what we looked at the analysis. But on the megabit range,
something like -- again, that's a parameter -- I mean so in the spy simulation sort
of looking at, you know, whether this is physically possible, we need to actually
build some of this hardware to determine what the interplay is between the
amount of energy that's required but frequency we can support and all that.
Okay. So we have a -- the key thing for me is that there's lots of connections on
the plus side. On the minus side is it's that it's very memory poor.
So this is with using, thinking about S RAM 6T cell S RAM and if you really ( want
low power you might actually use more transistors. That's a problem. If we look
at D RAM, then we get, you know, another factor of 40. So that's probably a
good thing. Yes?
>>: (Inaudible) 6 wires (inaudible).
>> Seth Copen Goldstein: Yes.
>>: And each wire had how many o.
>> Seth Copen Goldstein: 10 diameters. On the order of like 10 to the -- well,
no, you -- so you can't do it that way because there's lots of overlap in these
connections. Right? So if you sort of -- if you don't count overlap it's on the
order of 10 to the 6, let's say, but if you do count overlap, because they can go
through two contacts, right, so you get that square effect, if you do count overlap,
it's about 10 to the 5.
>>: (Inaudible) concentrate the (inaudible).
>> Seth Copen Goldstein: Oh, yeah, absolutely. Without the double hop thing,
then you're limited to just your local neighbors and not very -- it's not interesting.
I mean, it's lots of neighbors, I guess, but it's not rich enough.
Okay. So I (inaudible) the hop which is the logical A to B and a contact which is
hop where I'm saying you go through two contacts to do one hop. As many as -okay.
Okay. By the way, so, you know, if we think about scaling, you know, just the
general Moore's law thing, if we can at the 22 nanometer node, what we do is we
keep everything the same, but then we petabytes, so that's how we can make up
this balance. Or the alternative is, you know, why don't we reduce the size of the
nodes to 100 microns in diameter and then we have maybe let's say 10 to the 12
nodes. I don't know whether you keep the wires in this case. This is just a whole
different like regime because if you wanted one micron voxel of the actual brain,
the way they like do things out in Zurich, I forget what the name of that project is,
though, it's called blue brain, I guess, we could actually simulate a centimeters
cube of the brain completely at the like molecular level with one micron voxels.
So it's a completely different tool, right, because here you're doing physical
processes and really this was originally ideas were thinking about logical
processes and doing AI, not the brain itself. But as a very detailed simulator.
And the kinds of things that they do once you get the voxel size down to a micron
cube you could do with these processors. So if you look at the kind of stuff
they're (inaudible) blue brain function.
Okay. And you know, 10 to the 9 nodes if I go back to the 90 nanometer scale,
it's about 20 million dollars. So that doesn't seem like a lot to me. And then once
we figure out how to do it, you can get, you know, 10 to the 12 operations per
second, that's a peta-operation machine for something that you put in a Coke
bottle. Which is sort of a cool idea. So that's for the brain in the bottle.
Okay. So what -- I choose to say I have a little -- I'm done in an hour -- I have an
hour, right? Okay. So I have -- I should speed along here a little bit. But one of
the things that originally motivated me thinking about this was that I wanted to
have an MREFC that was more interesting than just Internet 2. The MREFC is a
sort of massive equipment grant that NSF does, you know, like the Hubble Space
Telescope, Lego, you know the big ice cube down at in Antarctica, an instrument
for researchers in the field to study something.
And I thought right now this is research just to build this, but if we figured out how
to do it, we'd have a tool that researchers could use that would be motivating to
the guy walking on the street. Right? I mean, Internet 2 is like, okay, I'm going to
get less spam, but you know, who cares. It's like plumbers. I mean plumbing is
important, right, it saved more lives than practically any other invention, but it's
not very interesting, and if we wanted to get the best and the brightest to come
into computer science, I think we need to get back to that state where we're
doing really interesting stuff that captures people's imaginations.
So that was my original thing, so I'd really like to have this sort of machine and -but, you know, from a research point of view, I'd like to figure out how to program
this darn thing. So let me talk a little bit about that.
So first let me just talk about the basics. I showed you the video of just
everybody trying to send a message to everybody, but I didn't actually explain
how we're going to route things in this machine, okay.
And remember, it's unbalanced. Lots of processing and communication, but
memory poor. As a matter of fact, we don't have enough memory in the nodes if
you also want to do something else, to store a list of every one of your neighbors.
So the traditional sort of comes in, I pick my neighbor that it should go to and
send it to that neighbor, that's not going to work.
So what do we do instead? Well, every node knows it's XYZ coordinates. That's
actually fairly easy to do. You just run an algorithm knowing what the crystal
lattice is and figure that out.
And we'll basically do geographic routing instead of IP, so everybody gets this
unique XYZ coordinate. Tells them where they are. And it also if you're trying to
route to somebody, you sort of know how far away they are. All right. So we're
basically going to do geographic routing.
And the thing that makes this interesting is that we're not going to store a list of
everybody, but we're going to sort of the setup phase is you select the
information about all your neighbors, and then you sort of divide up this sphere,
you project everybody on to a sphere, and you pick login points, login where N is
the total number of nodes in the system that sort of random, you know, with
some probability that tries to distribute these points around the sphere.
So if I want to go in some particular direction, I know that I've got somebody
that's close to that direction and I can send it in that direction. Okay.
And we did some I didn't actually -- I should have put this graph in here, but you
know, how many neighbors do you need to pick in order to have a single
connective component, because you can imagine if you're only picking let's say
20 out of your 100,000 neighbors, then you might end up with two completely
separate graphs.
But log-in neighbors is enough to actually -- we can't prove this, but empirically at
least, it's enough to end up with just one connective component. Actually you
need many fewer than that, six or seven neighbors is enough. Because
everybody is picking a different set of random neighbors, so there's just lots of
connections. Okay?
So the routing algorithm itself is trivially simple, okay? So I am at some location
and I'm routing to some other location, so I calculate the Euclidian distance and I
know what direction I basically want to go, and I with a probability biased towards
that direction, I pick a random neighbor. So I'm essentially flipping a weighted
coin that's biased in the direction that I want to go. I don't always go in that
direction. I might go in some other direction, just to make sure I stay out of local
minima.
And then I route. And if you look at the way this is, this little function here, as I
get closer this is the distance between me and the destination, as I get closer,
the probability -- the weighting of the coin gets more and more uniform. So when
I'm far away, I'm basically greedy. I pick the node I know about that is closest to
the destination node.
As I get closer, I'm likely to pick somebody off to the side. Okay? And when I get
really close, I'm going to be completely uniform. Okay? So you say, well, look,
I'm routing to somebody. The probability that one of its neighbors has that node
on its list is trivially small. But remember that when I put a message on to a wire,
everybody can hear it. Right? It's essentially I'm broadcasting to my entire
neighborhood.
So even -- so I'm sending a message to Simon, I want to send a message to
Simon, but I don't have Simon on my list of neighbors, but I have Stewart on my
list of neighbors. So I send the message to Stewart and Simon is listening to it
and says oh, that message is really for me, and then he grabs that message.
So basically he just put a time to live on this message, and after the message
has been sent, once it runs out of its time to live, it dice.
And if we make the 2 TL big enough, then we can essentially arbitrarily make the
probability gets delivered to the right guy, 100, as close to 100 percent as I want.
Okay?
So let me show you a little bit how that works. I think this is the right one. Yeah.
I just need to get my mouse over there. Okay.
So what you see here is the destination node. So we're going to go to a
destination then we're going to go to another destination, so once we get there.
And then here's a source and there's a destination.
And so these are the red nodes are the intermediate nodes that I'm going to, and
the blue wires that you see, so the nodes have all been made to disappear here,
the blue wires that you see are sort of the neighborhood I'm sending from one
red node to another, the people, the wires that are sort of getting that message.
So all the people connected to that message can hear that message. And so for
this million node brain basically 12, a TTO of 12 is enough to get us to wherever
we want to go. Yes?
>>: (Inaudible) using here attuned with higher algorithm? So you had one that
was kind of doing this connectivity timing.
>> Seth Copen Goldstein: Yeah. It's the same brain action.
>>: Okay.
>> Seth Copen Goldstein: I don't know whether it's the same one, but the way
that we made it was the same.
>>: Yeah.
>> Seth Copen Goldstein: And we generate lots of these and over and over
again.
So this is the basic way that this works. And you can see that sometimes -- first
of all, it's hard to see because this is in 3D, so when you see two red dots very
close together, you don't know whether that's from the Z axis, so there's just a lot
of information here.
I mean, if you look at it on the screen when it's running, you can tell. But
sometimes you go a far distance, sometimes you don't go that far distance. And
this has to do with the fact that you're only keeping 10 or 12 nodes I think in
this -- for this simulation. 10 or 12 of the 3,000 nodes that you can actually talk to
on your list. Okay?
So I just showed -- whoops, I'm going backwards. It's upside down. So why, you
know, why does this work? Well, one of the things is we're trying to actually
understand this is if you look, one of the ways to characterize the graph is sort of
look at the Eigenvalue gap of the normalized laplacian, and if you really press me
on this, I'm going to just say, you know, speak to Philipe, but what I do know is
the system engineers, the closer to one you get the better.
And if you're sort of at .1, it's an expander. And we're at like .9 here. So this is
the number, so the way he calculated this is he drew, he picked a node, he
looked up 50 diameters out of the node and grabbed that entire subgraph and
then calculated the Eigenvalue gap between the first and second Eigenvalue,
okay.
And so he did this for 50 nodes, and you can see most everybody -- everybody is
above, you know, point whatever. This actually looks -- I see. Everybody is
above .99, okay. And lots of people here are very close to, you know, .996.
That's huge. And this basically what this means is that in that graph to mix
happens very quickly. You can do it in one hop you can get basically anywhere,
two hops you can get basically anywhere. And so all these little subgraphs are
what we're calling, you know, local expanders.
So, you know, that doesn't really mean anything yet because the expansion
property of a graph has to do with how it works when it scales. So we're trying to
actually characterize, come up with a way of characterizing these graphs
because they just work so well. Okay, basically it's a very rich environments,
even to 50 diameters out, the wire is only 10 diameters. This is sort of a fairly big
thing.
And as we make the graphs bigger, it takes longer to -- the subgraphs bigger, it
takes longer to calculate. So we're working on that. The actual Eigenvalue of
gap for the entire million node brain is like .89 or something. I mean, it's still
huge when you consider, you know, that you're and expander it's like .1.
Okay. So and the other thing to remember is that every transmission, every time
you physically send one message you're broadcasting to everybody.
And this looks at the number of messages in that video as an example of sending
up, you know, it's six or seven messages and we send like randomly, you know,
a couple million or the hundredth -- couple million I don't know, 10 times 10 to the
5. So it's a million messages. How many hops, you know, this cumulative
distribution graph of how many hops it took.
So you know, like 99 percent or 90 percent -- 95 percent of the messages if we
send it 20 hops get delivered. And so we -- you set the TTO wherever you want
it to be, and then that works.
And this is just still the, you know, first naive implementation of this algorithm. So
this will only get better I would expect.
Okay. So how would we use something like this? Well, one thing is we can do
high level simulation to the brain. We could look at massive, really massively
parallel algorithms and then what I'm most interested, what I'm calling massively
connected algorithms, algorithms that depend on a lot of connectivity and then
I'm not going to have time to talk about these query driven workloads, but I'll talk
about them offline.
So, you know, the obvious thing is, you know, you want to do something for
massively parallel things, you want to do some huge video pipeline. You
basically make every processor a pixel. They're all locally connected, and they're
all so, you know, and your pipeline just runs along this.
The video runs in one face of this cube and it comes out the other face, and this
is sort of an obvious use.
Let's think about massively connected ones. These are algorithms that have a
huge graph structure they work on. So, you know, sort of paradigmatic of that
would be let's say page rank. One way to think about page rank is you've got
this huge graph and you want to figure out, you know, where people end up,
what the stationary distribution is, and so, you know, is there a way we've got lots
and lots of connections, we've got lots and lots of nodes to essentially embed the
Internet on this machine and a physical link on the machine is like a logical link
and so people are sort of close together, and we can just use the massive
connections of the machine to implement page rate.
So the first thing we have to think about is how do we take this graph description
and embed it inside this system? Okay. We can only stream it in through one
phase and I've got to sort of get this completely distributed. The nodes have
limited memory, so I can't remember the whole graph as it's coming in. I'm
limiting my IO to the surface, and I don't want to spend as much time sort of
preprocessing the embedding as I do running the algorithm.
So we abandon this idea of really trying to take advantage of the physical lengths
and just use the fact that you don't have to spend many hops to get from any one
place to another.
Basically we said well, how bad would it be if we take every URL and hash to
some XYZ location and then that's where you put that page. So then the links
are directly encoded or I want to follow a link I just calculate that hash and then I
go over to that place.
And so this is how bad that is. So one of the things you have to think about is
because it's not in a direct lattice you might recalculate a hash and there's no
node at that location. And you don't know how to do -- you know, what to do with
that. So what we basically do is we say, okay, here's -- we calculate this hash
and then we try and get to that node and we are going to try for a certain number
of hops let's say 20 hops, so I'll make the TTO 20. Okay.
And then we just say wherever we ended up, that's the actual node that's going
to take this. So like any sort of hash function, you know, you've got to actually
check to see whether the node has the actual URL or not.
Then later on in the algorithm we want to go to this node, we say I want to go to
XYZ, but for this URL. And so as you're going, you're searching for that
particular URL, not just that particular location because the location might not
exist.
Okay. And you can see that this is the mean error in the number of diameters
away we are from where we hash to and so, you know, lots and lots of these
pages are, you know, two or three diameters away, there's actually a whole
bunch at zero.
This is a standard deviation. You can see they're under zero, so that double
make any sense. But some of them are pretty far away, so you probably want to
do this preprocessing stuff pretty long. You know, maybe you do 50 hops or 100
hops, so you can get closer and closer to where you're actually supposed to be.
Okay. And then this algorithm is sort of is very simple on this kind of architecture
that's so parallel. So the way page rank works is you have these random surfers
and you want to see who ends up where, right? And so basically with some at
every step in the algorithm, we start out with a certain number of surfers and so
you move to some neighbor, meaning you follow some outgoing link on some
page with some probability of one minus gamma, or you just jump to some
random place with probability grant gamma. So that we don't have to actually
jump to random places.
We probably could. It's easier to just kill all the other nodes that we have and
then rematerialize a certain number of nodes that will be equivalent of them
randomly jumping to you. Okay. And so, you know, this is how we go to a
random node in the graph. Okay. And so basically it's a fairly simple algorithm
and if you want to discuss the bound on this algorithm of how far away from
actual page length, I can do that offline, but I'm running really late.
So that's basically what I wanted to talk to you about today. And you know, what
we're thinking about mostly at this point is how we can program this thing, make
sure the basic physical principles make sense, and we're going to start thinking
more about how to build it, depending on whether I can get a student that's really
interested in that. And so that's what we're trying to work on.
I should say that right now we're sort of improving the simulator for larger
systems and we're actually implementing the page rank. We have various of
these routing protocols implemented on our simulator so we can actually study
them and we're thinking more now about the actual node development.
One of the things I'd like to do, and this is for multiple reasons, is build a
thousand node machine that actually uses this -- it wouldn't be nano scale these
wires, but uses the same basic principal just that we can actually have a really
physical system that we can show what we're doing.
It's sort of an interesting price point and it turns out that this kind of machine, this
sort of very cheap machine, you notice this four gigabytes of flesh, that's because
Dave Anderson has some interesting ideas they have to use a machine like that
for doing high query throughput processing.
So very economical in some sense in terms of the amount of power and stuff like
that that's required. So that is what we're up to. Sorry I took so long.
(Applause).
>> Seth Copen Goldstein: Are there any questions the people held? Yes.
>>: So do you feel that it's better to sort of I would say non deterministic storage
in terms of similar to our brain the information is (inaudible) distributed we don't
know where a particular (inaudible) example that's kind of what we are using
which makes sense, but of course (inaudible) in this case is that sometimes our
re-call is extremely slow, right, because we're kind of doing this, although it's
(inaudible) tremendous amount of information. Right? So do you feel that this is
kind of a trade-off you have to make, this architecture, or is it -- does it make
sense to introduce deterministic storage in order to speed up access? What's
your take?
>> Seth Copen Goldstein: So my take on this is that the hashing thing is really
easy for us to do and understand, that's why we're doing it first. But it's not the
right way to do it. That's just my gut feeling. I don't know, maybe it is. It's so
easy to implement. I don't know how much we're going to actually pay for this
versus deterministically going to some node and looking it up.
Because I don't know how we get back which nodes are where exactly, given the
sort of -- I mean, you can see we're handicapped by the memory limitation, in fact
the machine is on balance. Or maybe that's something we need to address in
the architecturally. But right now I've been pressing hard to make all the sort of
algorithms memory impoverished.
>>: (Inaudible) because this really seems to get back to the same issue in your
massive (inaudible) machines which is do you want locality and speed of access
or would you rather have this tremendous (inaudible) memory but at the same
time (inaudible) different here but it still kind of has that feel.
>> Seth Copen Goldstein: Yeah. For me it is just a massively, massively parallel
machine. It's a different kind of space, right? You're going to want to harness
the network volume, the message volume that you have in this machine. I don't
know exactly what the best way to do that is.
>>: You want to use the (inaudible).
>> Seth Copen Goldstein: I don't make any claim, even though I use the word
brain a million times, that this is anything at all like how the brain works. And
generally I'm philosophically opposed to sort of biomimetic approaches. In other
words, there's no ( birds that fly at mach 2. Nature just doesn't go there. So I'm
interested in that uninteresting space.
We can borrow and be influenced by it, but I wouldn't try to copy the structure.
So I mean, the research issues there that I'm trying to stochastic assembly, you
know, what does that mean, you know, can we harness it, is it useful? Yes?
>>: I know you're not trying to (inaudible) this is all stochastic, (inaudible) data
connections. If you take two brains and how much of it, of -- are they stochastic.
>> Seth Copen Goldstein: Really good question I do not know the answers to.
Yeah, I think there's certainly some areas that aren't that stochastic, like the
visual system is pretty much the same to everybody. I mean, the fall -- I mean
obviously not identical, but the general architecture certainly. I don't know how if
you like took a million brains and you tried to do a model of where you would
expect the nodes to be, what that sort of distribution would be, would it be tight or
loose? That would be interesting. I'm sure people have looked at it. Actually, I
don't know if people have looked at that. Probably just ->>: Is this some general assumption of that, I think, but it's ->> Seth Copen Goldstein: Has it is been tested?
>>: I don't know how (inaudible) like in brain surgeries, for instance. You know,
they'll go, they'll look at a person's brain and most of them are pretty similar ->> Seth Copen Goldstein: Well, certainly we know that the high level
architecture is very, very close.
>>: And they're actually going to do something, okay, let's go probe this and see
what's really going on there. You know, so it's a question I think of how much is
influenced by, you know ->> Seth Copen Goldstein: We all have different fingerprints. Is that stochastic or
not? Right? We all have fingerprints. I mean there's probably no identical
places where the wires are. That's something a little bit bigger than single
neurons is a lot of similarities.
>>: Let's take that to another level. One of the things I looked at when I was in
college was basically disconnection or very young children that have epilepsy,
very severe epilepsy or damage to one part of their brain, they could actually go
in and remove an entire hemisphere, okay. And you know your brain's crossed
over, so you'd think they'd lose motor function. If they do this early enough, that
maps to the other hemisphere and essentially they notice very little cognitive
deficit. So it's -- there's a basic layer that's laid down during development, but it
can be highly influenced during development and after childhood.
>> Seth Copen Goldstein: Yes and so development of the brain I think is not -childbirth is not a good place to draw the demarcation there, right? So that's the
other issue.
>>: Exactly. Right. Yeah. As they -- as the child gross up, there's a very class
particular element there.
>> Seth Copen Goldstein: So I'm going to make a shameless plug for my talk
tomorrow. I'm going to talk about programmable matter and this is just the video
some people put together. Imagine that this is each one of those also particles is
a processor. So they're doing some 3D modelling here.
But I'm happy to answer questions about the brain in the bottle. Yes?
>>: Why did you go through 3D thing to find -- what was the (inaudible) 3D
(inaudible) let's say something (inaudible)?
>> Seth Copen Goldstein: Yes. I mean, there's -- again, my vent is trying to
understand stochastic processing. But why not take the whole damn wafer and
make tiny little processors, have lots of wires between everything on the wafer
and just make a stack of these things, right, and then pump fluid through it.
It seems like -- I mean that would be interesting and maybe that is the right
architecture, but I don't know how you make connections between the wafers.
>>: Well, I'm thinking (inaudible) you throw them down in a dish, rather than
(inaudible).
>> Seth Copen Goldstein: Oh, well, the cube route is better than the square root,
that's what, for the 3D.
>>: On a similar line, why these sphere things? Like you could just have a
whole bunch of flat things that are just thrown in a pile that are kind of like ->> Seth Copen Goldstein: How do you get that wire stuff.
>>: Kind of all meshy.
>> Seth Copen Goldstein: So it's a square dye with the wires attached. They're
maybe like a long strip, a bunch of long strips so they kind of fall in all kinds of
directions, not just flat. And then I don't know what the wires.
>>: (Inaudible).
>>: Well, you could.
>> Seth Copen Goldstein: You have fewer wires and there's wiring along the
thing.
>>: (Inaudible). That's an interesting idea. Yeah.
>> Seth Copen Goldstein: I mean, here's the way I'm thinking about it is that I
want the processors, so partly it's this, you know, this video, this describes why it
is that I want the spheres because if I can get -- if I can get this thing to work and
it steps aside like fun building a billion of these then this Claytronics stuff will
happen by magic. So I have an ulterior motive.
But the issue that I've been thinking about with the -- all right. So with any 2D
thing, I don't know how I get the wiring in 3D, and I think I want to get that cube
root advantage. And I mean the idea of making this strip with a like maybe it
curls up a little bit, you drop the strip, that has -- that's sort of an interesting idea.
But I want the nodes to be really simple and think about them as a synapse.
>>: Are these spheres, when they curl up, are they actually strong enough to
support the weight of the things above them or will they smoosh down ->> Seth Copen Goldstein: Well, the process is a little more complicated than
that. You can think of them as glass beads. So we're going to do something that
actually make it solid, so this fluid is not running through it, for instance.
>>: The fluid is going to give buoyancy and support, though, too, I would think.
>> Seth Copen Goldstein: Yeah. But in -- I mean, it's like a piece of glass. A
piece of ->>: So (inaudible).
>> Seth Copen Goldstein: And actually we're not thinking about curling like this,
we're thinking about like taking a Mercader map projection so when you fold it up,
it's actually almost 100 percent of the service use. That was just an initial. I'll
talk about that more tomorrow.
>>: (Inaudible) Q2 funding.
>> Seth Copen Goldstein: I'm having a dry run of getting funding right now. So I
don't know.
>>: Well, what's your scaling, what you think you need to to get that (inaudible).
>> Seth Copen Goldstein: Oh, I think building a sound -- you know, almost
everyone in the United States is from Missouri, basically. Yeah. I think building
this machine would be very useful, but I think maybe -- I don't know. I might not
be the right guy to fund the next step if it's not an architecture of it, it might be a
chemist, for instance. But we, you know, I think also as we can show, at least in
simulation that the algorithms are interesting, then you know, that's also part of
the next step. So I think another year of simulation and algorithm development
was fruitful. Meanwhile there's this thing going on with the CCC, so. And we
have enough data to motivate that. And so that's the important thing. That was
sort of the important thing. So it's a very indirect kind of process.
>>: There's no (inaudible) if you could (inaudible) breaking cryptography, you
would (inaudible).
>> Seth Copen Goldstein: I don't know how much connectivity you need. You
just need massive parallels. And on the other hand, they just want to dump
those things in a big box, locally connected, probably good enough. It will be
much easier to build.
>> Rico Malvar: Okay. So this is (inaudible) around for the next couple of days.
He's really busy with (inaudible). I'm sure he'll be open to dialogue at a time, he's
very passionate about his work, he gets fascinated with. So thanks very much
for coming in to the. Thanks.
(Applause)