PLOS2021: ISO-C became unusable for operating systems • Hacker News Board

Re: PLOS2021: ISO-C became unusable for operating systems

#81

Post by mwcampbell » Thu, Oct 07, 2021, 12:49 PM UTC

pcwalton wrote: post #27

In general I've long been very skeptical of removing optimizations that rely on undefined behavior. People say "I'd happily sacrifice 1% for better theoretical semantics", but theoretical semantics don't pay the bills of compiler writers. Instead, compiler developers are employed by the largest companies, where a 1% win is massive amounts of dollars saved. Any complaint about undefined behavior in C must acknowledge…

Priorities change though; in particular, security is a rising priority. So it's not inevitable that funded compiler development must focus on wringing every last optimization out of software that might perform well enough if it were simpler. Organizations like NLnet and ISRG, for example, could fund work on getting to a usable Unix-like system that's entirely compiled with one of the simpler C compilers that don't exploit undefined behavior so much. They could justify it with the argument that security is best achieved through simplicity at all levels of the stack, including a simple build toolchain.

Re: PLOS2021: ISO-C became unusable for operating systems

#82

Post by naasking » Thu, Oct 07, 2021, 1:28 PM UTC

astrange wrote: post #26

alerighi wrote: post #23

Earlier quoted context omitted.

I don't get how the fact that the compiler can remove or modify the code was thought to be a good idea. I get removing unused functions, but not conditions and changing the flow of the code. If there is unreachable code, best to issue a warning and let the programmer fix it. The compiler should optimize without changing the semantic of the code, even if it contains undefined/unspecified behavior. To this it's impossi…

> The compiler should optimize without changing the semantic of the code, even if it contains undefined/unspecified behavior. That is what it does. "Undefined behavior" is a lack of semantics, so it is preserving semantics when it leaves those paths out. You can make a "defined C" with `-fsanitize-trap=undefined`, but C was never a high level assembler, and performance is critical for C users too.

> "Undefined behavior" is a lack of semantics, so it is preserving semantics when it leaves those paths out.

It's not preserving semantics, it's inferring a valid program from an invalid one, but since the programmer entered an invalid program, unilaterally deciding that the valid program was the intended program seems dubious at best. These should really be errors, or warnings at the very least.

Re: PLOS2021: ISO-C became unusable for operating systems

#83

Post by kjs3 » Thu, Oct 07, 2021, 4:13 PM UTC

po1nt wrote: post #4

I think it's about time to abandon C language entirely.

As long as you write compilers for all of the platforms which currently only have C language production quality compilers. That includes porting the whole development ecosystem for those platforms (like libraries) to whatever NextNewShiny language you deem worthy.

We'll wait...

Re: PLOS2021: ISO-C became unusable for operating systems

#84

Post by kjs3 » Thu, Oct 07, 2021, 4:32 PM UTC

MobiusHorizons wrote: post #22

po1nt wrote: post #4

I think it's about time to abandon C language entirely.

I'm curious what you would replace it with? I can't think of anything actually suitable for most of the low-level operating systems / embedded level things that use C. I know people recommend rust for this kind of thing, but Rust really isn't appropriate in a lot of cases, especially when dealing with microcontrollers not supported by llvm (ie PIC, 8051 off the top of my head). This may be changing, but I was also un…

As an alternative in your use case, there was a pretty decent Modula-2 compiler for the 8051 (Mod51). It's a small, safe language and a reasonable fit for embedded architectures. It is a Wirth-ian BEGIN...END language which for some people means it has cooties, but I wrote a some useful stuff in it a long time ago and it was pretty painless, as such things go. There's even some standardization around Modula-2 in the embedded world (IEC 61311-3 ST). Unfortunately, I don't think Mod51 is sold any more; C won in that world.

Re: PLOS2021: ISO-C became unusable for operating systems

#85

Post by MobiusHorizons » Thu, Oct 07, 2021, 6:24 PM UTC

kjs3 wrote: post #84

MobiusHorizons wrote: post #22

Earlier quoted context omitted.

I'm curious what you would replace it with? I can't think of anything actually suitable for most of the low-level operating systems / embedded level things that use C. I know people recommend rust for this kind of thing, but Rust really isn't appropriate in a lot of cases, especially when dealing with microcontrollers not supported by llvm (ie PIC, 8051 off the top of my head). This may be changing, but I was also un…

As an alternative in your use case, there was a pretty decent Modula-2 compiler for the 8051 (Mod51). It's a small, safe language and a reasonable fit for embedded architectures. It is a Wirth-ian BEGIN...END language which for some people means it has cooties, but I wrote a some useful stuff in it a long time ago and it was pretty painless, as such things go. There's even some standardization around Modula-2 in the…

