C Is Not a Low-Level Language • Hacker News Board

Re: C Is Not a Low-Level Language

#201

Post by zkomp » Tue, May 01, 2018, 8:53 PM UTC

dgreensp wrote: post #95

rhacker wrote: post #76

The article itself has 4 definitions or "attributes" for low-level languages that can be considered contradictory: * "A programming language is low level when its programs require attention to the irrelevant." * Low-level languages are "close to the metal," whereas high-level languages are closer to how humans think. * One of the common attributes ascribed to low-level languages is that they're fast. * One of the key…

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, Lisp

Re: C Is Not a Low-Level Language

#202

Post by qsdf38100 » Tue, May 01, 2018, 9:03 PM UTC

"processors wishing to keep their execution units busy running C code" What? This is non sense, the processor is not running C code! The processor can only run machine code, regardless of the language used to write the source code.

Re: C Is Not a Low-Level Language

#203

Post by dragontamer » Tue, May 01, 2018, 9:08 PM UTC

jstimpfle wrote: post #181

munificent wrote: post #128

Earlier quoted context omitted.

C leads you to believe that memory access has uniform cost regardless of address. What is the perf cost of: *foo Depending on what foo points to, and which memory you have previously read, the cost can vary by close to two orders of magnitude on many chips. C does give you the ability to control those costs, but controlling how you lay out your data in memory and controlling imperatively in which order you access it.…

> But the language doesn't show you those costs in any way. I think it's pretty clear. Access memory sequentially, and you can expect to hit the cache. Access more memory than the cache size in a random order, and you can expect to pay memory access latencies (100s of CPU cycles). I doubt you would be willing to manage the cache yourself in every line of code. That would be a lot of code. Some programmers might want…

> Access memory sequentially

Except memory is virtual. Memory location 0x1000 might be forward, or backwards compared to 0xFFF, depending on the state of the Translation-lookaside buffer (TLB).

Ever notice how (when ASLR is disabled), programs all start at the same location?? (https://stackoverflow.com/questions/14795164/why-do-linux-pr...)

Hint: Virtual address 0x0804800 doesn't belong at physical address 0x0804800. The OS can put that memory anywhere, and the CPU will "translate" the memory during runtime.

This means that in an obscure case, going forward a linked list (ie: node = node->next) may involve FIVE memory lookups on x86-64

* Page Map Lookup

* Page Directory Pointer lookup

* Page Directory lookup

* Page Table lookup

* Finally, the physical location of "node->next".

An even more obscure case (looking at maybe address 0xFFFC, unaligned) may require two lookups, for a total of 10-memory lookups (the page-directory walk for page 0xFFFC, and then the page-directory walk for 0x1000).

There is a LOT of hardware involved in just a simple "node = node->next" in a linked list. Its not even CPU-dependent. Its OS configurable too. x86 supports 4kb pages (typical in Linux / Windows), 2MB Large Pages and 1GB Huge Pages.

Re: C Is Not a Low-Level Language

#204

Post by Avshalom » Tue, May 01, 2018, 9:12 PM UTC

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…

One of the big problems with predicting what can be MIMDed is that almost all the languages we use except for Haskell allow for dependency on who knows what. With out very strict refusal of state it's hard as fuck to figure out what is independent of what at compile time.

Not that it can't be done so much as getting programmers to accept it is can't be done.

Re: C Is Not a Low-Level Language

#205

Post by mar77i » Tue, May 01, 2018, 9:14 PM UTC

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 namedrop Spectre and Meltdown, which were caused by the fact that later optimizations were unsound, ie. the Tomasulo algorithm.

The problematic with the article somewhat remind me of the problems with LCTHW, and that the author of LCTHW was unable to figure out what the deal was about had been admitted by themselves. https://zedshaw.com/2015/01/04/admitting-defeat-on-kr-in-lct... Sorry to re-repost this article again. I just somewhat perceive two variants same "smells" in both.

Re: C Is Not a Low-Level Language

#206

Post by dikaiosune » Tue, May 01, 2018, 9:17 PM UTC

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, GNUstep, and Étoilé open-source projects, and he dances the Argentine tango.

If tango experience isn't enough to make his opinion credible, I imagine being an LLVM and Clang contributor are pretty good qualifications.

Re: C Is Not a Low-Level Language

#207

Post by Avshalom » Tue, May 01, 2018, 9:22 PM UTC

ori_b wrote: post #187

munificent wrote: post #180

Earlier quoted context omitted.

> The fact that it's not giving you a great idea of exactly what's happening in the transistors is irrelevant The author's point is that what's happening in the transistors is relevant — not controlling it is what led to Spectre and heavy performance losses if you aren't smart about cache usage. Thinking of C as a "low-level language" makes it easier for people to overlook that fact.

And the parent's point is that there should be a distinction in level between Haskell and C, for example.

Then we need a finer grained taxonomy instead of the current model that is essentially: machine code;c/forth; literally everything else.

I mean that should be blindingly obvious anyway looking at the actual history of programming languages and CPUs but here we are in 2018 insisting that we must have exactly three categories with exactly the definitions of: assembly;C/forth; everything else.

Re: C Is Not a Low-Level Language

#208

Post by jburgess777 » Tue, May 01, 2018, 9:23 PM UTC

posterboy wrote: post #197

pera wrote: post #65

Earlier quoted context omitted.

I'm not an expert, but I don't think the optimization phase should be really considered here: the same kind of pattern matching used by (e.g.) LLVM to find optimizable sequence of statements also could be used by any assembler. NASM for instance offer some level of optimizations, so I think optimization should only be considered when it's part of the language specification itself, like in Scheme. IMO C is close to lo…

C cannot read the overflow bit after an ADD, because of it's abstractions ... so I would say modern ASM is still lower in some aspects because it has less constrains and more importantly, it is less expressive, which is the whole idea of this hierarchy. The compiler should offer a macro for that. Then the question is whether to take the specification or the implementation at which point it's an absurd question to beg…

> C cannot read the overflow bit after an ADD ... The compiler should offer a macro for that.

If you use GCC then __builtin_add_overflow() is what you are looking for:

"The compiler will attempt to use hardware instructions to implement these built-in functions where possible, like conditional jump on overflow after addition, conditional jump on carry etc."

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

Re: C Is Not a Low-Level Language

#209

Post by antris » Tue, May 01, 2018, 9:23 PM UTC

skybrian wrote: post #174

munificent wrote: post #93

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…

It seems like the article is mostly useful for inspiring research; that is, most of us aren't the target audience. I'm wondering what will happen as GPU's become more general-purpose. What's next after machine learning? Would it be possible to make a machine where all code runs on a GPU? How would GPU's have to change to make that possible, and would it result in losing what makes them so useful? What would the OS an…

> It seems like the article is mostly useful for inspiring research; that is, most of us aren't the target audience.

As a group of professionals, it is highly beneficial for us to be interested in these things. People who design languages and compilers do it largely on what is perceived as being demanded, and us as programmers are the ones that create the demand for new languages.

To put in other words, if programmers aren't aware of what's going wrong with our current languages, they cannot express their need for new languages. So, there's less incentive for researchers to produce new ways of programming computers. It is much more tempting to "please the masses" in a way that causes this local-maximum problem. It's much more interesting to research problems that translate into mainstream use than academic things that nobody actually uses.

Re: C Is Not a Low-Level Language

#210

Post by Hemospectrum » Tue, May 01, 2018, 9:26 PM UTC

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.

In a nutshell: Too much pointer chasing. C# actually does much better than Java here, with its features for working with user defined value types, but it could still improve by a lot.