Live data from Hacker News

C Is Not a Low-Level Language

queue.acm.org

161–170 of 326 posts

Re: C Is Not a Low-Level Language

#161
post #148

Earlier quoted context omitted.

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

Itanium suffered performance wise initially because they had trouble with compilers, but that's not the whole story. You also have to consider that AMD launched AMD64, which was backwards compatible, at about the same time. Later on the Itanium compilers got better, but on release it became a choice of "sluggish, incompatible and expensive Itanium with potential to perform well in the future" versus "backwards compat…

> which ultimately doomed it even when a lot of the issues were resolved later on.

Was there ever a point in the Itanium's history where there were Itaniums that ran mainstream software with better performance than equivalently priced x64 processors?

Re: C Is Not a Low-Level Language

#162

Earlier quoted context omitted.

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

Their comment makes sense if you interpret "the C compiler" to mean "mainstream C compilers that 99% people use in production" or even just "gcc and clang". We're talking about concrete things in the real world here, not philosophizing about the language spec.

> not philosophizing about the language spec.

That's exactly what's going on.

Re: C Is Not a Low-Level Language

#163
post #55
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,…

> Sounds like a GPU? Which reminds me I'd love to see a computer running exclusively from a GPU-like CPU. And no, Xeon Phi's don't count. They are cool, but look too much like normal PCs.

Here’s one: https://en.m.wikipedia.org/wiki/Cray-1

They didn’t call it a GPU then, but the SIMD architecture is quite similar at a high level.

Larrabee was going to be a GPU-like CPU. https://en.m.wikipedia.org/wiki/Larrabee_(microarchitecture)

Here’s a more modern GPU based computer: https://www.nvidia.com/en-us/self-driving-cars/drive-platfor...

If you meant something that sits on your desktop and runs Linux, then yeah it’s uncommon but not unheard of to run it on a SIMD system. The trend is absolutely definitely going toward SIMD being used in general purpose computing. Even if you don’t want to count any of my examples, you will see the “normal” PC become more GPU-like in the future than it is today.

Re: C Is Not a Low-Level Language

#164

I really really liked this article, and reading the comments here is blowing my mind. Did we read the same thing? I think it's a strong insight that insight that chip designers and compiler vendors have spent person-millenia maintaining the illusion that we are targeting a PDP-11-like platform even while the platform has grown less and less like that. And, it turns out, with things like Spectre and the performance co…

As someone who does large scale computational work for a living, stuff like this is close to my heart. I often run into serious memory and run time constraints due to poorly written codes that have rather dumb understanding of the real underlying machine implementation that modern processors actually have rather than this imaginary PDP-11 that we've been brought up to believe.

I wonder how much I could save (and how many more sims I could run) if my codes were rewritten in a language that has an abstract system that is much more cleanly and simply translated to what the computer actually does in 2018.

Re: C Is Not a Low-Level Language

#165
post #145

Earlier quoted context omitted.

The whole point of the article is that by a definition like the one you quoted, modern C is not low-level, though PDP-11 era C was.

That's not true - PDP-11 era C isn't either - if you run it on a modern processor. And it's doubtful it even was then.

> PDP-11 era C isn't either - if you run it on a modern processor. And it's doubtful it even was then.

With a modern compiler C isn't low-level. But under PDP-11 era C compilers, C really did map closely to processor instructions.

Re: C Is Not a Low-Level Language

#166
post #83

If the general public & tech community refers to C as a low level language then it is a low level language.

When a lie gets repeated enough times, eventually it becomes a fact.

It's just practical. Otherwise how do you call java ? Or python ?

And what would be the benefit of changing those particular sementics ?

In french we define such article as "fucking a fly".

Re: C Is Not a Low-Level Language

#167
post #104

Earlier quoted context omitted.

It isn't at all similar. JVM bytecode is a pretty high-level IR for tokenized Java. The JVM's main unit of optimization is a method, not instructions. Its key component is a compiler, it's even called that. An x86 cpu, as the article points out, spends inordinate resources looking for ILP. It's not a compiler in any reasonable sense of the word, while a JVM is.

The point I'm trying to make with the analogy is that the x86 instruction set is not representative of what the hardware is actually doing. It is not "low level" because it is an abstraction or virtual platform that the processor exposes and then interprets using its own internal resources and programming interface (microcode). The x86 interface does not map closely to the actual hardware, just as the article states.…

Right, and the point I'm trying to make is this is a pretty lousy analogy. For one thing, an x86 CPU is not nearly as VM-y as you make it out - renamed registers are very much real registers, big piles of the most common instructions execute in 1 or 2 uOps. For another, the VM you've picked as an example is singularly uncpu-like. C also exposes an abstract machine, would you use that as an analogy? Probably not.

'An abstraction that is interpreted or compiled at runtime' is so broad it's exactly the what I said up top - it's analogous in the way everything is analogous to everything else. It's the sort of thing that might be true if you squint but offers somewhere between zero and negative insight.

Re: C Is Not a Low-Level Language

#168
It feels like the author really isn't talking so much about the limitations of C on modern architectures, but the architecture itself.

Possibly relevant is this (short?) discussion[1] from 2011 about a CPU more closely designed for functional programming.

[1] https://news.ycombinator.com/item?id=2645423

Re: C Is Not a Low-Level Language

#169
post #43
post #35

Earlier quoted context omitted.

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

OK, I guess it comes down to what you call "normal" C. I was defining it as what would run on x86 Windows or Linux.

You can look at C++ AMP too, it runs with all GPUs that support DX11 on Windows, and is a part of the Windows SDK. It's implemented by AMD ROCm on Linux, which also implements HIP/CUDA. Normal C/C++ can run fine on modern GPU architectures.

Re: C Is Not a Low-Level Language

#170
post #148

Earlier quoted context omitted.

Itanium suffered performance wise initially because they had trouble with compilers, but that's not the whole story. You also have to consider that AMD launched AMD64, which was backwards compatible, at about the same time. Later on the Itanium compilers got better, but on release it became a choice of "sluggish, incompatible and expensive Itanium with potential to perform well in the future" versus "backwards compat…

> which ultimately doomed it even when a lot of the issues were resolved later on. Was there ever a point in the Itanium's history where there were Itaniums that ran mainstream software with better performance than equivalently priced x64 processors?

There were hand-coded assembly loops that were 3-4 times faster than x86, using Itanium's predicates and rolling register windows.

But I guess you said mainstream. So unless you count database engines, I suppose the answer is "No."

Today you can get the same vector performance using SSE4 and AVX. Almost all of Itanium's good stuff has been rolled into Xeon.

Post reply on HN