very interesting

Re: PLOS2021: ISO-C became unusable for operating systems

#86

Post by Gibbon1 » Thu, Oct 07, 2021, 7:28 PM UTC

rini17 wrote: post #78

qsort wrote: post #77

Earlier quoted context omitted.

Why would that put C at a disadvantage performance-wise? Array decay is, with hindsight, an unfortunate feature, but optimizing access to contiguous memory is very low-hanging fruit as far as compiler optimizations go.

Some optimizations are low-hanging fruit only if you know length of the array. Which C avoids by design at all costs.

If you want better safety, runtime and compile time performance the lowest hanging fruit would be to fire the C standards committee and hard fork C++/C into C++ and C only ecosystems.

Re: PLOS2021: ISO-C became unusable for operating systems

#87

Post by pcwalton » Thu, Oct 07, 2021, 8:57 PM UTC

Asooka wrote: post #73

pcwalton wrote: post #37

Earlier quoted context omitted.

Even assuming the 5% number were correct (depending on how expansive your definition of UB is, it may not be), asking everyone who doesn't adjust their compiler flags to accept a 5% slowdown for some theoretical benefits is at odds with economic reality.

Even assuming the 5% number were correct (depending on how expansive your optimisations with UB assumptions are, it may not be), asking everyone who doesn't adjust their compiler flags to accept their programs being silently miscompiled for some theoretical benefits is at odds with economic reality.

Times like this I wish I were allowed to say exactly how much money a 1% fleet-wide loss in performance costs a big tech company.

Re: PLOS2021: ISO-C became unusable for operating systems

#88

Post by ncmncm » Thu, Oct 07, 2021, 9:09 PM UTC

jjtheblunt wrote: post #65

MobiusHorizons wrote: post #57

Earlier quoted context omitted.

How is this not correct? UB = Undefined Behavior. Or are you saying that UB is not from the C++ community? That could certainly be true, I am just describing the situation as I see it where C++ disallows more types of casting or reinterpreting than C does (even if compilers allow it). One salient example I heard was that the only way to legally read the bits of a float in C++ is to memcpy the float onto an integer ty…

In C you're free to get the address of the float (presuming it's not in a register) and cast that address to a pointer to an array of char, which doesn't copy anything, just re-decrees, from that point on, to the code generator of the compiler what assembly code is generated.

Right, I should not have said you have to memcpy. You can poke bytes any way you like, in any order you like. But! memcpy is known to compiler optimizers, so is more reliably optimized away.

Re: PLOS2021: ISO-C became unusable for operating systems

#89

Post by ncmncm » Thu, Oct 07, 2021, 9:36 PM UTC

aw1621107 wrote: post #53

ncmncm wrote: post #45

Earlier quoted context omitted.

It is quite common for any heavily inlined code to have lots of dead sections. Template code is very frequently heavily inlined. So, it is common for compilers to prune out the dead branches. But C code is often heavily inlined, too, and similarly pruned.

Guess I need to pay more attention to the template code I use. I knew that they tended to rely very heavily on inlining for good performance, but I haven't read as much about the presence/absence of dead code, though to be fair maybe the deadness isn't always obvious to the programmer? In any case, thanks for correcting me!

I should add that most of the Standard library will not often have many visibly dead code branches to prune. Most of what gets discarded is arguments and calls to no-op functions, all the scaffolding. But there is a lot of that. So, for example, an iterator on std::function isn't typically a pointer, but after optimization the instructions left standing are the same as if it was one.

Re: PLOS2021: ISO-C became unusable for operating systems

#90

Post by not2b » Thu, Oct 07, 2021, 11:22 PM UTC

vyodaiken wrote: post #56

not2b wrote: post #20

Earlier quoted context omitted.

Without these optimizations, you can't write fast scientific code in C. This was realized back in the early 1980s and it's why those rules were added. In Fortran the aliasing rules are even stricter: given two arrays passed in as arguments the compiler can assume that they do not overlap, for example. I remember messing that up as a student long ago and getting strange results. The Fortran rule was to enable vectoriz…

I doubt that very much, and one of the points of the article is that there is a shortage of data to back up claims like yours. In any case, for people who want to write OS or cryptography or embedded systems or arithmetic libraries or ... in C, this is not a relevant point.

You doubt it because you aren't a compiler developer, so you aren't aware of the history. Try taking some of the classic Fortran scientific programming libraries, such as LAPACK, recoding them in C, and then see what happens when you need to generate code with a compiler that doesn't do any of the optimizations the article complains about and has no undefined behavior. Then you'll figure out why.