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

11–20 of 326 posts

Re: C Is Not a Low-Level Language

#11

Post by _fq4v »

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?

The Itanium processor did exactly this. Other than being a commercial flop, it was found to be quite difficult to actually get the compiler to generate good management instructions, and x86 was often able to beat out an itanium core at the same clock speed

Re: C Is Not a Low-Level Language

#12

Post by tsomctl »

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.

Re: C Is Not a Low-Level Language

#14

Post by ge0rg »

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 improve the design, Intel's Itanium (affectionately called "Itanic") was a very progressive approach to shift the optimization work from the CPU (and the compiler) to just the compiler. I'm not sure what the reasons for its failing were, though.

Re: C Is Not a Low-Level Language

#16

Post by Avshalom »

retrogradeorbit wrote: post #13

It's all relative. Lower level than what? Higher level than what? C is lower level than a huge number of other languages so I would feel comfortable calling it 'low level'.

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.

Re: C Is Not a Low-Level Language

#17

Post by coliveira »

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?

They do not support C officially, but every CPU designer knows that 99%+ of the code that matters is written in C. Therefore they design chips targeting this translation from C. What the authors want is a better lower level interface that would allow for modern processor features without the legacy of the features available to the PDP11.

Re: C Is Not a Low-Level Language

#18

Post by [deleted] »

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…

[deleted]

Re: C Is Not a Low-Level Language

#19

Post by mattnewport »

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?

Many of these features are very difficult to use in a useful way in a static context (e.g. at compile time) because the performance gains mostly come from taking advantage of dynamic context. Speculative execution and out of order execution for example are mostly useful because you don't know at compile time exactly what data your code is processing or what CPU it is running on, what function / context you are being called from, what is in cache and what isn't, etc.

The SPUs on the PlayStation 3 were an experiment in user managed caches and that proved to be a difficult thing to make effective use of even in games where you know more context than a lot of code can assume.

Post reply on HN