Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C++ standard for the F-35 Fighter Jet [video]

youtube.com

Post reply on HN
Print view View original

211–220 of 451 posts

Re: The C++ standard for the F-35 Fighter Jet [video]

#211

Post by coderenegade »

mmooss wrote: post #184
stackghost wrote: post #62

Earlier quoted context omitted.

No I'm not joking at all. The Autocode feature generates code that has high fidelity to the model in simulink, and is immensely more reliable than a human. It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0`, for example. Any human who tells you they have not made this mistake is a liar. Unless there was a second uncommanded acceleration problem with Toyotas, my understanding i…

> It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0` That's a classic bias: Comparing A and B, show that B doesn't have some A flaws. If they are different systems, of course that's true. But it's also true that A doesn't have some B flaws. That is, what flaws does Autocode have that humans don't? The fantasy that machines are infallible - another (implicit) argument in this t…

What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me.

The main flaw of autocode is that a human can't easily read and validate it, so you can't really use it as source code. In my experience, this is one of the biggest flaws of these types of systems. You have to version control the file for whatever proprietary graphical programming software generated the code in the first place, and as much as we like to complain about git, it looks like a miracle by comparison.

Re: The C++ standard for the F-35 Fighter Jet [video]

#212

Post by creato »

YesBox wrote: post #204
creato wrote: post #202

Earlier quoted context omitted.

The "standard" (typically defined in projects I'm familiar with, and as of C23, an actual standard) is "unreachable": https://en.cppreference.com/w/c/program/unreachable.html

C++ keeps getting bigger and bigger :D Thanks for sharing

This is actually C and C++ has not done something similar AFAIK.

Re: The C++ standard for the F-35 Fighter Jet [video]

#213

Post by Animats »

jandrewrogers wrote: post #171
Animats wrote: post #159

Earlier quoted context omitted.

As is common in hard real time code, there is no dynamic allocation during operation: allocation/deallocation from/to the free store (heap) shall not occur after initialization. This works fine when the problem is roughly constant, as it was in, say, 2005. But what do things look like in modern AI-guided drones?

Why would the modern environment materially change this? The initialized resource allocation reflects the limitations of the hardware. That budget is what it is. I can't think of anything about "modern AI-guided drones" that would change the fundamental mechanics. Some systems support very elastic and dynamic workloads under fixed allocation constraints.

Basic flight control is a fixed-sized problem. More military aircraft systems now on what the environment and enemy are doing.

Re: The C++ standard for the F-35 Fighter Jet [video]

#214

Post by vlovich123 »

creato wrote: post #202
YesBox wrote: post #199

Earlier quoted context omitted.

Same. I go one step further and create a macro _STOP which is defined as w/e your language's DebugBreak() is. And if it's really important, _CRASH (this coerces me to fix the issue immediately)

The "standard" (typically defined in projects I'm familiar with, and as of C23, an actual standard) is "unreachable": https://en.cppreference.com/w/c/program/unreachable.html

That is not the same thing at all. Unreachable means that entire branch cannot be taken and the compiler is free to inject optimizations assuming that’s the case. It doesn’t need to crash if the violation isn’t met - indeed it probably won’t. It’s the equivalent of having something like

    x->foo();
    if (x == null) {
        Return error…;
    }
This literally caused a security vulnerability in the Linux kernel because it’s UB to dereference null (even in the kernel where engineers assumed it had well defined semantics) and it elided the null pointer check which then created a vulnerability.

I would say that using unreachable() in mission critical software is super dangerous, moreso than an allocation failing. You want to remove all potential for UB (ie safe rust with no or minimal unsafe, not sprinkling in UB as a form of documentation).

Re: The C++ standard for the F-35 Fighter Jet [video]

#216

Post by mmooss »

coderenegade wrote: post #211
mmooss wrote: post #184

Earlier quoted context omitted.

> It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0` That's a classic bias: Comparing A and B, show that B doesn't have some A flaws. If they are different systems, of course that's true. But it's also true that A doesn't have some B flaws. That is, what flaws does Autocode have that humans don't? The fantasy that machines are infallible - another (implicit) argument in this t…

