What exactly makes PHP CLI fundamentally unsuitable to power all the math on board a space craft?

Question

Let's say that there is an eccentric multi-trillionare who made his fortune by coding a very popular service in PHP. He knows it very well, and has such a love for it that he makes a rather unorthodox decision:

He starts a new "space tourism" company, hiring the smartest people in the world and pumping in countless trillions of dollars into giving them access to the best hardware and parts and materials that money can buy. There is just one small "catch": it has to run PHP CLI for all the calculations.

That is, they can freely choose whatever existing OS, commercial or not, and the best hardware that money can buy, but it has to run the unmodified stock PHP CLI (latest stable release), and it has to use only CLI PHP scripts for all the calculations.

They are allowed to fully vet the code, compile it locally, exclude as many or as few of the included base extensions as they wish, etc., but they cannot code their own interpreter or make changes to the code which powers PHP CLI itself.

What, exactly, is it about this that is so "crazy"? I realize that it probably is, but I don't understand why. I frankly cannot remember PHP ever "calculating the wrong number" or even crashing on me, especially not when I'm not involving a bunch of fragile external software as well. The "core" of PHP appears to me to be very reliable, and I would definitely not be skeptical to running PHP CLI on the "master computer" for a major corporation or bank.

Of course, space travel gives the phrase "mission critical" a whole new meaning, as any error could result in death, but does a space craft really ever have to have the answer so quickly that it matters if it takes a few more milliseconds? Because isn't that what we are talking about in terms of performance? Just about any math problem I've ever thrown onto PHP has been "instantly" (to my eyes) calculated every time. If the space crafts of the 1960s were able to go to the moon and back, how could PHP CLI running on some ultra-stable commercial or custom OS with a modern, expensive space computer as the bare metal have any problems whatsoever?

Am I somehow over-simplying things somehow? Not thinking about some crucial detail?

Of course, the engineers are allowed to make a bunch of redundant virtual machines and/or physical computers that all do the same thing and communicate with each other. They just all have to do all the actual work and calculations with PHP CLI scripts.

Admittedly, I would not dare to travel in this space craft myself, but then again, so wouldn't I no matter what it runs!

