Live data from Hacker News

C Is Not a Low-Level Language

queue.acm.org

191–200 of 326 posts

Re: C Is Not a Low-Level Language

#191
post #65

Earlier quoted context omitted.

I'm not an expert, but I don't think the optimization phase should be really considered here: the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. NASM for instance offer some level of optimizations, so I think optimization should only be considered when it's part of the language specification itself, like in Scheme. IMO C is close to lo…

> the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. Some of the simpler optimizations, sure. But modern backends do many incredibly sophisticated optimizations that are way beyond any kind of simple pattern-matching-and-substitution model. Even fundamental "optimizations" like register allocation use quite sophisticated algorithms. Op…

It would be interesting to revisit a world where languages/compilers were built explicitly with common memory access semantics/out of order op/etc in mind.

One of the things that really excites me about Rust is that it's single mutable reference enforcement means you can run run `restrict` 100% of the time if you wanted which is a non-trivial performance boost. I think it's not enabled today but from previous discussions it sounds like that's just a matter of plumbing through the right things to LLVM.

Every time I've seen that rolled out in a C/C++ codebase someone invariably forgets about pointer aliasing and you spend a week tracking down some non-deterministic behavior.

Re: C Is Not a Low-Level Language

#192
post #65
post #14

Earlier quoted context omitted.

I also had the initial impression that the article is misleading, but later on the author made the point that the C compiler is doing significant work to reorder / parallelize / optimize the code. I agree that x86/x64 is not a low-level language either, but even if it was, with the description the author provided, I'd agree with his point of C not being low-level. Regarding cutting off backwards compatibility to impr…

I'm not an expert, but I don't think the optimization phase should be really considered here: the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. NASM for instance offer some level of optimizations, so I think optimization should only be considered when it's part of the language specification itself, like in Scheme. IMO C is close to lo…

"the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler"

Transmeta's x86 CPU's were even doing translations and optimizations dynamically between x86 and their internal representations.

Re: C Is Not a Low-Level Language

#193
post #171

Earlier quoted context omitted.

unsigned char r(unsigned char num) { return num % 10; } https://godbolt.org/g/26HfQk

Or compile this with clang and -msse4.2 -O2 // https://codereview.stackexchange.com/questions/38182 // https://codereview.stackexchange.com/a/38184 // Definition: Count number of 1's and 0's from integer with bitwise operation // 2^32 = 4,294,967,296 // unsigned int 32 bit #include int CountOnesFromInteger(unsigned int); int main() { unsigned int inputValue; short unsigned int onesOfValue; printf("Please Enter value…

I've seen this and others, but they're brittle. Terminating that count loop for any other reason, for example, will break it.

There's another one for reversing bytes in an integer, but I ended up hard-coding the intrinsic due to brittleness.

Re: C Is Not a Low-Level Language

#194
post #65

Earlier quoted context omitted.

I'm not an expert, but I don't think the optimization phase should be really considered here: the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. NASM for instance offer some level of optimizations, so I think optimization should only be considered when it's part of the language specification itself, like in Scheme. IMO C is close to lo…

> the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. Some of the simpler optimizations, sure. But modern backends do many incredibly sophisticated optimizations that are way beyond any kind of simple pattern-matching-and-substitution model. Even fundamental "optimizations" like register allocation use quite sophisticated algorithms. Op…

My point was that since optimization is also possible in assembly, and since assembly is considered low-level, then optimization per se shouldn't be used as something that characterize high-level languages exclusively. But it is true that some abstractions used by high-level languages enable quite complex optimization techniques, so there is a clear correlation between the level of a language and the ability of its compiler to analyze and optimize programs.

Re: C Is Not a Low-Level Language

#195

I really really liked this article, and reading the comments here is blowing my mind. Did we read the same thing? I think it's a strong insight that insight that chip designers and compiler vendors have spent person-millenia maintaining the illusion that we are targeting a PDP-11-like platform even while the platform has grown less and less like that. And, it turns out, with things like Spectre and the performance co…