What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me. The main flaw of autocode is that a human can't easily read and validate it, so you can't really use it as source code. In my experience, this is one of the biggest flaws of these types of systems. You have to version control the file for whatever proprietary graphical programming software generated the…

> What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me.

It's an interesting question and point, but those are two different things and there is no reason to think you'll get the same results. Why not compile from natural language, if that theory is true?

Re: The C++ standard for the F-35 Fighter Jet [video]

#217

Post by jasonwatkinspdx »

Animats wrote: post #213
jandrewrogers wrote: post #171

Earlier quoted context omitted.

Why would the modern environment materially change this? The initialized resource allocation reflects the limitations of the hardware. That budget is what it is. I can't think of anything about "modern AI-guided drones" that would change the fundamental mechanics. Some systems support very elastic and dynamic workloads under fixed allocation constraints.

Basic flight control is a fixed-sized problem. More military aircraft systems now on what the environment and enemy are doing.

You're just imagining things at this point.

The overwhelming majority of embedded systems are desired around a max buffer size and known worst case execution time. Attempting to balance resources dynamically in a fine grained way is almost always a mistake in these systems.

Putting the words "modern" and "drone" in your sentence doesn't change this.

Re: The C++ standard for the F-35 Fighter Jet [video]

#218

Post by vlovich123 »

csmantle wrote: post #167
Animats wrote: post #159

Earlier quoted context omitted.

As is common in hard real time code, there is no dynamic allocation during operation: allocation/deallocation from/to the free store (heap) shall not occur after initialization. This works fine when the problem is roughly constant, as it was in, say, 2005. But what do things look like in modern AI-guided drones?

"AI" comes in various flavors. It could be a expert system, a decision forest, a CNN, a Transformer, etc. In most inference scenarios the model is fixed, the input/output shapes are pre-defined and actions are prescribed. So it's not that dynamic after all.

This is also true of LLMs. I’m really not sure of OP’s point - AI (really all ML) generally is like the canonical “trivial to preallocate” problem.

Where dynamic allocation starts to be really helpful is if you want to minimize your peak RAM usage for coexistence purposes (eg you have other processes running) or want to undersize your physical RAM requirements by leveraging temporal differences between different parts of code (ie components A and B never use memory simultaneously so either A or B can reuse the same RAM). It also does simplify some algorithms and also if you’re ever dealing with variable length inputs then it can help you not have to reason about maximums at design time (provided you just correctly handle an allocations failure).

Re: The C++ standard for the F-35 Fighter Jet [video]

#219

Post by vlovich123 »

tialaramex wrote: post #177
writtiewrat wrote: post #119

Earlier quoted context omitted.

[flagged]

"No semantic effect" is one of those recurring C++ tropes like the "subset of a superset" or "trading performance for safety" that I think even its defenders ought to call bullshit on. The insistence on "No semantic effect" for attributes has poisoned them badly, and the choice to just ignore the semantic implications for Bjarne's C++ 20 Concepts makes this a poor substitute for the concepts feature as once imagined…

But what’s the relevance of all of this to bird law?

Re: The C++ standard for the F-35 Fighter Jet [video]

#220

Post by dfedbeef »

Animats wrote: post #159
jandrewrogers wrote: post #8

For those interested, the F-35 (née Joint Strike Fighter) C++ coding standards can be found here, all 142 pages of it: https://www.stroustrup.com/JSF-AV-rules.pdf

As is common in hard real time code, there is no dynamic allocation during operation: allocation/deallocation from/to the free store (heap) shall not occur after initialization. This works fine when the problem is roughly constant, as it was in, say, 2005. But what do things look like in modern AI-guided drones?

How do you think these modern AI-guided drones use their AI? What part of the drone uses it?
Post reply on HN