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

261–270 of 326 posts

Re: C Is Not a Low-Level Language

#261

Post by fixermark »

simen wrote: post #258
fixermark wrote: post #137

Earlier quoted context omitted.

True, but one of the points the article makes is that in practice, there's a vast gulf of distance (person-years of C compiler development) between the C code one writes and the resulting assembly code output (and this is ignoring the fact that x86 assembly is, itself a co-evolved abstraction with C-like languages that is basically emulated on modern massively-parallel CPU architectures). In that regard, a case can b…

> In that regard, a case can be made that when you're writing in C, you're writing exactly as close to the bare metal as if you're writing in, say, Go or Haskell. No, you really can't. This is childish black and white thinking. The computational model of C is built on an interface exposed by the hardware. Go and Haskell build many additional abstractions on top of that same model. This article could have had a fruitf…

But I believe that's the article's very point: the context and relative terms people often talk about C are incorrect. The amount of mutation delta between a C program and the corresponding assembly instructions is significant, but people continue to believe it is not, which results in all sorts of incorrect assumptions when reasoning about a C program (such as which line of code or statement executes "first").

Haskell, Go, et. al. are understood to have complex runtime machinery atop the x86 instruction set. It's an erroneous belief that C does not (and one that I've seen developers get bitten by repeatedly as they try to manage threaded C code).

Re: C Is Not a Low-Level Language

#262

Post by hexane360 »

_fq4v wrote: post #11
occamrazor wrote: post #8

Earlier quoted context omitted.

I don’t understand. CPUs do not support C, they support a specific instruction set. What stops them from having instructions for cache management, pipelining, speculative execution hints, etc?

The Itanium processor did exactly this. Other than being a commercial flop, it was found to be quite difficult to actually get the compiler to generate good management instructions, and x86 was often able to beat out an itanium core at the same clock speed

It seems like x86 exists at a local maxima, and Itanium didn't go far enough away to find a different peak.

Re: C Is Not a Low-Level Language

#263

Post by admax88q »

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…

> The promise of JITs outperforming AoT compiled code has never really materialized.

Well JITs do actually outperform AoT compiled code today. Java is faster than C in many workloads. Especially large scale server workloads with huge heaps.

Java can allocate/deallocate memory faster than C, and it can compact the heap in the process which improves locality.

Re: C Is Not a Low-Level Language

#264

Post by elcritch »

tzahola wrote: post #232
lmm wrote: post #141

Earlier 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

That’s a great blog post!

> I agree with Ousterhout's critics who say that the split into scripting languages and systems languages is arbitrary, Objective-C for example combines that approach into a single language, though one that is very much a hybrid itself. The "Objective" part is very similar to a scripting language, despite the fact that it is compiled ahead of time, in both performance and ease/speed of development, the C part does the heavy lifting of a systems language. Alas, Apple has worked continuously and fairly successfully at destroying both of these aspects and turning the language into a bad caricature of Java. However, although the split is arbitrary, the competing and diverging requirements are real, see Erlang's split into a functional language in the small and an object-oriented language in the large.

I still strongly think Apple is taking the wrong approach with Swift by not building on the ObjC hybrid model more.

Re: C Is Not a Low-Level Language

#265

Post by mattnewport »

admax88q wrote: post #263
mattnewport wrote: post #149

Earlier quoted context omitted.

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…

> The promise of JITs outperforming AoT compiled code has never really materialized. Well JITs do actually outperform AoT compiled code today. Java is faster than C in many workloads. Especially large scale server workloads with huge heaps. Java can allocate/deallocate memory faster than C, and it can compact the heap in the process which improves locality.

I haven't seen this convincingly demonstrated. Can you point to good examples? The few times I've seen concrete claims they are usually comparing Java code with C code that no performance oriented C programmer would actually write. In certain cases Java can allocate memory faster than generic malloc but in practice in many of those cases a competent C or C++ programmer would be using the stack or a custom bump allocator.

In practice it's quite hard to do really meaningful real world performance comparisons because real world code tends to be quite complex and expensive to port to another language in a way that is idiomatic. My general observation is that where performance really matters to the bottom line or where there is a real culture of high performance code C and C++ still dominate however. This is certainly true in the fields I have most experience in and where there are many very performance oriented programmers: games, graphics and VR.

Re: C Is Not a Low-Level Language

#266

Post by sizeofchar »

favorited wrote: post #188
scott_s wrote: post #115

The author, David Chisnall, is a co-author on a related paper from PLDI 2016: "Into the Depths of C: Elaborating the De Facto Standards", https://news.ycombinator.com/item?id=11805377

He was also one of the earliest non-Apple contributors to Clang, was on the FreeBSD core team, and wrote the modern GNU Objective-C runtime implementation. His work on Objective-C in particular is prolific.

Also, his book on Objective-C is the best one I read.

Re: C Is Not a Low-Level Language

#268

Post by 11thEarlOfMar »

>403 Error - Access Forbidden We are sorry ... ... but we have temporarily restricted your access to the Digital Library. Your activity appears to be coming from some type of automated process. To ensure the availability of the Digital Library we can not allow these types of requests to continue. The restriction will be removed automatically once this activity stops.

We apologize for this inconvenience.

Please contact us with any questions or concerns regarding this matter: portal-feedback@hq.acm.org

The ACM Digital Library is published by the Association for Computing Machinery. Copyright � 2010 ACM, Inc.

Re: C Is Not a Low-Level Language

#269

Post by mar77i »

dikaiosune wrote: post #206
mar77i wrote: post #205

As far as I understood what I do about C, is that most of C's here called "quirks" have actually been enablers for much of the portability and performance of modern platforms. Therefore I don't like "undefined behavior" and the like being criticised for being such a "hindrance". I hence doubt the author's familiarity with C is much beyond the basics, which kind of makes the case for why the author also had to namedro…

from the article: > David Chisnall is a researcher at the University of Cambridge, where he works on programming language design and implementation. He spent several years consulting in between finishing his Ph.D. and arriving at Cambridge, during which time he also wrote books on Xen and the Objective-C and Go programming languages, as well as numerous articles. He also contributes to the LLVM, Clang, FreeBSD, GNUst…

I don't understand how someone who ended up working on a C compiler feels intimidated by the standard/-s such software needs to adhere to. And if such people work on a C compiler, we're not logically in for a ride of WTFs?

Re: C Is Not a Low-Level Language

#270

Post by nickpsecurity »

11thEarlOfMar wrote: post #268

>403 Error - Access Forbidden We are sorry ... ... but we have temporarily restricted your access to the Digital Library. Your activity appears to be coming from some type of automated process. To ensure the availability of the Digital Library we can not allow these types of requests to continue. The restriction will be removed automatically once this activity stops. We apologize for this inconvenience. Please contac…

I emailed them about it. Hopefully it will be fixed soon. Just keep a tab or bookmark. :)
Post reply on HN