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

What every compiler writer should know about programmers (2015) [pdf]

complang.tuwien.ac.at

Post reply on HN
Print view View original

71–80 of 101 posts

Re: What every compiler writer should know about programmers (2015) [pdf]

#71

Post by zbentley »

muldvarp wrote: post #53

A C compiler is a relatively simple program (especially if you don't want any optimizations based on undefined behavior). If a large part of the userbase is unhappy with the way most modern C compilers work, they could easily write a "friendly"/"boring" C compiler.

Some of those already exist, e.g. https://bellard.org/tcc/

However, they're not in widespread use. I would be curious to learn if there's any data/non-anecdotal information as to why. Is it momentum/inertia of GCC/LLVM/MSVC? Are alternative compilers incomplete and can't actually compile a lot of practical programs (belying the "relatively simple program") claim? Or is the performance differential due to optimizations really so significant that ordinary programs like e.g. vim or libjpeg or VLC or whatnot have significant degradations when built on an alternative compiler?

Re: What every compiler writer should know about programmers (2015) [pdf]

#72

Post by dotancohen »

uecker wrote: post #34
dotancohen wrote: post #18

Earlier quoted context omitted.

Have you seen Rust? I'm loving it.

Rust is not super appealing to me as C user: too complex, slow compilation, etc.

You are correct about the complexity. I write it with significant assistance from an LLM. Not quite vibe coding, but close. But I'm coming from Python, not C.

Re: What every compiler writer should know about programmers (2015) [pdf]

#73

Post by duped »

muldvarp wrote: post #57
duped wrote: post #43

Earlier quoted context omitted.

If dead code (1) is common in your codebase then your code base is missing heaps of refactors (1) "dead" meaning unused types, unreachable branches

Not really, no. If you use a regex library it is very likely that 80% of that code is effectively dead code.

public interfaces are not dead code

Re: What every compiler writer should know about programmers (2015) [pdf]

#74

Post by HexDecOctBin »

zbentley wrote: post #69
Joker_vD wrote: post #47

Earlier quoted context omitted.

The proposals for Boring C or "Friendly Dialect of C" or whatever has been around for a while. None went beyond the early design stages because, it turns out, no two experienced C programmers could agree on what parts of C are reasonable/unreasonable (and should be kept/left out), see [0] for the first-hand recount. [0] https://blog.regehr.org/archives/1287 > In contrast, we want old code to just keep working, with l…

I can't upvote this enough. I mostly work in compiled languages now, but started in interpreted/runtime languages. When I made that switch, it was baffling to me that the compiled-language folks don't do compatibility-breaking changes more often during big language/compiler revision updates. Compiled code isn't like runtime code--you can build it (in many cases bit-deterministically!) on any compiler version and it s…

There are C codebases many decades old still being actively maintained and used. I don't think the same is true for Python on the same scale. It's easy to remodel when you are on the top of abstraction layer, but you don't want to mess around with the foundational infrastructure unnecessarily.

Re: What every compiler writer should know about programmers (2015) [pdf]

#75

Post by rurban »

BeeOnRope wrote: post #23
somat wrote: post #20

Earlier quoted context omitted.

That's the problem

Why is that a problem? Inlining and optimization aren't minor aspects of compiling to native code, they are responsible for order-of-magnitude speedups. My point is that it is easy to say "don't remove my code" while looking at a simple single-function example, but in actual compilation huge portions of a function are "dead" after inlining, constant propagation and other optimizations: not talking anything about C-sp…

Removing unused inlined functions or false constexpr's is trivial to see. We already have -Winline. We care about removed branches, exprs and stmts due to some optimizer logic.

I'm talking about the optimizer, not the linker, which thanksfully does a lot of pruning.

Re: What every compiler writer should know about programmers (2015) [pdf]

#76

Post by xscott »

torben-friis wrote: post #67
Doxin wrote: post #46

Earlier quoted context omitted.

No, because the former definition is still something you can rely on given a specific compiler and a specific machine. Hell a bunch of UB was pretty much universal anyway. Compilers would usually still emit sensible code for UB. UB just ment "the spec doesn't define what happens". It didn't use to mean "the compiler can just decide to do any wild thing if your program touches UB anywhere at anytime". Hell, with the m…

>the former definition is still something you can rely on given a specific compiler and a specific machine. >UB just ment "the spec doesn't define what happens" What comes to mind is that then the written code is operating on a subspec, one that is probably undocumented and maybe even unintended by the specifics of that version and platform. It sounds like it could create a ton of issues, from code that can’t be port…

Very simple code is UB:

    int handle_untrusted_numbers(int a, int b) {
        if (a
Every computer you will ever use has two's complement for signed integers, and the standard recently recognized and codified this fact. However, the UB fanatics (heretics) insisted that not allowing signed overflow is an important opportunity for optimizations, so that last if-statement can be deleted by the compiler and your code quietly doesn't check for overflow any more.

There are plenty more examples, but I think this is one of the simplest.

Re: What every compiler writer should know about programmers (2015) [pdf]

#77

Post by zbentley »

HexDecOctBin wrote: post #74
zbentley wrote: post #69

Earlier quoted context omitted.

I can't upvote this enough. I mostly work in compiled languages now, but started in interpreted/runtime languages. When I made that switch, it was baffling to me that the compiled-language folks don't do compatibility-breaking changes more often during big language/compiler revision updates. Compiled code isn't like runtime code--you can build it (in many cases bit-deterministically!) on any compiler version and it s…

There are C codebases many decades old still being actively maintained and used. I don't think the same is true for Python on the same scale. It's easy to remodel when you are on the top of abstraction layer, but you don't want to mess around with the foundational infrastructure unnecessarily.

Absolutely. But there’s so much more liberty in C land in that you can stay on an old compiler/language version for such codebases.

I know it’s not pleasant per se, but the level of support needed (easier now with docker and better toolchain version management utils than were the norm previously) surely doesn’t merit compilers carrying around the volume of legacy cruft and breaking-change aversion they do, no?

Re: What every compiler writer should know about programmers (2015) [pdf]

#78

Post by Panzerschrek »

uecker wrote: post #34
dotancohen wrote: post #18

Earlier quoted context omitted.

Have you seen Rust? I'm loving it.

Rust is not super appealing to me as C user: too complex, slow compilation, etc.

Slow compilation and complexity isn't an issue. It's a price for much better result code quality and elimination of many errors.

Re: What every compiler writer should know about programmers (2015) [pdf]

#79

Post by Panzerschrek »

uecker wrote: post #35
Panzerschrek wrote: post #9

Making C compilers better and more predictable is impossible with so many UB cases listed in the standard. A better language should be used instead, where UB and implementation-defined behavior cases are minimized.

Where there is UB in the standard it means that a C compiler is free to define the behavior. So of course, somebody could write a C implementation which does this. See also Fil-C for a perfectly memory safe version of C. So the first sentence makes no sense. But also note that there is an ongoing effort to remove UB from the standard. We have eliminated already about 30% of UB in the core language for the upcoming ve…

C is designed in such a way, that designing a safe compiler without big performance penalties isn't possible. How much Fil-C is slower compared to something like GCC? 2 to 5 times slower?

Re: What every compiler writer should know about programmers (2015) [pdf]

#80

Post by Panzerschrek »

mfru wrote: post #40
uecker wrote: post #34

Earlier quoted context omitted.

Rust is not super appealing to me as C user: too complex, slow compilation, etc.

Maybe Zig, Hare or C3 then?

Zig isn't a language I mean. It's still full of footguns. It doesn't address fundamental reliability issues of C.
Post reply on HN