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

141–150 of 326 posts

Re: C Is Not a Low-Level Language

#141

Post by lmm »

marshray wrote: post #140
drbawb wrote: post #133

Earlier quoted context omitted.

>the argument made was that predicting likely-parallelizable code is actually a lot harder to do at compile time So don't do it at compile time? That's really a very weak argument against the Itanium ISA, and honestly more of an argument against the AOT complication model. Take a runtime with a great JIT, like the JVM or V8, and teach it to emit instructions for the Itanium ISA. (As an added advantage these runtimes…

This argument has been made since the introduction of the JVM in the early mid-90's. 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.

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

Re: C Is Not a Low-Level Language

#142

Post by skylyrac »

This doesn't make any sense. This would mean that my C code compiled for a Cortex-M0 is low level, but for my x86 laptop is not. Or even more stupid, that the same assembly code running in an old 386 is low level, but for an i7 isn't.

Low level is about how close to talking to the CPU you are, not about how close to the silicon you are. The CPU is a black box and the programmer communicates with it. What that box does inside doesn't matter.

Re: C Is Not a Low-Level Language

#143

Post by plpot »

I find this article insightful, but missing the points it tries to deliver.

What the article is very good at delivering is that current CPU's ISAs exports a model that doesn't exist in reality. Yes, we might call it PDP-11, although I miss that architecture dearly.

C was never meant to be a low level language. It was a way to map loosely to assembler and provide some higher level abstraction (functions, structures, unions) to write code that was more readable, and structured, than assembler. And yes, it is far from perfect. And yes, today is called a low level language with good reasons.

But this article is all about exposing the insanity that modern CPU have become, insanity that is the sacrifice to the altar of backward compatibility -- all CPU architecture that tried the path of not being compatible with older CPUs have died.

I am pretty sure that once we'll have an assembler that map closely to the microcode, or to the actual architecture of the internals of a modern, parallel, NUMA architecture, we will still need to have a C-like language that will introduce higher level features to help us ease writing of non-architecture dependent parts. And it will most probably be C.

Re: C Is Not a Low-Level Language

#144

Post by mattnewport »

scott_s wrote: post #132
mattnewport wrote: post #79

Earlier quoted context omitted.

> The reason is that in these domains (e.g. game consoles, supercomputing), you know ahead of time the precise hardware characteristics of your target, you can assume it won't change, and can thus optimize specifically for that ahead of time. Cell was a failure in large part because this proved to be less true / less relevant than its designers thought. Source: many late nights / weekends trying to get PS3 launch tit…

I did work in graduate school trying to make the Cell easier to program - basically, providing OpenMP-like abstractions that would take advantage of the SPEs. I've always been really curious: how much did your games take advantage of the SPEs? When did you send code to the SPEs versus using the GPU? Were you using libraries that helped managing the SPEs, or did you do all of it manually?

OpenMP is a bad approach for the types of problems commonly encountered in games and graphics programming in my experience. Matt Pharr's excellent series of articles on the history of ISPC gives some good explanations of what programming models actually work well for graphics particularly: http://pharr.org/matt/blog/2018/04/30/ispc-all.html

At the time I was doing most of my SPE work (helping to optimize launch titles at EA prior to the launch of the PS3) most titles weren't taking much advantage of them at all. We were a central team helping move some code that seemed like it would most benefit over, I was particularly involved in moving animation code to the SPEs. There weren't really any options for libraries to help at that point, other than things we were building internally, so it was almost all manual work.

Later on in the PS3 lifecycle people moved more and more code to the SPEs. To my knowledge most of that work was largely manual still. For a while I was project lead on EA's internal job/task management library which had had a big focus on supporting use of the SPEs but my involvement in it was mostly during the early part of the Xbox One / PS4 generation. The Frostbite graphics team in particular did a lot of interesting work shifting GPU work over to the SPEs (I think some of it they've talked about publicly) but I wasn't directly involved in that.

Re: C Is Not a Low-Level Language

#145

Post by lmm »

Shikadi wrote: post #118

Language evolves. C is certainly lower level than C# or JavaScript, so even if it no longer fits the definition created decades ago, I don't see a problem with the term evolving to match modern times. People say assembly language when they mean assembly language, (which others have argued isn't low level any more anyway) so using low level to describe a language closer to the hardware seems valid to me. It's interest…

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.

Re: C Is Not a Low-Level Language

#146

Post by mark-r »

rbanffy wrote: post #51
School-Cotton wrote: post #25

Earlier quoted context omitted.

That doesn't mean the definition is useless -- rather than "C isn't a low-level language, as opposed to something else which is", the point might be "there exist no low-level languages according to most people's understanding of that term". Which is still an interesting and useful fact.

It also hides the fact C is just a couple notches above the absolute minimum most people would even consider - writing assembly code by hand - and is, effectively, the lowest most programmers will ever venture.

How many people have resorted to SIMD intrinsics because C wasn't low level enough?

Re: C Is Not a Low-Level Language

#147

Post by scott_s »

mattnewport wrote: post #144
scott_s wrote: post #132

Earlier quoted context omitted.

I did work in graduate school trying to make the Cell easier to program - basically, providing OpenMP-like abstractions that would take advantage of the SPEs. I've always been really curious: how much did your games take advantage of the SPEs? When did you send code to the SPEs versus using the GPU? Were you using libraries that helped managing the SPEs, or did you do all of it manually?

OpenMP is a bad approach for the types of problems commonly encountered in games and graphics programming in my experience. Matt Pharr's excellent series of articles on the history of ISPC gives some good explanations of what programming models actually work well for graphics particularly: http://pharr.org/matt/blog/2018/04/30/ispc-all.html At the time I was doing most of my SPE work (helping to optimize launch title…

I completely believe you on OpenMP being bad for games and graphics programming; we were targeting the HPC community which had a heavy interest in Cell as well. But all the while, I knew a bunch of programmers out in the world were shipping Cell code, and I was always curious what their patterns were. Thanks for the answers!

Re: C Is Not a Low-Level Language

#148

Post by gh02t »

skywhopper wrote: post #90
ge0rg wrote: post #14

Earlier quoted context omitted.

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 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 compatible, currently faster and cheaper x86_64." It didn't gain any real momentum to start because of this, which ultimately doomed it even when a lot of the issues were resolved later on.

Re: C Is Not a Low-Level Language

#149

Post by mattnewport »

drbawb wrote: post #133
skywhopper wrote: post #90

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…

>the argument made was that predicting likely-parallelizable code is actually a lot harder to do at compile time So don't do it at compile time? That's really a very weak argument against the Itanium ISA, and honestly more of an argument against the AOT complication model. Take a runtime with a great JIT, like the JVM or V8, and teach it to emit instructions for the Itanium ISA. (As an added advantage these runtimes…

There's not that much overlap between the kind of optimizations that JITs do and the optimizations that modern CPUs do. The promise of JITs outperforming AoT compiled code has never really materialized. The performance advantages of OoO execution, speculative execution, etc. are very real and all modern high performance CPUs do them. Attempts to shift some of that work onto the compiler like Itanium and Cell have largely been failures.

Re: C Is Not a Low-Level Language

#150

Post by mattnewport »

lmm wrote: post #141
marshray wrote: post #140

Earlier quoted context omitted.

This argument has been made since the introduction of the JVM in the early mid-90's. 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.

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

Post reply on HN