Fashionable, but unable to tell fact from fiction (testing4l) wrote,
Fashionable, but unable to tell fact from fiction
testing4l

Welp, the day is fast approaching. Tomorrow I'll look my program counter in the register, fetch, and execute an increment, sending the current accumulator contents to the ALU, and restoring them after execution of the instruction.

Of course, with pipelining, some of this has already happened.

Nothing special -- as far as I know -- is planned, though our weekly game night happens to fall on the date of my usual increment. (Actually, that's a lie -- I think I know one thing that's happening, but I'm trying really hard to forget it. REALLY hard). I tossed up a post in scgamenight about possible ideas for tomorrow evening.

It just so happens that today may well prove to be a red letter day in the history of computing. At the Computer History Museum, a company called D-Wave demonstrated a 16 qubit quantum processor -- the first public demonstration of a quantum processor in a commercial application and the first public demonstration of a quantum processor of that size. They apparently maintain a blog too.


For those suffering from technobabble overload, I'll explain. A quantum processor works very differently from a normal one. A normal processor like you have in your computers run a series of instruction. Some programmer wrote something that tells the computer what to do and it blindly follows it. As a result, solving a problem requires one to write a series of instructions to come around to a solution. How the programmer writes that directly affects how quickly the solution is computed and so on.

By analogy, a normal processor is like a truck driver. You give him directions and tell him that his cargo's expected in Manhattan in a week's time. He gets to Manhattan and your job's done.

A quantum processor specializes in finding optimal solutions to things, but instead of writing algorithms to tell it how to do things, you give it a series of constraints and it settles at a solution with those constraints that uses the least energy. There isn't a meaningful road analogy for it -- and this only pretends to be a good analogy -- but picture a glass surface. You want to find out where the lowest point on it is, so you put a drop of water on the surface, and it runs along by gravity until it forms a pool at the lowest point.

Very neat and very strange. It doesn't really have an application in desktop PCs yet and the company believes it won't *replace* modern day processors, but rather, it will work in concert with one. At the moment, with minimal modification, they can take normal programs and execute them using their quantum processor -- and did so. One matching molecules in a drug database, another solving a Sudoku puzzle, and another handling seating arrangements. It was all pretty small scale stuff and they mentioned a number of times that their present method isn't nearly as fast as the conventional algorithms and chips, but for a proof of concept, it's serious stuff.

What captured my mind was the future of software though. To give a (very) brief history of programming languages, the first real ones were all high level, pie-in-the-sky type stuff that forced you to express problems in a given context. LISP, for example, had you do everything in terms of lists of data. FORTRAN had you express things in math. COBOL had you express things in terms of database tables and manipulations.

What really changed things was C -- a language which accurately reflected how the hardware worked. Eventually, people used it to define their own paradigms -- C++ and Java are excellent examples of this.

I've been trying to think of the equivalent quantum programming language -- it's a topic that no one really seems to want to tackle at the moment. The designers seemed to show a proclivity towards SQL which made me think of a different declarative language that was arguably SQL's ancestor called Prolog.

Prolog does strange things. Essentially, you define all of your data and you define a series of rules. For example, you could have a database of flights -- departure times, arrival times, and locations. If you wanted to find how to get from LA to Portland, you'd make a function to handle the trivial case of a direct flight:
go(X,Y) :- flight(X,Y).

and one of the same name to handle layovers.

go(X,Y) :- flight(X,Z),
flight(Z,Y).

To find your answer, you then type into the interpreter:
go(LAX, PDX).


Keen, eh?
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 4 comments