Tuesday, November 27, 2018

What do all those transistors do?

The CPU in your laptop or desktop has a lot of transistors in it.  The Core i7-6700HQ that I'm typing this on has 1.35 billion of the little guys.  Buck back in the day on of the earliest computers, ENIAC, had only 20 thousand vacuum tubes which more or less fufilled the same role as transistors do now.  So what do all those extra transistors we've added accomplish, if we were able to do useful mathematical operations with just 20,000?  Most of the increase in the speed at which we run computers, the clock rate, has come from replacing large and slow transistors with smaller and faster transistors after all.

Well first, what was ENIAC doing with it's transistors?  A single transistor isn't very useful.  If you're willing to use a resistor too you can perform an operation like making an output the logical and of one input and the inverse of a second input, call it AND(A, NOT(B)).  But that circuit is a very jury rigged thing which will be slow, unreliable, and fairly power hunger.  You can make much more solid and-ish circuit, NOT(AND(A,B)) or NAND, from a couple of transistors and a resistor if you don't mind being power hungry.  But given that Moore's Law has made transistors cheaper and cheaper relative to resistors anybody these days would use a four transistor NAND circuit which is faster and more power efficient than the resistor and transistor equivalent.

What if you want to add two numbers together?  Digital circuits output zeros and ones so first you have to decide how many base 2 digits you want to be able to represent since you need enough output wires for the largest number the machine can handle.  In a modern all-transistor design you'll be using 16 transistor for every bit of the addition.  On a 32 bit adder which many processors used around 2000 and which is roughly equivalent to what ENIAC used this'll be 512 total.

But you don't want a computer that only adds numbers. You want a wide variety of instructions you can execute, you want some way of choosing what instruction you execute next, and you want to interact with memory. At this point you're up to 10,000s of transistors. That will give you a CPU that can do all the things ENIAC could do.

Now lets say you don't want your entire operating system to crash when there is a bug in any program that you run. This involves more transistors. And you probably want to be able to start one multi-cycle instruction before that last one finishes (pipelining). This might get you up to executing one instruction every other clock cycle on average. That'll cost transistors as well. This will grow your chip up to 100,000s of transistors and will give you performance like the Intel 386 form the mid 80s.

But this will still seem very slow compared to the computers we use nowadays. You want to be able to execute more than one instruction at a time. Doing that isn't very hard but figuring out which instructions can be executed in parallel and still give you the right result is actually very hard and takes a lot of transistors to do well. This is what we call out of order execution like what the first Intel Pentium Pro had in the mid 90s and it will take about 10 million transistors in total.

But now the size of the pool of memory that we're working with is getting bigger and bigger. Most people these days have gigabytes of memory in their computers. The bigger the pool is the longer it takes to grab any arbitrary byte from it. So what we do is have a series of pools, a very fast 10kB one, a slightly slower 100kB, a big 10MB one on the chip, and then finally your 8GB of main memory. And we have the chip figure out what data to put where so that the most of the time when we go to look for some data it's in the nearby small pool and doesn't take very long to get and we're only waiting to hear back from main memory occasionally. This and growing the structures that look forward for more instruction to execute are how computers changed until the mid 2000s. Also going from 32 to 64 bits so that they could refer to more than 4GB of memory, the biggest number you can say in only 32 bits is 4294967296 so any memory location over that number couldn't be used by a 32 bit computer. This'll get us up to 100 million transistors.

And from the mid 2000s to the mid 2010s we've made the structures that figure out which instructions to execute next even bigger and more complicated letting us execute even more instructions at once. As we grow performance this way the number of transistors we needs grows as the square of the performance, on average. And we've added more cores on the same chips letting us grow performance linearly with transistors as long as software people can figure out ways to actually use all the cores. And now we're up to billions of transistors.

All this raises the question of whether you could just take a design 10,000 transistor cores you would have used back in the day and put 100 of those cores in a CPU instead of the 4 you'd normally buy.  To some extent you can do that.  If you want to have them all talk to each other and with a good amount of memory you have to increase their width to 64 bits but that doesn't take so very many transistors if the rest of the design stays simple.  And they'll be slower individually but each of the 10x transistor steps causes something like a doubling of performance rather than a 10x increase in performance.  The problem is that it's hard to write software in such a way the work can be broken up neatly into 100 different threads of execution.  And some operating systems, such as Windows, tend to problems dividing up work efficiently between more than 30 or so threads.

In theory you could have 2 large cores for cases where the software doesn't support a lot of division of work and another 30 tiny cores to handle cases where the work can be divided easily.  The operating system would have to be aware of this, though, and prefer running tasks on the fast cores first before less tasks trickle down to the slower cores.  Something of the sort has been done on mobile phones where you might have 2 fast cores and 4 slow cores.  But on your laptop you mostly see this sort of thing with a few large cores running your applications and a gaggle of small cores in the GPU doing the graphics processing.

