"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'.
C Is Not a Low-Level Language
311–320 of 326 posts
Re: C Is Not a Low-Level Language
#312Earlier 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).…
Re: C Is Not a Low-Level Language
#313Earlier 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…
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
#314Earlier 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.
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
#315This 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 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
#316Earlier 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
Re: C Is Not a Low-Level Language
#317Earlier 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++
Re: C Is Not a Low-Level Language
#318Earlier 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.
Re: C Is Not a Low-Level Language
#319Ah 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.
Re: C Is Not a Low-Level Language
#320Earlier 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.
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.