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…
One feature that many languages don't provide is the ability to have direct control over how aggregates are organized in memory.
It's worth noting that chips that were designed for high-performance computing (e.g. the Cell) from the outset generally don't have silicon devoted to things like out of order execution, register renaming, etc. In this case, the bulk of the optimization logic does shift to the programmer (aided by the compiler). The reason is that in these domains (e.g. game consoles, supercomputing), you know ahead of time the preci…
The point of dynamic optimizations (such as ooo) is not only to hide implementation details (such as register file size) but very much to take advantage of dynamic opportunities that simply cannot be known statically. The optimal schedule can be very different depending on whether some load hit L1 vs L2 or even was forwarded from the store buffer. There are some classes of very regular algorithm where you could proba…
Yeah, this is a very important point that many people seem to be missing, including the authors of the original article it seems to me. It was certainly a big problem for performance of games on Cell in my experience.
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 I think that's a fair conclusion though, I don't think the article is misleading. x86 assembly is a high level language. It's analogous to JVM bytecode. Modern x86 processors are more like a virtual machine for x86 bytecode.
The JVM provides native primitives around memory and thread management which are not present in x86, but that's a matter of degree.
It's analogous to JVM bytecode. That's only true in the way everything is analogous to everything.
Nope, also in the way the parent explains right after that sentence.
It's a pretty terrible analogy in nearly every obvious technical way. What an x86 cpu does with its instructions is almost but not entirely unlike what a JVM does.
... any more. It's not a category that can't exist, it just doesn't have any members right now.
It actually can't exist at all for current modern CPUs (x64/ARM/PowerPC) since they don't expose a programming interface for many of the things discussed in the article (speculative / out of order execution, register renaming, full cache control).
Yeah but it can for all sorts of microcontroller-y chips; embedded CPUs; DSPs; theoretical future CPUs that aren't trying to both act like a PDP11 and go faster every year...
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…
> I worded this statement carefully to exclude exotic languages like Haskell or Erlang
I suspect that your definition of "exotic" is exactly "not like C".
>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".
> Calling out a specific language as not being something leads one to ask, "Well what is?".
The article does basically answer this. The last section is about what it would mean to design a chip such that a low level language were possible to design for it.
The thing is, most of the time you're reflecting at some logical level that will not be the "reality". The problem is that C programmer think that C === reality === performance. C has better (lower) constant factors but by no means better all the time.
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…
There was an article on Hacker News recently that covered some of the reasons for Itanium's failure to realize its theoretical benefits. I'm not finding it now, but IIRC, the argument made was that predicting likely-parallelizable code is actually a lot harder to do at compile time, and that, like so many ultra-optimized systems, the real world works much differently and a messier, more random approach ultimately yields far better performance.