Sunday, November 18, 2018

Book Review: Radical Abundance

Eric Drexler is the person who came up with the name "nanotechnology" and is probably the one most responsible for public awareness of the idea.  After a pretty long haitus he's published a new book and I thought I'd take a look but before I get to the new book I think I should provide some history.

Way back in 1986 Drexler published Engines of Creation.  In it he outlined a vision of a world remade by the ability to engineer chemicals the way we engineer widgets today, assembling them precisely using mechanical arms placing bits in position rather than waiting for the random thermal motion of molecules to bring parts into contact where they can stick.  In the book he envisioned tiny robots called assemblers constructed with atomic precision using tiny arms to assemble other devices - and also replicate themselves.  That ability to replicate could potentially be a big danger if an error in programming caused them to replicated without bound like a cancer.  The cells that make up our bodies are contained by having to have had a clear evolutionary path from point to point.  It took a billion years for mitochondria to evolve since that required multiple things adjusting in a cell at once.  There are quite plausibly ways to drastically increase the efficiency of self-replicating organisms that could be designed by engineers which evolution wouldn't find before the Sun consumes the Earth.  Specifically, you could have these nanobots made out of much stronger molecules and life could use and also, thanks to placing things deliberately rather than wait for random motion to put things into place, they could potentially replicate much more quickly.  So it's possible that, if you can make good enough self-replicating nanobots and they have a fault you might see them end up consuming Earth's biosphere and turning it into grey goo.

After this publication Drexler went off to do some doctorate work which he later published at Nanosystems in 1992.  Rather than conceptualizing molecular manufacturing in terms of tiny robots he wrote about it in terms of molecular factories and assembly lines.  There are a lot of advantages to this approach.  Encasing a molecule in a tube as some operation is done to it limits its range of thermal motion much more effectively than trying to hold it it at the end of an arm.  By having the structure of a conveyor line encode a sequence of operations you don't need a nano-scale general purpose computer which made up the bulk of the atoms in the back-of-the-envelope design for a nanobot in Engines of Creation.  And you don't have to worry about a factory replicating itself in the same way you do with a tiny robot.

And that brings us to Radical Abundance published in 2013.  The book is a policy book like Engines of Creation was but the engineering in it is very much all post Nanosystems; looking at construction in terms of assembly lines rather than craftsman nanobots.  There's also a large segment on the public perception of nanotechnology and how it has changed over time.  Because of excitement about nanotechnology in the late 90s and early 00s a lot of chemistry tried to re-brand itself as nanotechnology to absorb nanotechnology research dollars.  This would involve molecules smaller than 100nm created by normal thermal motion chemistry rather than through forcing molecules together with external guidance.

Additionally, a lot of the public thinks of nanotechnology in terms of tiny nanobots instead of in terms of factories made out of atomically precise parts.  This is, of course, because that's how Engines of Creation conceptualized it and because Engines is a much easier to read book than Nanosystems is.  I was expecting some sort of mea culpa from Drexler on the matter and maybe an explanation on what he'd gotten wrong in his first book.  But Radical Abundance never seems to let slip that the ideas Drexler now finds so annoying were spread by his younger self.  I think a section going into a bit of detail on why nanobots aren't workable would have been a useful addition to this book but Drexler just dismisses them here with eye rolling.

But because of these two ways in which the word "nanotechnology" no longer means what he intended it to back in '86 he is now promoting "Atomic Precision Manufacturing" or APM as a term for the technologies he's interested in.  I wish him good luck with that but I'm doubtful he'll succeed.

What seems more likely to succeed are attempts to build these "APM" capabilities, at least eventually.  Our science of the nanoscale is currently imperfect but engineering practice can let us proceed anyways.  It's very hard to look at a protien and figure out how it will fold when placed in water.  I currently have my desktop give some spare cycles to figuring out some medically important proteins.  But that doesn't mean we can't just design proteins to fold understandably if we're willing to be a bit less efficient than evolution is.  We don't understand how every molecular surface interacts but we can restrict ourselves to the surfaces we do understand.  We can't predict the exact strength of every structure but we can design in sufficient safety factors to cover our uncertainty.  There's a lot of scientific work being done pointing towards APM and Drexler gives a good high level over view of it.

I'm going to say that I don't have any firm idea of what sort of time scale progress on APM/nanotechnology will happen on.  But I think I'm persuaded that it will happen eventually.

And just because I saw it recently, here's A Capella Science's song about current research in nanobots.

The very long run for SARS Covid 2

Many of the worst pandemics that afflict us are from pathogens that don't normally prey on humans.  Probably the most famous pandemic in...