31–40 of 48 posts
Isn't the real challenge finding anything made today that has less compute power than the lander? I challenge you to find that.
It does make sense to me that automating only the bare essentials could be an intentional choice on a lunar lander. Relying on intense discipline + training of the astronauts combined with dirt-simple automation should hopefully put them in a good spot to resolve issues you couldn't predict earth-side. If you automated too much, the thing that goes wrong could be a bug IN the automation, which is obviously going to be harder to train for.
There's also power savings and weight, which I'm sure were big factors... so I can't imagine the guidance computers were great examples of the most performant compute 60s/70s had to offer.
(Also, not able to listen to the podcast right now, so if that idea gets dispelled during it, disregard me. Just basing this on what I can read over a coffee break.)
It’s like measuring national power by population, or saying that ants have “more power” than humans because ants are more numerous, have more legs and can lift more per unit of size. It’s fun to think about for about five seconds before recognizing that “power” is about capability, not abstract numbers.
If I get back to middle ages I will be smartest man on in the world - first question “so how do your mobile phones work actually and can you build one?”
Well great you can compare compute power but can you get to the LEO at least? I don’t think so.
Earlier quoted context omitted.
I guess even a disposable vape has more computing power than the Lunar lander. (I don't know if that's more or less ridiculous than a key fob, but at least a key is not so disposable.)
Car chargers for usbs, or digital thermometers, or disposable pregnancy tests - it's absurd the amount of compute that ends up even in single use or trivial products.
That's a really interesting comparison! But does anyone know if any Apollo lunar lander was specifically notable at the time for the power of compute on board? I feel like the takeaway could be "wow, technology has come so far, the pinnacle of computing in the 60s is bested by this stupid keyfob." It does make sense to me that automating only the bare essentials could be an intentional choice on a lunar lander. Relyi…
It was somewhere in between. Absolutely impressive for the physical volume and was consuming about 80% of all integrated circuits being produced at the time, but around an order of magnitude slower than the fastest computers at the time (and maybe more depending on how you want to calculate that. It's very back of the envelope).
And it did have huge amounts of automation. The modern multitasking hard RTOS was basically invented for the AGC. The pilots weren't super happy about it, but also it's generally considered that landing on the moon is essentially impossible without huge amounts of automation.
The contactless chip in your credit card is a full computer that powers up via inductive charging when tapped. It then negotiates 2 way public/private key encryption to verify you. These usually run jme which requires a lot more power than the lunar lander. Another good one is the many little computers on cars such as the TPMS sensor in each tyre valve.
No char, double, float or long types. No arrays with more than one dimension. New creates persistent objects in something like flash with no runtime garbage collection. No String, and in fact most of java.lang.* is missing, etc.
Low cost ARM M series microcontrollers are ubiquitous, and they're all immensely more powerful than the lunar lander computer.
The contactless chip in your credit card is a full computer that powers up via inductive charging when tapped. It then negotiates 2 way public/private key encryption to verify you. These usually run jme which requires a lot more power than the lunar lander. Another good one is the many little computers on cars such as the TPMS sensor in each tyre valve.
Well, they run javacard, which is a far cry from normal java or even jme. No char, double, float or long types. No arrays with more than one dimension. New creates persistent objects in something like flash with no runtime garbage collection. No String, and in fact most of java.lang.* is missing, etc.
I guess the portability of bytecode? A modern version might use WebAssembly instead which feels more suited as it’s much lower level (at least without the modern GC extensions)