Live data from Hacker News

C Is Not a Low-Level Language

queue.acm.org

181–190 of 326 posts

Re: C Is Not a Low-Level Language

#181

Earlier quoted context omitted.

> 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?

C leads you to believe that memory access has uniform cost regardless of address. What is the perf cost of: *foo Depending on what foo points to, and which memory you have previously read, the cost can vary by close to two orders of magnitude on many chips. C does give you the ability to control those costs, but controlling how you lay out your data in memory and controlling imperatively in which order you access it.…

> But the language doesn't show you those costs in any way.

I think it's pretty clear. Access memory sequentially, and you can expect to hit the cache. Access more memory than the cache size in a random order, and you can expect to pay memory access latencies (100s of CPU cycles).

I doubt you would be willing to manage the cache yourself in every line of code. That would be a lot of code. Some programmers might want to tune cache eviction behaviour by changing it in a few controlled points in time. But not in a way that couldn't be exposed to assembler/C. (I don't know if that's even realistic from a hardware architect's point of view).

Re: C Is Not a Low-Level Language

#183

The points made in the article are certainly valid, but C is low-level in an abstract sense: it is approximately the intersection of all mainstream languages. I.e. if a feature exists in C, it probably exists in every language most programmers are familiar with. (I worded this statement carefully to exclude exotic languages like Haskell or Erlang). Thus C, while not low-level relative to actual hardware, is low-level…

Which languages have pointer arithmetic, longjmp, goto anywhere within a function, address-of operator, memcpy that is equivalent to assignment even for lexical variables, untagged unions, switch with fall-through in absence of explicit break and a textual/token-wise preprocessor?

Re: C Is Not a Low-Level Language

#184
I wonder if it's easier for a compiler/cpu to optimize "async" code ? And I often find myself having an array in JavaScript that calls the same function on each item in the array, it would be nice if such cases would be made parallel, which I think is possible to do in C++. Is that ever gonna happen in JavaScript !?

Re: C Is Not a Low-Level Language

#185
post #176

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.

It might still be possible. The JVM and .NET both have their speed annihilated by their awful choice of memory model.

What's wrong with their memory model? Honest question.

Re: C Is Not a Low-Level Language

#186

This article is completely clickbait. C is low level. For example, with AVRs everything you do maps very clearly to what happens as opcodes. It's like the author wants to blame C for whatever reason and conveniently forgets that C is also portable.

The author isn't blaming C. C has stayed largely the same. The author is saying that Intel and AMD have - unlike PIC, AVR, and such - hidden the machine from C so thoroughly that it's no longer a low-level language for that platform.

Re: C Is Not a Low-Level Language

#187
post #129

Earlier quoted context omitted.

>x86 assembly is a high level language. It's analogous to JVM bytecode. If you take this position, then having the distinction between "low level" and "high level" languages becomes pointless, and we have no way to distinguish between languages like x86 assembly and C and languages like Python and Haskell. This is why we use the terms "low level" and "high level": some of these languages have a lower level of abstrac…

> The fact that it's not giving you a great idea of exactly what's happening in the transistors is irrelevant The author's point is that what's happening in the transistors is relevant — not controlling it is what led to Spectre and heavy performance losses if you aren't smart about cache usage. Thinking of C as a "low-level language" makes it easier for people to overlook that fact.

And the parent's point is that there should be a distinction in level between Haskell and C, for example.

Re: C Is Not a Low-Level Language

#188

The author, David Chisnall, is a co-author on a related paper from PLDI 2016: "Into the Depths of C: Elaborating the De Facto Standards", https://news.ycombinator.com/item?id=11805377

He was also one of the earliest non-Apple contributors to Clang, was on the FreeBSD core team, and wrote the modern GNU Objective-C runtime implementation. His work on Objective-C in particular is prolific.

Re: C Is Not a Low-Level Language

#189

Earlier quoted context omitted.

Relative to dozens of years of "portable assembly" and "C makes you understand how a computer works" and "C is efficient because it maps to almost 1:1 with CPU operations" and a jillion of related claims.

Depending on your hardware that is still the case. There are plenty of embedded systems where these claims still hold. It's not really C that has changed (though the language has evolved a little bit), it's the hardware that changed and the implementation of the language.

That's the main thrust I got from the article. It does depend on the hardware, and for mainstream desktop and server hardware it no longer maps well to what the machine is doing.

Re: C Is Not a Low-Level Language

#190
post #102

The article does not properly distinguish between C as a language and what the C compiler does with the C program. The logic of the article references what the compiler does. The reasonable way to measure languages is to look at the abstractions present in the language. C has fewer abstractions than the other languages that we are familiar with. That is the reasonable definition of the level of a language.

That's exactly the author's point. The C that programmers write is remarkably far from what the compiler generates for modern hardware.

How do you propose measuring the number of abstractions? JavaScript has remarkably few built-in abstractions, but it's in no way "low-level" from a hardware perspective.

Post reply on HN