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

PLOS2021: ISO-C became unusable for operating systems

yodaiken.com

Post reply on HN
Print view View original

91–100 of 100 posts

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

#91

Post by not2b »

Gibbon1 wrote: post #64
vyodaiken wrote: post #56

Earlier quoted context omitted.

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.

My understanding is the reason FORTRAN is faster than C isn't because of stupid stuff like noalias and the like. It's because FORTRAN has arrays and C doesn't.

You're right, sort of. Because C doesn't have proper arrays, you make up for it by passing a pointer to the first element and the range. So for C to do as well as Fortran on matrix operations the compiler developers need help. One source of help is that if you have a pointer to double and a pointer to int, you can assume that writing pdouble[k] doesn't alter anything reachable as pint[m].

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

#92

Post by vyodaiken »

bsder wrote: post #52
Asooka wrote: post #7

Earlier quoted context omitted.

Sometimes I do wonder if all these UB optimisations aren't pushed by people aiming to make C and C++ unusable, so that people will be forced to move to other languages.

That's a touch unfair. The problem is that C is sufficiently primitive that optimizing it is effectively trying infer structure backwards because the language doesn't specify it. For-loops are a great example. Why are we even discussing about a "loop index"? Because we need to iterate over an array, string, etc. and "length" isn't something stored with the data structure so the compiler can't do the loop for you. The…

Your argument would be more compelling if programming languages with higher level iteration primitives were significantly more optimizable than C. The underlying processor architectures have loop indexes. Just pretending you can do applicative programming doesn't mean you can. C is very adaptable - even to GPUs. Also, I have yet to see that decent memory model.

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

#93

Post by not2b »

ncmncm wrote: post #42
not2b wrote: post #28

Earlier quoted context omitted.

I think it's the opposite: compiler writers under pressure to produce fast code assume that the programmers are smart, not morons, and that they understand the rather complex rules. For example: the compiler is assuming someone isn't ignorant and knows, for example, if they want to write a variable as one type and read it as another, they need to consider two things: they are now in implementation-dependent territory…

Amusingly, unions are also defined so that operations that pun types are undefined. Gcc has private extensions that provide a way to pun types in unions, but those are not portable. Specifically: if you have a union with members a and b, and you assign into member a, then reading from member b afterward is, by the C and C++ Standards, usually undefined. You are presumed to have some way to know that member a is live,…

The C99 and C11 standards say that the behavior is unspecified (in standard-ese, "unspecified" and "undefined" are different), meaning that the standard doesn't say what you get. Of course that's true: the result is different on a big-endian and a little-endian machine. Packing the bytes of a double might generate a signalling NaN so you get a trap when you read it, or not, and the standards don't require that floating point representations match the IEEE standard, either.

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

#94

Post by vyodaiken »

not2b wrote: post #91
Gibbon1 wrote: post #64

Earlier quoted context omitted.

My understanding is the reason FORTRAN is faster than C isn't because of stupid stuff like noalias and the like. It's because FORTRAN has arrays and C doesn't.

You're right, sort of. Because C doesn't have proper arrays, you make up for it by passing a pointer to the first element and the range. So for C to do as well as Fortran on matrix operations the compiler developers need help. One source of help is that if you have a pointer to double and a pointer to int, you can assume that writing pdouble[k] doesn't alter anything reachable as pint[m].

It's because C has pointers and FORTRAN doesn't and pointers are a pain for certain types of optimization.

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

#95

Post by vyodaiken »

not2b wrote: post #90
vyodaiken wrote: post #56

Earlier quoted context omitted.

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.

You still don't have any data.

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

#96

Post by vyodaiken »

pcwalton wrote: post #87
Asooka wrote: post #73

Earlier quoted context omitted.

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.

A) there is no evidence such phenomena - especially in net- are due to unsafe optimizations, b) those companies dont need to shift their costs to other users

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

#97

Post by plq »

astrange wrote: post #54
pcwalton wrote: post #44

Earlier quoted context omitted.

The optimization I'm referring to is widening a 32-bit loop IV to 64-bit so it can stay in a register: https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759... size_t obviates the need for this optimization.

That's a strange example since it doesn't prove their point. "int count; … for (int i = 0; i "int count; … for (int i = 0; i I don't think "have a 64-bit int type" is the right approach for a new language either… we should be aiming for safety. If a variable's valid values are 0-50 then its type should be "integer between 0 and 50", not "integer between 0 and UINT64_MAX". Storage size should be an implementation deta…

ADA has this exact functionality: https://www.adaic.org/resources/add_content/standards/05aarm...

Look for the "range" keyword

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

#98

Post by ncmncm »

ncmncm wrote: post #89
aw1621107 wrote: post #53

Earlier quoted context omitted.

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.

Oops: s/std::function/std::vector/

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

#99

Post by throwaway19937 »

vyodaiken wrote: post #95
not2b wrote: post #90

Earlier quoted context omitted.

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.

You still don't have any data.

You're the one arguing for a change to the status quo, the burden of proof is on you.

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

#100

Post by SubjectToChange »

vyodaiken wrote: post #92
bsder wrote: post #52

Earlier quoted context omitted.

That's a touch unfair. The problem is that C is sufficiently primitive that optimizing it is effectively trying infer structure backwards because the language doesn't specify it. For-loops are a great example. Why are we even discussing about a "loop index"? Because we need to iterate over an array, string, etc. and "length" isn't something stored with the data structure so the compiler can't do the loop for you. The…

Your argument would be more compelling if programming languages with higher level iteration primitives were significantly more optimizable than C. The underlying processor architectures have loop indexes. Just pretending you can do applicative programming doesn't mean you can. C is very adaptable - even to GPUs. Also, I have yet to see that decent memory model.

> C is very adaptable - even to GPUs.

Can you expand on this? I've never heard of someone seriously running actual C on a GPU.

Post reply on HN