Live data from Hacker News

C Is Not a Low-Level Language

queue.acm.org

231–240 of 326 posts

Re: C Is Not a Low-Level Language

#231

There is an entire junkyard full of processors designed to run other languages well. LISP machines in the 60s, Java machines in the 90s, many others. For whatever reason, successful general purpose silicon has almost always followed a C-ish model. It's also worth noting that Fortran runs quite well on C-ish style processors.

Exactly. While CPU designers c will certainly make sure they can run C code fast, it turns out that, for the last 40 years at least, the C model (sequential, procedural, mostly flat address space) is the most efficient to implement in hardware.

Re: C Is Not a Low-Level Language

#232
post #141

Earlier quoted context omitted.

This argument has been made since the introduction of the JVM in the early mid-90's. Seems to me like if, in practice, JIT provided better performance then by now people would be rewriting their C/C++ code in Java and C# for speed.

> Seems to me like if, in practice, JIT provided better performance then by now people would be rewriting their C/C++ code in Java and C# for speed. It's a little bit faster, not faster by enough to matter. If you're going to rewrite C/C++ code for speed you'd go to Fortran or assembler, and even then you're unlikely to get enough of a speedup to be worth a rewrite. New projects do use Java or C# rather than C/C++ th…

Nah, nobody in their right mind would use Java/C# over C/C++ for performance...

http://blog.metaobject.com/2015/10/jitterdammerung.html?m=1

Re: C Is Not a Low-Level Language

#233

Earlier quoted context omitted.

> the C compiler You mean C compiler X has the feature of Y. There are lots of compilers and that's not part of the language.

Their comment makes sense if you interpret "the C compiler" to mean "mainstream C compilers that 99% people use in production" or even just "gcc and clang". We're talking about concrete things in the real world here, not philosophizing about the language spec.

And yet small device C and Gcc/clang are onky kissing cousins and we (well people that aren't me: ustedes) still rhetorically lump them together as a single language.

Re: C Is Not a Low-Level Language

#234

"processors wishing to keep their execution units busy running C code" What? This is non sense, the processor is not running C code! The processor can only run machine code, regardless of the language used to write the source code.

Eh, the past thirty years has had CPUs designed to run C. That's the whole point of RISC: the idea of 'let's just pare down the CPU to what actually gets compiled, and now we have less gates in the critical path and we can run our chips faster'.

Re: C Is Not a Low-Level Language

#235
post #14

This article makes some valid points but is overall rather misleading I think. Almost all of the reasons given why C is "not a low-level language" also apply to x86/x64 assembly. Register renaming, cache hierarchies, out of order and speculative execution etc are not visible at the assembly / machine code level either on Intel or other mainstream CPU architectures like ARM or Power PC. If C is not a low level languag…

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 think people often overestimate how smart the compiler is. DJB had a slide deck about this: http://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf Compilers are really useful... but, if it really has to be fast, you still need to have a human in the loop.

I was also under the impression that there hasn't been much improvement in compiling C/C++ in a long time. It would be interesting to compare the performance of gcc from 15 years ago versus gcc today, on a real world piece of code. I suspect you wouldn't see much difference (aside from the changes in C dialect over time), and some added features in the new version. Has anyone run this experiment?

Re: C Is Not a Low-Level Language

#236

Ok, w/o dipping into machine code, show me a low level language. Any snippet of C-code is transparent in that you know roughly how it is going to be translated into machine code.

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

Yes. this is doing to infamous division by 10 using bit shifts as you will find in hacker's delight: http://www.hackersdelight.org/divcMore.pdf.

You may notice that when you divide num by 10 you get a quotient q and a remainder r:

    num = q*10 + r
Once you get q, you can solve for r as

    r = num - q*10
So this is how you get r and q:

    q = (num >> 1) + (num >> 2);
    q = q + (q >> 4);
    q = q + (q >> 8);
    q = q + (q >> 16);
    q = q >> 3;
    r = num - q*10;
    q = q + ((r + 6) >> 4)    
voila!

Re: C Is Not a Low-Level Language

#237

Ok, w/o dipping into machine code, show me a low level language. Any snippet of C-code is transparent in that you know roughly how it is going to be translated into machine code.

> Any snippet of C-code is transparent in that you know roughly how it is going to be translated into machine code. This isn't really true on a modern optimizing compiler.

You still have a good idea of what can get inlined, where loop unrolling can occurs, constant folding, etc.... if you have any assembly experience you still have a good idea of what machine could can be generated.

Re: C Is Not a Low-Level Language

#238
post #209

Earlier quoted context omitted.

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…

> It seems like the article is mostly useful for inspiring research; that is, most of us aren't the target audience. As a group of professionals, it is highly beneficial for us to be interested in these things. People who design languages and compilers do it largely on what is perceived as being demanded, and us as programmers are the ones that create the demand for new languages . To put in other words, if programme…

I still think a research project (either academic or in industry) with a hardware component would be the best way to explore radical new processor architectures that are further away from C.

- Hardware designers are conservative. They aren't likely to implement a different hardware architecture because "programmers demand it" (really?), unless there's existing research showing how it can be done and a compelling reason why customers will buy the chips.

- As a hobbyist language designer, I'm still going to target something that exists and is popular: x86, JavaScript, wasm, C, or something like that. A low-level language targeting a platform that doesn't exist isn't all that appealing. But, someone might get some good papers out of doing the research.

Re: C Is Not a Low-Level Language

#239

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…

> cost of cache misses How is the C memory model a leaky abstraction here? What better way do you suggest? Are we not fine coding sequential (in memory) datastructures in C?

How about a different example entirely? Memory nowadays is either CPU (and the GPU can access it) or GPU (and the CPU has a window into it). It's terribly important to use the right one: if a chunk of memory is mostly used by the CPU, it needs to be CPU memory, and if it's mostly used by the GPU, it needs to be GPU memory. But there's no good way to specify that.

You might argue that a modern computer is more like programming a tightly-bound, nonuniform multi-processor system. And I'd agree. But C doesn't much to help program such a thing.

Re: C Is Not a Low-Level Language

#240
I enjoyed reading this, mostly because it made me angry, then curious, then thoughtful all in one go.

Partly because I really like the PDP-11 architecture, and it's 'separated at birth' twin the 68K, it greatly influenced me in how I think about computation. I also believe that one of the reasons that the ATMega series of 8 bit micros were so popular was that they were more amenable to a C code generator than either the 8051 or PIC architectures were.

That said, computer languages are similar to spoken languages in that a concept you want to convey can be made more easily or less easily understood by the target by the nature of the vocabulary and structure available to you.

Many useful systems abstractions, queues, processes, memory maps, and schedulers are pretty easy to express in C, complex string manipulation, not so much.

What has endeared C to its early users was that it was a 'low constraint' language, much like perl, it historically has had a fairly loose policy about rules in order to allow for a wider variety of expression. I don't know if that makes it 'low' but it certainly helped it be versatile.

Post reply on HN