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

241–250 of 326 posts

Re: C Is Not a Low-Level Language

#241

Post by angry_octet »

It is instructive to consider GPUs and their compilers. The death of OpenGL in favour of Vulcan has come about because OpenGL is unable to express low level constructs which are essential to achieving performance. GPU drivers are actually compilers that recompile shaders to efficient machine expressions.

Thus the fundamental limitation is that the processor has only a C ABI. If there were a vectorisation and parallel friendly ABI, then it would be possible to write high level language compilers for that. It should be possible for such an ABI to coexist with the traditional ASM/C ABI, with a mode switch for different processes.

Re: C Is Not a Low-Level Language

#242

Post by dnautics »

mattnewport wrote: post #149
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…

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

arguably the "sufficiently advanced compiler" (cue joke) has arrived (sadly, post Itanium, Cell) in the form of a popularized LLVM[0], so it's improper to claim failure based on two, aged datapoints.

The flaws of OOO and SpecEx are evident with the overhead required to secure a system (spectre, meltdown) in a nondeterministic computational environment, and there is certainly a power cost to effectively JITting your code on every clock cycle.

As the definition of performance is changing due to the topping out of moore's law and shifting paralellism from amdahl to gustafson, I think there is a real opportunity for non ooo, non specex in th future.

Re: C Is Not a Low-Level Language

#243

Post by Const-me »

One reason for that is for many applications latency is much more critical than bandwidth. For PCs that’s input-to-screen latency, for servers that’s request-to-response. It’s possible to make multicore processors with simpler cores, design OS and language ecosystem around it, etc. Such tradeoffs will surely improve bandwidth, but will harm latency.

Another reason is most IO devices are inherently serial. Ethernet only has 4 pairs, and wifi adapters are usually connected by a single USB or PCIx lane. If a system has limited single threaded (i.e. serial, PDP11-like) performance, it gonna be hard to produce or consume these gbits/sec of data.

Re: C Is Not a Low-Level Language

#244

Post by kwillets »

waynecochran wrote: post #236
kwillets wrote: post #108

Earlier quoted context omitted.

unsigned char r(unsigned char num) { return num % 10; } https://godbolt.org/g/26HfQk

Yes. this is doing to infamous division by 10 using bit shifts as you will find in hacker's delight: http://www.hackersdelight.org/divcMore.pdf . You may notice that when you divide num by 10 you get a quotient q and a remainder r: num = q*10 + r Once you get q, you can solve for r as r = num - q*10 So this is how you get r and q: q = (num >> 1) + (num >> 2); q = q + (q >> 4); q = q + (q >> 8); q = q + (q >> 16); q =…

Yep, 205/2048 = .10009..

This is something I'm actually using, as I'm serializing small int's (0-99). For those it all fits in 16 bits.

Re: C Is Not a Low-Level Language

#245

Post by marshray »

Baeocystin wrote: post #185
Tobba_ wrote: post #176

Earlier quoted context omitted.

It might still be possible. The JVM and .NET both have their speed annihilated by their awful choice of memory model.

What's wrong with their memory model? Honest question.

Garbage Collection is a very consequential design decision. To free that last unused object is going to take O(total writable address space) memory bandwidth.

Re: C Is Not a Low-Level Language

#246

Post by angry_octet »

angry_octet wrote: post #241

It is instructive to consider GPUs and their compilers. The death of OpenGL in favour of Vulcan has come about because OpenGL is unable to express low level constructs which are essential to achieving performance. GPU drivers are actually compilers that recompile shaders to efficient machine expressions. Thus the fundamental limitation is that the processor has only a C ABI. If there were a vectorisation and parallel…

s/vulcan/vulkan damn autocorrect.

Re: C Is Not a Low-Level Language

#247

Post by dgreensp »

arghwhat wrote: post #214
dgreensp wrote: post #98

Earlier quoted context omitted.

