Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unreasonable Effectiveness of C

damienkatz.net

Post reply on HN
Print view View original

161–170 of 394 posts

Re: The Unreasonable Effectiveness of C

#161

Post by betterunix »

looser wrote: post #130
madhadron wrote: post #105

Earlier quoted context omitted.

No, I am referring to the virtual machine defined by the C language.

If C makes use of a virtual machine, then why we have to recompile it for every new machine/platform?

"Virtual machine" in this context refers to the computation model of the language. In C, that model is essentially a single-CPU machine with a big memory space that can be accessed with pointers (including a possibly disjoint memory space for program code).

Other models are possible; for example, lambda calculus and combinator logic are based on a model where computation is performed by reducing expressions, without any big memory space and without pointers. Prolog is based on a model where computation is performed by answering a query based on a database of rules. These are all "virtual machines" -- the realization of these computation models is based on compiling a program for a specific machine. It is not different with C; C just happens to use a model that is very similar to the real machine that a program executes on (but it is not necessarily identical e.g. you probably do not have so much ram that any 64-bit pointer would correspond to a real address on your machine).

Re: The Unreasonable Effectiveness of C

#162

Post by kscaldef »

I take significant issue with this paragraph:

    When you write something to be fast in C, you know why 
    it's fast, and it doesn't degrade significantly with
    different compilers or environments the way different 
    VMs will, the way GC settings can radically affect 
    performance and pauses, or the way interaction of one 
    piece of code in an application will totally change
    the garbage collection profile for the rest.
The implementation of malloc & free that your C implementation uses significantly impacts performance (both time and space) just like the choice of GC implementation in other languages. It is not uncommon for memory fragmentation to be a serious problem for large or long-running C programs, and at the point that you have to start worrying about that and working around it, you've broken the abstraction in just the same way that the author complains about for Java, Erlang, Haskell, etc.

Also, as others have pointed out, performance can also depend significantly on how well C's machine model maps to the actual machine architecture you're running on.

Re: The Unreasonable Effectiveness of C

#163

Post by popee »

madhadron wrote: post #104
DigitalJack wrote: post #74

Earlier quoted context omitted.

I'm pretty ignorant about this stuff, so please don't think I'm trolling. I'm confused when you speak of a virtual machine with regard to C... can you explain what you mean by this? I had to wikipedia the Burroughs machine. I guess the big deal is that it's a stack machine? It looks very interesting and I plan to read more about it. But I guess I don't understand why that is a hindrance to C. The JVM is a stack machi…

