# Executing an algorithm constantly on slow and fast machine

Is it possible to create an algorithm that will execute at the same rate and speed on faster and slow computers. What i mean is, i have a year 2000 desktop that can run a certain computational algorithm. a hundred years latter, quantum computers have arrived in their full capacity and i want to run the same algorithm. the Quantum computer should never be able to catch up with the slow computer. The several ways i can think:

1. Locking the execution of an algorithm to a specific time, but the problem with this is someone could possible alter the ticks in a second, eventually making the execution time very small, hence fastening the execution.
2. Create a function that only uses a fixed amount on memory. for this i don't know how practical it is.

What could i do to achieve the desired consistency?

• – gnat Aug 6 '18 at 11:16
• In a way you are touching on a really hard problem of critical importance: How can I create an encryption algorithm that will still be safe in a few decades? Current public-key crypto algorithms (e.g. based on integer factorization or elliptic curve problems) are not quantum-safe. – amon Aug 6 '18 at 12:16
• This is pretty simple: if you want to achieve timing consistency, you need a reliable clock. If there is no such clock available (or the clock can be manipulated), the program cannot make any guarantees about its wall-clock running time. – Doc Brown Aug 6 '18 at 19:36

# No

It's not possible.

The only "solid" solution to achieve the same execution time would be the "literal" approach: Using the language's date/time library to wait for a fixed time before quitting. This is because the language itself guarantees its correctness. If Java is still going to be used in the year 3000 on a quantum computer, the Java makers will have the important bits ported and adjusted so that one second is indeed a second. However, if I understand correctly, the system is so compromised that even a second is not a second anymore.

The other direction you aim to go there - abusing hardware quirks and restrictions as a timer, a bit like The Story of Mel - is by its very definition tied to a certain set of hardware. Hardware getting faster and/or changing is not just a potential danger to look out for. On the contrary, we can say with confidence that it will most definitely happen.

## Instructions vs Executions

It makes sense if you think about it like this: A program is just a set of steps for a computer to execute. The steps don't care about how (fast) they are executed. That's completely up to whoever takes the steps and executes them.

Because timing is a thing needed often, there is a way (in most programming languages) to say "wait 2 minutes" - but if the instructions are not followed... At that point you actually have a faulty compiler/computer/VM. At that point, timing issues are only one of your smaller problems.