It seems like the article is mostly useful for inspiring research; that is, most of us aren't the target audience. I'm wondering what will happen as GPU's become more general-purpose. What's next after machine learning? Would it be possible to make a machine where all code runs on a GPU? How would GPU's have to change to make that possible, and would it result in losing what makes them so useful? What would the OS an…

I think it is going the opposite direction, where cpus get more powerful graphics cards integrated more and more into them. This allows for matrix math to become a bit more standard in day to day programming.

However, in the opposite direction where a gpu becomes more like a cpu, if streams could do some level of limited branching without slowing the whole thing down, it opens the door to threading frameworks and design patterns where you write a loop in code, every thread gets it's own copy of memory, and on the threading front, it just kind of works for a lot of generic code.

Then if gpus added some sort of piped-like summation-like instruction, in the cases in a loop where variables need to be shared, they can still be added, subbed, mul, div, or mod, easily and quickly, allowing for what looks and acts like normal code today, but is actually threaded. That would kind of bring code back to where it is today.

Who knows? It's kind of fun to speculate about though.

Re: C Is Not a Low-Level Language

#197
post #65
post #14

Earlier quoted context omitted.

I also had the initial impression that the article is misleading, but later on the author made the point that the C compiler is doing significant work to reorder / parallelize / optimize the code. I agree that x86/x64 is not a low-level language either, but even if it was, with the description the author provided, I'd agree with his point of C not being low-level. Regarding cutting off backwards compatibility to impr…

I'm not an expert, but I don't think the optimization phase should be really considered here: the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. NASM for instance offer some level of optimizations, so I think optimization should only be considered when it's part of the language specification itself, like in Scheme. IMO C is close to lo…

C cannot read the overflow bit after an ADD, because of it's abstractions ... so I would say modern ASM is still lower in some aspects because it has less constrains and more importantly, it is less expressive, which is the whole idea of this hierarchy.

The compiler should offer a macro for that. Then the question is whether to take the specification or the implementation at which point it's an absurd question to begin with. You could compare -O0 binaries, bypassing the optimization question, too.

High/low is not fine grained enough. IIRC, prolog for example would be dubbed a fifth generation language, after assembler, goto hell macro compilers, structured functional programming, and DSLs. Now coq and the like seem to be of yet a higher order (pun intended, sorry).

Re: C Is Not a Low-Level Language

#198
Ah yes, David Chisnall. Another Cambridge wannabe without a hope of tenure track who thinks he is cleverer than he really is and makes a bunch of trite points over and over hoping to get some attention -- not realising they've been made for over 20 years. Have an original thought David, and stop feeling smug. You're not.

Re: C Is Not a Low-Level Language

#199
post #139

Earlier quoted context omitted.

Hmm, what does "virtual machine" mean if the "virtual machine" is implemented in hardware? And, is nothing but actual binary machine code a "low level language"? I guess it's the lowest, I don't _think_ you can go lower than that... but someone's probably gonna tell me I'm wrong.

VHDL / Verilog is lower level! In all seriousness, the "assembly is high level" argument is ridiculous and robs the "low level" vs "high level" categorization of all meaning.

Perhaps C is a "medium-level language"? :)

Re: C Is Not a Low-Level Language

#200
post #65

Earlier quoted context omitted.

I'm not an expert, but I don't think the optimization phase should be really considered here: the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. NASM for instance offer some level of optimizations, so I think optimization should only be considered when it's part of the language specification itself, like in Scheme. IMO C is close to lo…

> the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. Some of the simpler optimizations, sure. But modern backends do many incredibly sophisticated optimizations that are way beyond any kind of simple pattern-matching-and-substitution model. Even fundamental "optimizations" like register allocation use quite sophisticated algorithms. Op…

The K-graph coloring problem for register allocation is NP-complete, but in SSA form is actually linear. The tougher problem isn't the coloring but rather where to optimally place spills and fills around loops and calls.

https://llvm.org/devmtg/2011-11/Olesen_RegisterAllocation.pd...

Post reply on HN