Should you learn C to “learn how the computer works”? • Hacker News Board

Re: Should you learn C to “learn how the computer works”?

#291

Post by pm215 » Tue, Oct 02, 2018, 8:54 PM UTC

XMPPwocky wrote: post #232

tptacek wrote: post #220

Earlier quoted context omitted.

In what sense is stack-relative addressing, PUSH, POP, and addition/subtraction on the stack pointer not ISA-level support for stack allocation of local variables?

Addition, subtraction, and stack-relative addressing are, in most architectures I'm familiar with, generic- stack-relative addressing ends up just being a special case of register-relative addressing, and addition and subtraction are rather important instructions in their own right. PUSH/POP are more obviously "hey store your locals on the stack, kids", but on, say, x64, how often do you actually see a push instead o…

There's a reason 32-bit ARM has 'move base register down and then do some stores' and 'do loads and then move base register up' (stmdb and ldmia) rather than just plain old ldm and stm, and I'm pretty sure it's because it makes the entry and exit sequences for function calls with a stack shorter. (The ARM ISA doesn't privilege a downward growing stack, so you can use stmib and ldmda if you want your stack to grow upward; the Thumb ISA, however, does want a downward stack for push and pop.)

Re: Should you learn C to “learn how the computer works”?

#292

Post by icedchai » Tue, Oct 02, 2018, 8:56 PM UTC

steveklabnik wrote: post #118

icedchai wrote: post #108

Earlier quoted context omitted.

I don't think he is correct. The underlying representation of a pointer is not defined by the C standard. You could have a C implementation that works on segmented, non-flat architectures. Look at the C compilers from the DOS days, for example...

I think we're talking past each other, and in some ways, this is what the post is about. The C abstract machine presents a flat, uniform, byte-addressed address space.[1] The reason that it does not define what a pointer's representation is is because it needs to map that to what the hardware actually does, which is your point. 1: Actually, my impression is that it does, but this is actually an area of the spec in wh…

Yep, these common assumptions are not always true if you read deep enough into the spec. Even though they may be true in practice, only as a side effect in most implementations...

