Squeezing More Juice Out Of Gentoo With Graphite, LTO Optimizations

[duby229]

Are you talking about the difficulty to avoid plain bugs such as array access out of range, or is there some area in the language definition that you think is problematic to follow?

That's such a loaded question, I'm not sure how to answer it. There are answers for it though. A few. It's not type safe. It's really hard to data orient. It's really hard to multithread. Arrays are a real nightmare. There are just so many places and reason undefined behavior can pop up. It's hard to list them all...

My advice is to use a fuzzer on the most stable code you know of, you'll still find undefined behavior.

[In_Between_Names]

That's such a loaded question, I'm not sure how to answer it. There are answers for it though. A few. It's not type safe. It's really hard to data orient. It's really hard to multithread. Arrays are a real nightmare. There are just so many places and reason undefined behavior can pop up. It's hard to list them all...

My advice is to use a fuzzer on the most stable code you know of, you'll still find undefined behavior.

Which language are you talking about here? In C++11 and especially onwards, we have things like happens-before to establish data dependencies across thread boundaries, we've got many useful alignment tools, we have nice STL interfaces for arrays, etc. I know a number of these concepts are available in C11 as well. Avoiding UB is hard, but it certainly used to be a lot harder. Let's not forget that hardware itself often exhibits it's own forms of UB, too.

[indepe]

....
My advice is to use a fuzzer on the most stable code you know of, you'll still find undefined behavior.

Speaking generally, I like to use lots of asserts in performance-insensitive places, and debug-only asserts in performance-relevant places. (In addition to debugging tools and static analyzers).

Since you mention arrays: For arrays in C, in many cases where performance is not super-critical, simple libraries can use such asserts within inline access functions (which the compiler can then optimize), and store the dynamic size with the array, for bounds checks. That makes it possible, for example, to mix code that uses runtime checks in general, yet optimized access within inner loops (with explicit checks outside the loop as needed).

However what you write here sounds like you might prefer a higher-level language with hidden built-in runtime checks.