Also, the "ground control" part also is bound by the same constraint, so that they don't "cheat" and simply calculate everything down on Earth and then send the space craft the instructions directly. Having said that, they aren't required to do every calculation related to the mission on the space ship, as long as the space ship is able to function independently and both go into space (let's say to the moon) and return to Earth without depending on analogue 1960s equipment which bypasses the PHP CLI requirement or something like that.

Essentially, what I'm wondering is: What about using PHP CLI is so fundamentally incompatible with this? Even if you're gonna reply that it doesn't do secure floating point or something, can't they just use integers like they always did in old video games when they didn't have FPUs, or use the "BC Math" base extension in PHP to get "true floats"?

I am very much looking forward to the insightful and clarifying answers to this, and I hope I won't see any mindless PHP bashing.

Answer 1

Developing software for space applications is quite different from "regular" software development, especially when we're considering human spaceflight.

If you want to develop critical software (i.e. software that, in case of a failure, can lead to loss of life, mission, and/or facilities) for ESA, you need to comply with the applicable standards defined by the European Cooperation for Space Standardization. Some things you need to do in order to comply:

• You need to provide a CPU budget and a worst-case execution time analysis. This is to prove that your CPU will never "run behind" and miss a deadline for real-time execution.
• You need to provide a memory budget and prove that your application will always have enough memory with a large margin.
• You need to test each and every line of code (100% code and branch coverage, etc.)
• You need an external party to check every line of code.

You hopefully agree that doing this for PHP CLI, and correct any issues, is going to be a very expensive exercise. Of course, your multi-trillionaire is free to not follow the ECSS (or equivalent NASA, JAXA, etc.) directives, but the standards have been implemented for very good reasons...!

---

(Note: these ECSS requirements typically don't apply to e.g. cubesats, because cubesats only power on when in orbit, where they can't cause loss of life or launch facilities, and thus their software is not considered critical. That's why you'll see a lot of open-source stuff on cubesats, like FreeRTOS)

Answer 2

Let's have a look on a 1998 paper on real time systems from CMU (Carnegy-Mellon Univeristy).

Typical examples of real-time systems include Air Traffic Control Systems, Networked Multimedia Systems, Command Control Systems etc. In a Real-Time System the correctness of the system behavior depends not only on the logical results of the computations, but also on the physical instant at which these results are produced.

A missed deadline in hard real-time systems is catastrophic and in soft real-time systems it can lead to a significant loss.

So your question can be generalized to finding out, how much real time precision is required for which situation during operation of a space craft; I am not an expert in this but I think there will be different types of control, sometimes you have more time and sometimes less. From there, requirements can be specified.

Going back to Earth, let's have a look on a problem which appears trivial compared to space. You have written: "... does a space craft really ever have to have the answer so quickly that it matters if it takes a few more milliseconds".

Let's have a look on the airbag design. Imagine you have to implement it with PHP. How much time is there to a save a life during crash? Engineers have designed the airbag's ECU (electronic control unit) to kick in during first 15 milliseconds of the crash, or even 10.

PHP binary needs to be launched every time you want to do a calculation. Would a process use it to poll crash sensors? PHP was designed to operate in a web server environment.

Finally, cars are much slower than speeds you find in the space.

Answer 3

What exactly makes PHP CLI fundamentally unsuitable to power all the math on board a space craft?

...

What, exactly, is it about this that is so "crazy"?

You seem to be taking the unsuitability of PHP as a given premise here. Why is that?

PHP has two major deficiencies that are relevant here.

One is that it's not very performant; the reference implementation is an interpreter rather than a compiler. This is trivially dealt with by using more powerful hardware; modern hardware running a slow language is still vastly more powerful than 1960s hardware running hand coded assembly.

The second is that it has a number of error prone design features -- in particular it's weakly, dynamically typed, which is great for whipping up scripts quickly, but not so good for establishing confidence in the correctness of a large program. This can be dealt with by spending more time in testing and review.

In my opinion, PHP would be a terrible, terrible choice for a language to run a space program on, but the problems are largely surmountable by throwing additional time and money at them.

Answer 4

Modern PHP runs on a Virtual Machine: A guaranteed environment that will exist regardless of underlying operating system or hardware.

That is, core library functions that depend on features of an OS are not part of the VM, such as getting the PID of a child process after performing a pcntl_fork() in a Posix environment.

Rather, language constructs like foreach will always behave (more or less) identically regardless of platform. While the compiler writers and standards committees for C++ are simply amazing, they explicitly state that they do not have a virtual machine. Your compiled C++ code runs directly on the physical machine, and is dependent on the processor architecture for its behavior. (I am confident that the C++ designers have nailed down their version of foreach for all major platforms so that they're indistinguishable regardless of processor, but there are some very strange, fringe platforms out there.)

The standard PHP interpreter relies on modern operating systems. None of the operating systems that PHP depends on are Real-Time Systems. There may be ways to strip some versions of the Unix and Linux Kernels down so that they provide actual real-time functionality to processes running on them, but this leads us to a separate issue:

PHP does not allow direct memory access, and programs running in Real-Time need to directly access memory.

This is a great thing for web development and general purpose scripting. Us PHP developers do not have to worry about the truly devastating security implications of buffer overflows and underruns. The VM knows, at runtime, if our variable is holding a value, a reference, or a lambda (anonymous function), and will act appropriately, rather than just letting the processor pick up user-specified data and letting it run uncontrolled. Heartbleed could not have happened with PHP. (This is good, because I've seen how some of my peers treat user-generated content.)

One feature of scripting and VM-based languages in general is garbage collection. The VM can know when memory is truly unused at runtime, and can take over the script's time to clear and re-allocate that memory. There is no way for the script to know when or how the free memory will be collected, though... And while a user of a website may not notice a few hundred milliseconds being added to the site's loading time, critical spaceflight systems might notice this in disastrous ways. (They probably wouldn't fail, but while I'd trust a business and my reputation to modern OSes and PHP; I wouldn't trust my life to modern OSes and PHP.)

It's not all doom-and-gloom for PHP, though. Outside of life-critical functions, PHP has the flexibility and memory safeness to help humans manage many computing tasks... And, if you absolutely must get every last ounce of computing power that you can get from compiled languages, while still telling the billionaire who is paying your paycheck that you're using pure PHP, you can write PHP modules in C or C++, compile them into SOs (DLLs), and be on your way.

Also, coming in PHP 7.4 is support for Foreign Function Interfaces. You no longer need to format your .so (.dll) into a PHP module, just compile it to a basic .so, give the .h file to PHP, and hire a senior PHP dev who will know how to troubleshoot the inevitable segfaults that your junior developers will create.