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

The Problem with Friendly C

blog.regehr.org

Post reply on HN
Print view View original

121–130 of 174 posts

Re: The Problem with Friendly C

#121

Post by scott_s »

Peaker wrote: post #98
jerf wrote: post #27

Tone: I do not mean this as sarcasm or merely chasing fashion, I'm quite serious. As both theory and practice are showing, you're never going to be able to get the consensus you want out of C. There's no "saving" C... not because that's somehow mathematically impossible, but simply because the project is too staggeringly large for us to even wrap our heads around. It would literally be easier to get people to start u…

I love the ideas behind Rust. I don't think it can replace C for all use-cases. C has the use-case of zero-dynamic-allocations. AFAIK, Rust is not very compatible with that mode of use.

As far as I know, C and Rust give you the same opportunities to work with stack-allocated values.

Re: The Problem with Friendly C

#122

Post by catnaroek »

Peaker wrote: post #98
jerf wrote: post #27

Tone: I do not mean this as sarcasm or merely chasing fashion, I'm quite serious. As both theory and practice are showing, you're never going to be able to get the consensus you want out of C. There's no "saving" C... not because that's somehow mathematically impossible, but simply because the project is too staggeringly large for us to even wrap our heads around. It would literally be easier to get people to start u…

I love the ideas behind Rust. I don't think it can replace C for all use-cases. C has the use-case of zero-dynamic-allocations. AFAIK, Rust is not very compatible with that mode of use.

Huh? If you don't want any dynamic allocation (or any other features that require support from a runtime system), you can use `#![no_std]` and instead use `libcore` directly. This is how the standard library itself is implemented.

Re: The Problem with Friendly C

#123

Post by marcosdumay »

ryandrake wrote: post #91

I must be missing something here, but can't you simply not invoke undefined behavior in your program? That way, you don't have to worry about what your compiler will do when it encounters undefined behavior.

That's possible.

It requires extreme care (assuring no memeory leaks is comparably a walk in the park), and will make your code much less performant. But it's possible.

Re: The Problem with Friendly C

#125

Post by overgard »

marcosdumay wrote: post #118
overgard wrote: post #37

Earlier quoted context omitted.

> What sort of optimisations exactly, and just how significant are they? Well, if you could remove one instruction per loop on most computers (especially conditionals that could cause a branch mis-prediction), the effect of that in terms of performance is pretty staggering. Instead of thinking of it as an optimization, think of it as a check that doesn't need to be inserted into the code. If you can tell the compiler…

> but if safety is your priority you should probably look at things other than C And those things are? C is the low level language we have. Now compiler writers decided it'll work like a high level language, except for all the actual benefits. We'll probably get usable C compilers that work (in fact, this already started), and some stuff only good for old code.

Rust or Go are possible alternatives, or Java if it doesn't need to be system level.

Re: The Problem with Friendly C

#126

Post by pcwalton »

lmm wrote: post #102
pcwalton wrote: post #56

Earlier quoted context omitted.

> I don't believe C should be a language where the compiler does all sorts of high-level optimisation; it should be a straightforward "do what I say" type of language where you get almost exactly what you write, and the only optimisations should be at the level of things like instruction selection --- the optimisations that a programmer would not be able to do at the source level. In that case, you're asking for easi…

> You can get essentially this by turning on -O0 and compiling, say, Firefox. This is done in debugging, and it's a terrible browsing experience. Which says more about Firefox than it does about -O0. I've run Seamonkey on 3x-5x slower machines than I use these days and it's been fine.

Gecko is what mostly benefits from the optimizations, and Gecko is the largest component shared between SeaMonkey and Firefox. I don't believe SeaMonkey at -O0 is an acceptable experience.

Re: The Problem with Friendly C

#127

Post by pcwalton »

cwzwarich wrote: post #88
pcwalton wrote: post #83

Earlier quoted context omitted.

> On strict aliasing, I'm against it without explicit opt-in over a delimited subset of source code. I understand that using & is going to harm the performance of my code; I think that's an acceptable tradeoff for more predictable behaviour. I believe that you and others think that's an acceptable tradeoff. At the end of the day, though, most people want C compilers to produce the fastest code possible. Compiler auth…

