Live data from Hacker News

C Is Not a Low-Level Language

queue.acm.org

311–320 of 326 posts

Re: C Is Not a Low-Level Language

#311

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

hmmm, I think that CPUs instruction sets inherit mainly from the 8086, and https://en.wikipedia.org/wiki/Intel_8086 mentions few languages that had influence on the 8086 design, but don't mention C at all.

Re: C Is Not a Low-Level Language

#312

Earlier quoted context omitted.

OoO and speculative execution are largely improving performance based on dynamic context that in most real world cases is not available at compile time. They are able to do so much more efficiently than software JITting can due to being implemented in hardware. There is still no sufficiently advanced compiler to make getting rid of them a good strategy for many workloads. Most of what OoO and speculative execution ar…

My point is that the dominant software programming paradigm is migrating away from highly dynamic to highly regular. A good example is Machine learning, where for any given pipeline, your matrix sizes are generally going to stay the same. A good compiler can distribute the computation quite well without much trouble, and this code will almost certainly not need SpecEx/OOO (which is why we put them on GPUs and TPUs).…

This might be true for some domains but it's far from true for the performance sensitive domains I'm familiar with - games / VR / realtime rendering. The trend is if anything the opposite there as expectations around scene and simulation complexity are ever increasing.

Re: C Is Not a Low-Level Language

#313

Earlier quoted context omitted.

Java and Python are much closer to C than C is to assembly. Managing memory and raw pointers are nothing. Try implementing a recursive function call in x86 assembler to get a real idea of low level.

> Try implementing a recursive function call in x86 assembler to get a real idea of low level. Isn't that pretty easy? Recursion is just a function calling itself, directly or indirectly. Here's the simplest possible recursive function in x86 assembler. It simply causes a stack overflow. recursion: call recursion That's it. Tail recursive version would be simply a jump: recursion: jmp recursion Here's the simplest te…

A call is not a function; functions have parameters and return values, and you’ll need at least one local variable. And you need to save the values of all the registers if you don’t want the called function overwriting them.

You’ll need to manually push that all onto the stack with each call. There’s no compiler to do all that work for you.

Re: C Is Not a Low-Level Language

#314

Earlier quoted context omitted.

> Try implementing a recursive function call in x86 assembler to get a real idea of low level. Isn't that pretty easy? Recursion is just a function calling itself, directly or indirectly. Here's the simplest possible recursive function in x86 assembler. It simply causes a stack overflow. recursion: call recursion That's it. Tail recursive version would be simply a jump: recursion: jmp recursion Here's the simplest te…

A call is not a function; functions have parameters and return values, and you’ll need at least one local variable. And you need to save the values of all the registers if you don’t want the called function overwriting them. You’ll need to manually push that all onto the stack with each call. There’s no compiler to do all that work for you.

If I have just one parameter in eax/rax and return value in eax/rax, why would I need a stack frame? It's not like any registers except eax/rax (and flags) are modified anyways. And that function doesn't call anything else that could modify eax/rax.

A call is a function as long as caller and callee agree on the calling convention. Non-exported functions don't necessarily need to adhere to platform ABI.

Generally you only push registers on stack when you need to modify more variables than what fit in your calling convention "thrashable" register set, or when you save register contents to call other function, or to push function call parameters on the stack.

I do embedded systems & low level drivers as my dayjob. Not a stranger to writing assembler routines.

Re: C Is Not a Low-Level Language

#315
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…

Itanic failed because Intel/HP initially still used a front side bus memory architecture, which could not support the bandwidth necessary for peak performance on anything but matrix multiplication and other computations where most of the work is done in-cache. Then Opteron came around, with its faster memory, and Intel was suddenly thrown back into reality.

Itanic was also in-order (at least as far as dispatch), meaning anytime an instruction was stalled, so were all instructions in the same bundle or after it.

One "non-low-level" idea on Itanic, which never really panned out in practice, was for the assembler to automatically insert stop bits ;; marking assembly code "sequence points", instead of the programmer having to do it manually. But in practice, everyone did it manually, because they'd rather know how well their bundles were being used, and whether they could move instructions around in order get the full 3 instructions / bundle (6 instructions / clock).

And explicit stop bits did not provide any advantage to future hardware by marking explicit parallelism, because at every generation everyone was concerned about obtaining maximum performance on the current machine, which involved shuffling instructions into 6-instruction double-bundles, often at the expense of parallelism on future implementations (which never went beyond two bundles / clock).

Re: C Is Not a Low-Level Language

#316
post #141

Earlier quoted context omitted.

> 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

Your article is correct that Java/C# performance is unpredictable. But, per the OP, C/C++ performance is also unpredictable, because C/C++ doesn't reflect what a modern processor actually does; there are cases where e.g. removing a field from a datastructure makes your performance multiple orders of magnitude worse because some cache lines now alias.

Re: C Is Not a Low-Level Language

#317
post #141

Earlier quoted context omitted.

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

"New projects do use Java or C# rather than C/C++ though." But not for speed reasons. Java is in no way faster than well written C/C++

X is not faster than well written Y, for all X and Y; that's not a particularly useful comparison though. I've seen a project pick Java over C/C++ because, based on their previous experience, the memory leaks typical of C/C++ codebases were a worse performance problem than any Java overhead.

Re: C Is Not a Low-Level Language

#318
post #141

Earlier quoted context omitted.

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

> New projects do use Java or C# rather than C/C++ though. Nobody is picking Java/C# over C/C++ for performance reasons.

I've seen a project pick Java over C/C++ because of the memory leaks they saw in the latter in practice. You can call that a correctness issue rather than a performance issue if you like, but the practical impact was the same as a performance problem.

Re: C Is Not a Low-Level Language

#319

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.

We've banned this account for repeatedly violating the site guidelines.

https://news.ycombinator.com/newsguidelines.html

Re: C Is Not a Low-Level Language

#320
post #317

Earlier quoted context omitted.

"New projects do use Java or C# rather than C/C++ though." But not for speed reasons. Java is in no way faster than well written C/C++

X is not faster than well written Y, for all X and Y; that's not a particularly useful comparison though. I've seen a project pick Java over C/C++ because, based on their previous experience, the memory leaks typical of C/C++ codebases were a worse performance problem than any Java overhead.

Well written Java is sure to be slower than well written C/C++.

Happy? ;)

But yes, the point you make, is valid, it is much harder to write C/C++ well, because of the burden of memory management. So if you lack the time or skilled people, it might make sense to choose Java out of perfomance reasons.

Post reply on HN