The point is specifically about parallel vs sequential programs. Legacy C code is sequential, and the C model makes parallel programming very difficult. I met a guy back in college, a PhD who went to work at Intel, who told me the same thing. In theory, the future of general purpose computing was tons of small cores. In practice, Intel's customers just wanted existing C code to keep running exponentially faster.

> Legacy C code is sequential, and the C model makes parallel programming very difficult. Neither of these statements are true, unless "Legacy" refers to the early days of UNIX. Tasks that parallelize poorly do not benefit of many small cores. This is usually a result of either dealing with a problem that does not parallelize, or just an implementation that does not parallelize (because of a poor design). Neither of…

I admit it's not fair to blame C in particular. The comparison is between how we write and execute software and how we could write and execute software, and the language absolutely comes into play, in addition to how the language is conventionally used. "Legacy" code in this context is code that was written in the past and is not going to be updated or rewritten.

I disagree that tasks performed by a computer either don't parallelize or the cost of synchronization is too high. At a fine-grained level, our compilers vectorize (i.e. parallelize) our code -- with limits imposed by C's "fake low-levelness" as described in the article -- and then our processors exploit all the parallelism they can find in the instructions. At a coarser level, even if calculating a SHA (say) isn't parallelizable, running a git command computes many SHAs. The reasons why independent computations are not done on separate processors -- even automatically -- come down to programming language features (how easy is it to express or discover the independence, one way or another) and real or perceived performance overhead. Hardware can be designed so that synchronization overhead doesn't kill the benefits of parallelization. GPUs are a case in point.

The world is going in the direction of N cores. We'll probably get something like a mash-up of a GPU and a modern CPU, eventually. If C had been overtaken by a less imperative, more data-flow-oriented language, such that everyone could recompile their code and take advantage of more cores, maybe these processors would have come sooner.

Re: C Is Not a Low-Level Language

#248

Post by pavon »

Rebelgecko wrote: post #216
fixermark wrote: post #136

Earlier quoted context omitted.

Correct. For low-level language, we may actually want to look more in the direction of HLSL or GLSL.

I haven't done any shader programming, but can we even say that about those languages? It might just be my own inexperience talking, but for anything more complicated than matrix multiplication the innards of a GPU seem just as opaque as a CPU.

OpenGL started out as being a pretty high level language and 1.0 certainly doesn't map closely to modern hardware at all. But APIs and hardware have moved closer together over time, and stuff like CUDA and Vulkan use models that are a pretty close match to the hardware they run on. When writing CUDA you can reasonably figure the number of cycles an operation will take, and benchmarking will agree, unlike CPUs that have become so non-deterministic that they are much harder to reason about.

That said, I wouldn't look to those as examples for how to design a good "low-level" CPU language, as CPUs and GPUs solve very different problems.

Re: C Is Not a Low-Level Language

#249

Post by dgreensp »

zkomp wrote: post #201
dgreensp wrote: post #95

Earlier quoted context omitted.

I think the author's point is that despite being perceived as low-level, C doesn't really differ from, say, Java on the last bullet. In other words, a programmer who sits down and uses C and not Java might think, "I am being forced to pay attention to irrelevant things and think in unnatural ways, but that's because I am writing fast code using operations that map to operations done by the physical machine. In a high…

Maybe true but I think the Java example is not that good. Java is still not that different from C. Java is more like a decendant to C and C++ - and to be honest both languages force you to pay attention to lots of irrelevant "low-level" detail, fictionally low-level since its not actually the machine but language itself (that is stuck in the PDP11 mental mode...) Compared to something different like Erlang, Haskell,…

High-level and low-level are relative, to be sure, but Java is definitely considered higher-level than C -- it was designed to target a virtual machine, for example, while C was designed to target real machines -- so I think it illustrates the article's point perfectly.

Re: C Is Not a Low-Level Language

#250

Post by anfilt »

mark-r wrote: post #146
rbanffy wrote: post #51

Earlier quoted context omitted.

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?

I have used the SIMD instructions quite a bit. Even used FPGA's for some tasks.
Post reply on HN