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

C Is Not a Low-Level Language

queue.acm.org

Post reply on HN
Print view View original

31–40 of 326 posts

Re: C Is Not a Low-Level Language

#31

Post by School-Cotton »

arghwhat wrote: post #6
thinkling wrote: post #3

TLDR: C was close-to-the-metal on the PDP-11 but since then hardware has become more complex while exposing the same abstraction to the C programmer. That means that hardware features such as speculative execution and L1/L2 caching are invisible to the programmer. This was the cause of Spectre and Meltdown and it forces a lot of complexity into the compiler. GPUs achieve high performance in part because their program…

It is very important to emphasize that GPU's only "achieve high performance" in workloads tailored very specifically to their extremely limited architecture. CPU's, on the other hand, are designed to be much more generic with decent performance for any task.

I think it's more accurate to say that CPUs are high-performance for different tasks than GPUs. Simple code, very wide data workloads are atrociously slow on CPUs, and single-threaded heavily branching workloads are atrociously slow on GPUs. That doesn't mean that one is more limited than the other.

Re: C Is Not a Low-Level Language

#32

Post by PersistentCough »

ge0rg wrote: post #14
mattnewport wrote: post #5

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…

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

Re: C Is Not a Low-Level Language

#33

Post by SolarNet »

ge0rg wrote: post #14
mattnewport wrote: post #5

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…

Not sure if facetious, but it failed because shifting that work caused it to be slow and not backwards compatible.

Re: C Is Not a Low-Level Language

#34

Post by ajross »

thinkling wrote: post #3

TLDR: C was close-to-the-metal on the PDP-11 but since then hardware has become more complex while exposing the same abstraction to the C programmer. That means that hardware features such as speculative execution and L1/L2 caching are invisible to the programmer. This was the cause of Spectre and Meltdown and it forces a lot of complexity into the compiler. GPUs achieve high performance in part because their program…

Yeah, but that's just reinventing the mistakes of VLIW all over again. Yes, CPUs have complicated behavior in a way that can't be captured by scalar imperative languages in a concise way. No, that doesn't mean that you can fix this with new abstractions.

The reason C won wasn't that it forced CPUs to adhere to its particular execution metaphor[1], but that it happened upon a metaphor that could be easily expressed and supported by CPUs as they evolved over decades of progress.

[1] Basically: byte-addressable memory in a single linear space, a high performance grows-down stack in that same memory space, two's complement arithmetic, and "unsurprising" cache coherence behavior. No, the last three aren't technically part of the language spec, but they're part of the model nonetheless and had successful architectures really diverged there I doubt C-like runtimes would have "won".

Re: C Is Not a Low-Level Language

#35

Post by dahart »

tsomctl wrote: post #12
dahart wrote: post #7

> A processor designed purely for speed, not for a compromise between speed and C support, would likely support large numbers of threads, have wide vector units, and have a much simpler memory model. Sounds like a GPU? > Running C code on such a system would be problematic, so, given the large amount of legacy C code in the world, it would not likely be a commercial success. It seems like ATI & NVIDIA are doing okay,…

C-like code that runs on GPUs is not even close to normal C, even though the syntax is similar. The way you layout your memory, schedule your threads, and add memory barriers is completely different. You are never going to take a piece of large C code written for a CPU and just run it directly on a GPU.

Huh, that’s weird, I run a C++ compiler directly on my GPU code. The only difference between CPU and GPU code at the function level is whether I tag it with a __global__ macro or not, and lots of functions compile and run for both CPU and GPU.

Memory layout, thread scheduling, and barriers are not features of the C language and have nothing to do with whether your C is “normal”. Those are part of the programming model of the device you’re using, and apply to all languages on that device. Normal C on an Arduino looks different than normal C on an Intel CPU which looks different than normal C on an NVIDIA GeForce.

Re: C Is Not a Low-Level Language

#36

Post by swsieber »

Avshalom wrote: post #29
mattnewport wrote: post #5

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…

>If C is not a low level language then a low level language does not exist for modern CPUs correct, but that lack is not an argument for C being low level.

Correct - it's an argument for broadening the title.

Calling out a specific language as not being something leads one to ask, "Well what is?". In this case, there is no qualifying alternative, so the title might as well be, "There is no low-level language for CPUs".

Re: C Is Not a Low-Level Language

#37

Post by zelos »

occamrazor wrote: post #8
thinkling wrote: post #3

TLDR: C was close-to-the-metal on the PDP-11 but since then hardware has become more complex while exposing the same abstraction to the C programmer. That means that hardware features such as speculative execution and L1/L2 caching are invisible to the programmer. This was the cause of Spectre and Meltdown and it forces a lot of complexity into the compiler. GPUs achieve high performance in part because their program…

I don’t understand. CPUs do not support C, they support a specific instruction set. What stops them from having instructions for cache management, pipelining, speculative execution hints, etc?

Games console CPUs support those kind of instructions, don't they?

To some extent, didn't Intel go down this road with VLIW: trying to shift the burden of making code fast onto the compiler, instead of the CPU?

Re: C Is Not a Low-Level Language

#38

Post by rbanffy »

mattnewport wrote: post #5

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…

Microcode is the new low level language. ;-)

But, to be fair, C is not that low level. In fact, when I first learned it, it was considered a high-level language because CPUs we used it with didn't have functions with parameters, only subroutine jumps.

C reaches into the realm of low-level languages because it allows you to arbitrarily read from and write to the "state" of the context you live in, but it also allows you to express constructs that have no counterpart even on the most complex CPU architectures (even if they have things that disagree fundamentally with C's point of view).

Re: C Is Not a Low-Level Language

#39

Post by Avshalom »

swsieber wrote: post #36
Avshalom wrote: post #29

Earlier quoted context omitted.

>If C is not a low level language then a low level language does not exist for modern CPUs correct, but that lack is not an argument for C being low level.

Correct - it's an argument for broadening the title. Calling out a specific language as not being something leads one to ask, "Well what is?". In this case, there is no qualifying alternative, so the title might as well be, "There is no low-level language for CPUs".

... any more.

It's not a category that can't exist, it just doesn't have any members right now.

Re: C Is Not a Low-Level Language

#40

Post by School-Cotton »

jackhack wrote: post #9
thinkling wrote: post #3

TLDR: C was close-to-the-metal on the PDP-11 but since then hardware has become more complex while exposing the same abstraction to the C programmer. That means that hardware features such as speculative execution and L1/L2 caching are invisible to the programmer. This was the cause of Spectre and Meltdown and it forces a lot of complexity into the compiler. GPUs achieve high performance in part because their program…

Thanks for the TLDR. But if that's the argument, then not even assembly is sufficient, as control over speculative branching and prefetch is only accessible via microcode in the CPU. I think the argument is improperly framed. This is a discussion over public and private interface. The CPU is treated as a black box with a public interface (the x86+ instruction set). Precisely how those instructions are implemented (on…

You make good points - if we're just talking about semantics, then yes C is the closest portable language to x86 or arm and is low-level in that sense. But on the other hand, semantics is not always the only important thing: performance is sometimes important also, and there these low-level details matter. The architecture does its best to hide them from the user, but the abstraction is very leaky.

For example, when writing high-performance CPU-bound code it's usually important to keep in mind how wide cache lines are, but C doesn't expose this to the programmer in a natural way.

Post reply on HN