The Burroughs was a stack machine, but that's only the beginning. Look at how it handled addressing hunks of memory. Bounds checked memory block references were a hardware type, and they were the only way to get a reference to a block of memory. So basically, null pointers didn't exist at the hardware level, nor out of bounds writes to arrays or strings. Similarly, code and data were distinguished in memory (by high…

C doesn't care for fancy terms like VM, multicore, threads, ... But you can always make libary and implement what you need. This approach has advantages, for example you can share memory pages between processes, because that kind of stuff are part of hardware/OS, not C language. It would be stupid to implement it directly in C language. You will now say that it is reason why C is bad, i say it is reason why C is so popular all these years.

Re: The Unreasonable Effectiveness of C

#164

Post by eropple »

minimax wrote: post #92
michaelochurch wrote: post #83

Earlier quoted context omitted.

I'm also a novice on low-level stuff, but if I had to guess... I'd guess that the virtual machine of C pertains to the addressing and the presentation of memory as a "giant array of bytes". Stack addresses start high and "grow down", heap addresses start low. These addresses need not exist on the machine. For example, two running C processes can have 0x3a4b7e pointing to different places in machine memory (which prev…

C pointer aliasing defeats certain compiler optimizations that can be made in other languages, and is frequently brought up in C vs FORTRAN comparisons. I think that's probably what the GP had in mind.

C99 includes restricted pointers, but support is a bit spotty. Microsoft's compiler (which is of course really just a C++ compiler) includes it as a nonstandard keyword, too.

http://en.wikipedia.org/wiki/Restrict

Re: The Unreasonable Effectiveness of C

#165

Post by betterunix »

papsosouid wrote: post #116
madhadron wrote: post #53

Oh for heavens' sakes. Yet more ignorance. A more realistic view of C: - C is straightforward to compile into fast machine code...on a PDP-11. Its virtual machine does not match modern architectures very well, and its explicitness about details of its machine mean FORTRAN compilers typically produce faster code. The C virtual machine does not provide an accurate model of why your code is fast on a modern machine. The…

None of what you said supports your initial claim that the author is ignorant. In fact, even if we pretend that everything you said is true, none of it contradicts the article, or the authors conclusions. Yes, C has lots of areas where other languages are better. And yet, it is still the most practical language to use because of the combination of things that it does well.

"it is still the most practical language"

Only in extremely limited contexts: low-level code for operating systems that happened to have been written in C. Otherwise, there is a better language for pretty much every use-case of C.

Re: The Unreasonable Effectiveness of C

#166

Post by anonymfus »

Thrymr wrote: post #15
cageface wrote: post #2

C is a fantastic high level language. Nonsense. This sudden C fad is totally baffling to me. C is a great language for low-level work and it does have an attractive minimal elegance but is in absolutely no sense of the term a high level language . A language with next to no standard containers or algorithms, manual memory management, raw pointers, a barely functional string type and minimal standard library and concu…

> C... is in absolutely no sense of the term a high level language. Of course it is. You're not worrying about how many registers your CPU has, or when you swap a register out to memory. All that has been abstracted away for you. The fact that you can access memory locations directly gives you some low-level access, but in a very real sense C is a high-level language. There are higher-level languages with more abstra…

> You're not worrying about how many registers your CPU has

But you need to worry about size of registers. How many modern languages have basic data types without strictly defined sizes?

Re: The Unreasonable Effectiveness of C

#167

Post by pimentel »

kscaldef wrote: post #158
pimentel wrote: post #111

"C is a weak, statically typed language" Wouldn't that imply that a variable of one type could be coerced into another type? I would say C is strong typed...

C is weakly-typed. You can cast anything to anything else and the compiler won't stop you.

That's right! Completely forgot about the cast.

Re: The Unreasonable Effectiveness of C

#168

Post by emeraldd »

pimentel wrote: post #111

"C is a weak, statically typed language" Wouldn't that imply that a variable of one type could be coerced into another type? I would say C is strong typed...

> Wouldn't that imply that a variable of one type could be coerced into another type?

Yup! It's quite common to cast things from a void * to a more specific one. You do it every time you call malloc.

Re: The Unreasonable Effectiveness of C

#169

Post by bunderbunder »

peterevans wrote: post #69
ryeguy wrote: post #33

Earlier quoted context omitted.

The problem is that the "level" of a language is relative to other languages. If C is a high level language, that means you can group it into the same pool as Java, C#, Haskell, Python, and Ruby. Don't you see a bit of a difference here? Unless there is a significant number of actual languages , not concepts , that are below C, it logically has to be called a "low level language" because there really isn't much below…

Here's the thing: "high-level", when applied to a programming language, has a historical context. It means something specific (see: http://en.wikipedia.org/wiki/High-level_programming_language ), and what it means and has always meant is that the language in question abstracts away registers and allows structured programming (as in, through the use of if, while, switch, for, as opposed to using labels and branching).…

Here's the thing: The English language is polysemous. Computer science jargon even more so.

Meaning that any particular term can often have many gradations of meaning. So "X means Y" does not necessarily imply "X does not mean Z". Especially when Y and Z are similar concepts.

I suppose we could lament the inherent ambiguity of the jargon, but the truth is that for the most part problems only result when ambiguous language is used in combination with an argumentative person armed with equal measures of pedantic zeal and failure to grasp the fundamental characteristics of natural language. Without that element, for the most part any reasonably knowledgeable person should be able to figure out which of the particular meanings is at play from context. For example, even though the term "high level language" is used in multiple ways, the statement "C is not a high level language" is not all that ambiguous, even when considered in isolation. As long as you're willing to grant that the person making the statement is not an idiot, then it's trivial to determine that they weren't using the "everything but machine and assembly language" definition.

Re: The Unreasonable Effectiveness of C

#170

Post by AnIrishDuck »

jbooth wrote: post #97
rootbear wrote: post #73

Earlier quoted context omitted.

Can you elaborate on your first point a bit? How, specifically, does C's machine model not fit current architectures well, aside from multiple cores. How is Fortran's model better?

C is based on a simplistic view of the computer as a turing machine (or von neumann machine, if you'd prefer). Since the 70s or 80s, CPUs have gotten a lot faster while memory access has only gotten incrementally faster. This means that CPU manufacturers have put an increasingly sophisticated caching system on the CPU die to speed up access to main memory contents. C's simple model allowing pointer arithmetic, aliase…

Pointer aliasing can cause additional problems with today's multiple dispatch CPUs, which are nothing like the CPUs of the 80s. Because pointer aliasing ties the compiler's hands, compilers may have trouble reordering code to maximize a single core's instruction level parallelism.
Post reply on HN