The halting problem states that it's impossible to prove if any arbitrary program halts. This has no relevance to latency of real software. Software is laggy because programmers pile up abstractions without caring about latency, not because of an abstract mathematical theorem. It's possible to write hard real-time software with provable latency bounds.
It is possible, but the proof's effort grows combinatorially with the size of the program. The large majority of "real software" is not amenable to this kind of test, making the mathematical theorem very concrete.
I am not sure what you are trying to say here but the halting problem does not say anything about runtime and is very much not relevant to real world computers which are strictly speaking not even turing complete due to having finite memory.
That you cannot have a program that will decide if arbitrary theoretical programs halt on arbitrary inputs has no bearing on how well specific real-world software is able to deal with real-world inputs. You can have a smartwatch, a virtual synthesizer and IoT switches that are guaranteed to have a fixed upper response time for the tasks they are designed for. That they don't provide these guarantees is only because most users prefer a device that works 99% of the time but is much cheaper.
You don’t have to solve the halting problem to have consistent latency - you are conflating distinct concepts. The fact that a computer can’t check if an arbitrary program will eventually halt does not preclude the existence of programs that halt with exactly the same number of instructions every single time.
The halting problem states that it's impossible to prove if any arbitrary program halts. This has no relevance to latency of real software. Software is laggy because programmers pile up abstractions without caring about latency, not because of an abstract mathematical theorem. It's possible to write hard real-time software with provable latency bounds.
It is possible, but the proof's effort grows combinatorially with the size of the program. The large majority of "real software" is not amenable to this kind of test, making the mathematical theorem very concrete.
I am not sure what you are trying to say here but the halting problem does not say anything about runtime and is very much not relevant to real world computers which are strictly speaking not even turing complete due to having finite memory.
That you cannot have a program that will decide if arbitrary theoretical programs halt on arbitrary inputs has no bearing on how well specific real-world software is able to deal with real-world inputs. You can have a smartwatch, a virtual synthesizer and IoT switches that are guaranteed to have a fixed upper response time for the tasks they are designed for. That they don't provide these guarantees is only because most users prefer a device that works 99% of the time but is much cheaper.
No it is not possible for arbitrary programs with arbitrary being the operative word.
2 replies →
You don’t have to solve the halting problem to have consistent latency - you are conflating distinct concepts. The fact that a computer can’t check if an arbitrary program will eventually halt does not preclude the existence of programs that halt with exactly the same number of instructions every single time.