I taught myself C when I was a teenager (on an Amiga, back in the 80's.) It is amazing that almost 30 years later, I'm still learning new things about it.

Re: Should you learn C to “learn how the computer works”?

#293

Post by fmihaila » Tue, Oct 02, 2018, 8:59 PM UTC

steveklabnik wrote: post #264

fmihaila wrote: post #259

Earlier quoted context omitted.

> Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here. I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime: > There’s just one problem with this: C also operates inside of a virtual machine. I agree with the sibling comment that in this context the term abs…

In the language of the spec, it does “operate” inside the machine. Well, the spec says “execute” but that’s even more likely to be confused with a runtime thing. Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.

> Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.

Of course; I was only addressing the confusion that other posters mentioned. While one could have a C interpreter (or any interpreter), for the purposes of the article this seems to be only a marginal point. In practice, C is (almost) never run that way, but your choice of words could suggest a parallel between the C abstract machine and the Ruby or Java VMs, and I think the way usual C implementations differ from those is more informative than how they are alike.

You do explain later that the C abstract machine is a compile-time construct, but many people read selectively and react immediately, as evidenced by several posts on this page.

Re: Should you learn C to “learn how the computer works”?

#294

Post by Karrot_Kream » Tue, Oct 02, 2018, 9:08 PM UTC

t0mbstone wrote: post #130

ashleyn wrote: post #58

Earlier quoted context omitted.

C at the very least teaches the difference between stack and heap memory, a crucial concept obscured by most higher-level languages.

Just playing devil's advocate here... why is this such a "crucial" concept, for someone who is using a higher level language (like Python or Ruby)? If 99% of what that person does is gluing together APIs and software modules, and they can see their memory usages are well within range, why does it matter?

Because we haven't figured out a large body of non-leaky or resilient abstractions yet. If a higher level construct was indeed a true superset of lower level functionality, or was robust enough to be applied to a wide variety of situations, then it would be okay. Right now in web software, because we optimize for development velocity so heavily, the tools a smaller product would reach for are fundamentally different from the tools a very high load service would. Until we can come up with a set of robust higher level abstractions that scale well (or better than they currently do) then we'll be stuck where we're at. Thread pools will saturate, GC will stutter, sockets will timeout, and all sorts of stuff that higher level abstractions do not capture well.

(I kept this post vague but can offer concrete examples of you'd like)

Re: Should you learn C to “learn how the computer works”?

#295

Post by qubax » Tue, Oct 02, 2018, 9:08 PM UTC

C and systems programming to learn how software works.

Paraphrasing Churchill:

An educated person should know a bit of latin and ancient greek. And educated computer science person should know C and assembly.

Re: Should you learn C to “learn how the computer works”?

#296

Post by pcwalton » Tue, Oct 02, 2018, 9:15 PM UTC

tptacek wrote: post #54

HankB99 wrote: post #53

I stopped reading when I got to "C also operates inside of a virtual machine." Is the author confusing virtual memory with virtual machine? Perhaps they're referring to the way a high level language abstracts away the details of the H/W. I didn't care enough to read on. That said, I learned the most about "how a computer works" in a class that taught Intel 8080 assembler on a system running CP/M. (Technically it was…

I'm confused as well. Klabnik is no doubt reading this thread. I'd like to know more about the "virtual machine" he supposes the C language targets.

I suspect that by "virtual machine" he means "the C abstract machine". There's arguably little relevant difference between an abstract machine and a virtual machine—for example, Android has an AOT compiler for the Java "virtual machine".

Re: Should you learn C to “learn how the computer works”?

#297

Post by blaisio » Tue, Oct 02, 2018, 9:15 PM UTC

lmm wrote: post #246

blaisio wrote: post #69

I definitely would not consider a CS education complete without C. If you don't know C, that means you don't know how how parts of operating systems work. It definitely makes you a less useful engineer. I don't think people need to be able to code in C at the drop of a hat. But it should not be a scary thing for good engineers.

> If you don't know C, that means you don't know how how parts of operating systems work. How so? It's not like you can't write operating systems in other, more readable and understandable, languages.

Yeah I meant "operating systems used by 99% of people". I don't mean to say you need to know C to understand operating systems in general.

Re: Should you learn C to “learn how the computer works”?

#298

Post by pcwalton » Tue, Oct 02, 2018, 9:17 PM UTC

iforgotpassword wrote: post #179

fixermark wrote: post #147

Earlier quoted context omitted.

It varies from application to application. In my domain, we reach for the CUDA libraries to write the high-performance parts of our code. ;)

That requires special Hardware in contrast to C code.

Intel will not sell you an x86 processor without a GPU capable of compute these days.

Re: Should you learn C to “learn how the computer works”?

#299

Post by saagarjha » Tue, Oct 02, 2018, 9:18 PM UTC

School-Cotton wrote: post #286

geofft wrote: post #191

Earlier quoted context omitted.

> Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design. This I agree with and also I'd call the most important reason for Rust programmers to learn C. The C ABI is a lingua franca, not because it's good or pure but (as with spoken linguas franca) happened to be in the right place at the right time. It defines certain conventions and assumptions…

There is not really any such thing as "the" C ABI -- different platforms have totally different conventions, even on the same instruction set.

I'm assuming "the" C ABI probably means System V.

Re: Should you learn C to “learn how the computer works”?

#300

Post by dbaupp » Tue, Oct 02, 2018, 9:21 PM UTC

btmorex wrote: post #244

pcwalton wrote: post #185

Earlier quoted context omitted.

Our popular software stacks are written in C and C++, but that's more because of history than anything else. I rarely reach for just "classic" C for performance anymore. These days I'm more likely to reach for GPUs, SIMD intrinsics (available in Rust), or at least Rust/Rayon for code that needs maximum performance. C is fundamentally a scalar language. In 2018, the only code for which "classic" C is the fastest is co…

Except even when you think vectorized processing should be a performance win, it often isn't: http://www.vldb.org/pvldb/vol11/p2209-kersten.pdf I'd argue that GPUs and SIMD instructions have so many restrictions that they're useless for general purpose computing. Yeah, they have niche spaces, but in terms of all the different kinds of programs we write, I think those spaces are going to remain niche.

Vectorised processing is a win according to that paper: it is faster than scalar code. The key point of the paper is that compiled queries---doing loop fusion---is sometimes more of a win (in a database context, where "vectorisation" doesn't always mean SIMD as in this discussion).

Doing fused SIMD-vectorised operations will likely bring the advantages of both, with relatively small downsides. This is a relatively common technique for libraries like Eigen (in C++), that batch a series of operations via "Expression Templates" and then execute them all in as a single sequence, using SIMD when appropriate. (Other examples are C++ ranges and Rust iterators, although these are focused on ensuring loop fusion and any vectorisation is compiler autovectorisation... but they are written with that in mind: effort is put into helping the building blocks vectorise.)