So the elephant in the room is the halting problem. Consider a program like this:
while (true) { } // do nothing forever
cout << "Finished" << endl;
This can never halt. It can never print "Finished." Clearly it cannot complete nearly instantaneously.
So the solution has to handle this infinite case. Your solution is to have the machine break, until a reset button is pressed. This handles the easy case, but there be dragons nearby.
Consider that C is turing complete. This means it can describe other turing complete languages. Let's pick Java, because it happens to be convenient for where the story goes next. We can write a program in C consisting of a Java virtual machine with an extra block of text in it. That text is JVM bytecodes, and the virtual machine will run it as code. This is important because now C can do all sorts of nefarious things, like providing the Java sub-program its own bytes as input. Now consider a program with the following pseudocode:
read input as a program
determine if the program will halt or run forever if fed itself as input
if the program would have halted, loop forever
if the program would have looped forever, halt
Let's say I wrote this in Java. I could feed it any program in Java, and it could tell me if it halts. However, what happens if I feed the program itself? If the program halts, it will loop forever. If the program loops forever, it will halt. This paradox is at the center of a decidability problem called the halting problem, and it is a fundamental limit of programming.
Edit: Now this seems to be the topic of much consternation, especially since we're going to make claims about solving the problem. This apparently has even caused this answer to be passed up for selection as the "best" answer. Now consider a program consisting of:
- A virtual machine, pick the JVM as an example. As a special detail, this VM uses an unlimited precision counter to count how many opcodes have been used. Such counters are well within the realm of computation, given that the memory model of the computer does not specify any upper limit, so I can count using an infinite number of bits.
- A program under test. This is a sub program which will be run in the JVM, counting how many opcodes are issued
- A main loop which initializes the VM, runs the program, and then determines if the resulting number of opcodes is finite (which can be written, albeit perhaps calling for an infinite loop).
- This program then prints whether the number of opcodes executed was finite.
This is an easy to write program, though it is hard to execute it on our mere physical machines. I have written a program, in a traditional computer language, that just happens to require infinite time to execute. By the exact wording in the question, "This device can have the capability to generate true random numbers, and run any program instantly," it must be capable of running this program instantly. This is the actual problem... its a problem with the question which prevents the question from having a meaningful answer until it is properly resolved.
The halting problem is known as a "non decidable problem". There is no way to determine if any arbitrary program halts or loops forever in finite time. The only theoretical way to do it is pushed off to infinity... You have to run the program for an infinitely long time, and see if it halts or not.
However, your supercomputer has oracle capabilities. If a program doesn't halt, the answer comes out instantly. If the answer doesn't come out within nanoseconds, then the operator knows the program actually ran forever, and hits the reset button. Either way, the oracle has answered the halting problem in finite time. This is... big. You can give it programs that would have taken an arbitrary amount of time to run, and it gives you answers instantly. But more interesting, you can give it programs that never loop, but run forever (chaotic systems), and it can give you those answers as well. It can even tell you which ones remain chaotic forever, and which ones eventually loop.
The consequences are... mindblowing. To start, any question which can be phrased in a "formal language" can be answered instantly. Screw AI's cleaning up in Jeprody, now we're talking about solving world-hunger and global-warming sized problems as fast as you can phrase the problem.
Halting also interacts with Godel's incompleteness theorems. This would have religious implications. Many religious statements which are unprovable are suddenly provable with access to a halting oracle. The question of which religion is the "right" one is suddenly within our grasp. One could make observations about our universe, then plug it into a program which simulates all possible universes, and figures out which religions are consistent with the observations. Gather more data, weed out more religions. Then go prove the one religion that is left.
Whichever country has ownership of the supercomputer instantly rules the world. While the path of nations is not fully predictable, it has enough computability that access to that oracle would guarantee flawless victory in every military endeavor the nation undertakes.
So, that's all boring. Way too powerful. How can we cut it down? One answer is statistics. Define two distributions: one for halting programs and one for looping programs. Each distribution should include answering instantaniously, answering in an infinite amount of time, or anywhere inbetween. You can weight the distributions such that the expected run time of a halting program is 1ns, and the expectation of the run time for a halting problem is undefined (i.e. skewed towards infinite run time). The oracle decides the halting problem, then does a draw from that distribution. It then waits that long before announcing the problem.
Now, when it takes a long time for the problem to get answered, it becomes a probability game. Is this an unluckily long halting problem, or is it an infinite looping problem? We only get a statistical answer to this question, so we do not get a definitive answer to the halting problem. This bounds the problem as you woudl like it.
Amusingly enough, if we don't know the distributions (we just know they are statistical), we have a multi-armed bandit problem for anyone seeking to abuse the oracle. This is a well known and rather nifty set of problems, which make for a good story.
Edit: An even more insidious pattern which I did not account for until Samuel's comment: there's no reason we wouldn't build a traditional robot around this oracle. For dealing with large programs which need to collect data from the real world, what if the output of the oracle is a set of instructions for data to collect, plus a new program to run on the oracle with that data (think of it like a singularity event). Now the limiting ability to process data is that we need to reload the working memory of the program each time (USB is actually not a size limit here... it supports 64-bit addressing, but it does limit transfer speeds). Now nothing stops this robot from cruising the world, gathering data, abusing the oracle to do infinite amounts of processing whenever it needs it.