I'm not sure that's the best example. In that case, the knowledge that the 'array' global never has its address taken allows you to perform the optimization. You can also rewrite it by copying 'array' to a separate local that doesn't have its address taken, and ordinary SSA construction solves the problem. I feel like a new systems language needs to come and make aliasing explicit in a way, so that it doesn't surpris…

> I feel like a new systems language needs to come and make aliasing explicit in a way, so that it doesn't surprise programmers but still allows them to get the optimizations that they want. Tracking uniqueness like Rust is a good first step, but it doesn't work for unsafe code or anything with more subtle aliasing relationships.

I think it could be added to Rust. :)

Uniqueness can be viewed as just a starting point. It's a conservative subset of more sophisticated systems like PALE. Since it's a subset, it could be expanded to the full system eventually.

I think the biggest problem is not implementing it or finding a way to slot it into the language design but rather making it easy enough to use to achieve widespread adoption. Rust already stretches the boundaries of programmers' willingness to learn new type systems/static analyses to control aliasing, and it has, as you point out, a very simple system. In fact, I think it's unproven that programmers will be willing to adopt such a system en masse at all†, since Rust is still niche. If and when Rust really takes off in widespread production, we'll have proof that programmers are willing to adopt aliasing information in the type system.

† It'll be interesting to see how the ISO Core C++ lifetime checker fares here. I'm not optimistic about how much use it will get due to complexity and effectively being a different language from C++, but I'd love to be proven wrong.

Re: The Problem with Friendly C

#128

Post by Senji »

overgard wrote: post #125
marcosdumay wrote: post #118

Earlier quoted context omitted.

> but if safety is your priority you should probably look at things other than C And those things are? C is the low level language we have. Now compiler writers decided it'll work like a high level language, except for all the actual benefits. We'll probably get usable C compilers that work (in fact, this already started), and some stuff only good for old code.

Rust or Go are possible alternatives, or Java if it doesn't need to be system level.

Java for performance critical or realtime things sounds like a feverish dreamed nightmare.

Re: The Problem with Friendly C

#129

Post by anp »

chubot wrote: post #70
jerf wrote: post #27

Tone: I do not mean this as sarcasm or merely chasing fashion, I'm quite serious. As both theory and practice are showing, you're never going to be able to get the consensus you want out of C. There's no "saving" C... not because that's somehow mathematically impossible, but simply because the project is too staggeringly large for us to even wrap our heads around. It would literally be easier to get people to start u…

I'll take the bet that in 2035 it's still going to be C/C++ (or a C derivative like Boring C). Because rewriting all that code is an economic impossibility. There's a very long way to go before the rate of foundational Rust code written exceeds the rate of foundational C/C++ code written. And even if you manage to have 100% Rust and 0% C/C++ code being written, you still have a huge legacy to write, which literally c…

I haven't used it yet, but apparently Rust's FFI with C (in both directions) is quite good:

https://doc.rust-lang.org/book/ffi.html

Re: The Problem with Friendly C

#130

Post by sharpneli »

rswier wrote: post #110
rwmj wrote: post #106

Earlier quoted context omitted.

Hardware doesn't work like this. You might want to read Hennessy and Patterson, and the original RISC I paper. http://www.amazon.com/Computer-Architecture-Fifth-Edition-Qu... http://www.cecs.pdx.edu/~alaa/ece587/papers/patterson_isca_1...

RISC created a huge local minimum by speeding up C code to the exclusion of other languages. I predict that eventually future processors will hide more features from the higher software levels (such as number of registers, instruction types and formats) in order to improve efficiency at the machine level. I think we are seeing this trend with GPUs already. Current CPUs don't do this because they have to maintain bina…

GPU's don't do any OoO processing like modern CPU's do. They also don't do any register renaming. They execute things really literally, up to the point where one has to manually put delay slots for pipelined stuff if one really writes the raw asm (Which the manufacturers tend to keep really hidden, in order to avoid the binary compatibility trap, see https://github.com/NervanaSystems/maxas as an example for third party assembler for nvidia Maxwell arch)

On GPU's the binary compatibility issue is solved by having the driver compile the shader/compute kernel before it's used. As an example nvidia uses PTX (see http://docs.nvidia.com/cuda/parallel-thread-execution/) as an intermediate language in CUDA which is then compiled by the runtime into the actual ASM.

On modern CPU's the register renaming has already decoupled the physical registers from the instruction set register. As an example modern haswell has over 100 registers per core.

Post reply on HN