The Unreasonable Effectiveness of C • Hacker News Board

Re: The Unreasonable Effectiveness of C

#281

Post by ori_b » Thu, Jan 10, 2013, 9:45 PM UTC

dspeyer wrote: post #193

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…

Is there any way for software, even in assembly, to make intelligent use of on-cpu ram caches? I thought they were completely abstracted by the hardware.

Yes. You read about how the cache works, and design the code to take that into account. This is usually done through techniques like cache coloring (http://en.wikipedia.org/wiki/Cache_coloring), loop tiling (http://en.wikipedia.org/wiki/Loop_tiling) and other techniques that depend on the way that the cache works internally.

In addition, many CPUs provide prefetch instructions to make sure data is in cache before it's used, or cache-skipping loads and stores to prevent polluting cache with data that's only ever touched once.

Re: The Unreasonable Effectiveness of C

#282

Post by betterunix » Thu, Jan 10, 2013, 9:45 PM UTC

angersock wrote: post #267

betterunix wrote: post #165

Earlier quoted context omitted.

"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.

How might you suggest that I write a good compression, hashing, or encryption library with a lot of bit twiddling? Any good alternatives to C?

Well, there is always Lisp:

http://psg.com/~dlamkins/sl/chapter18.html

At least SBCL will generate efficient machine language for bit vector manipulations if you tell it the sizes of the vectors (or if it can infer that information). It might just be a matter of opinion, but I would say that Lisp beats the pants off C in terms of programming; you are almost never going to have to keep track of pointers or memory allocations, you have far less undefined behavior to deal with, and it is generally a more expressive language. SBCL and CMUCL also support a non-standard feature that is similar to inline assembly language in C, the VOP system, that allows you to utilize obscure instructions or change how your code will be generated, if there is some reason for doing that (e.g. if your encryption library will use AESNI).

Of course, since you said "library," I assume you meant for this to be used in other programs, possibly programs not written in Lisp. Unfortunately, SBCL's support for that is still rough; commercial Lisp compilers may have better support for it. Of course, if you were targeting an OS written in Lisp, things would probably be different -- my view is that C's popularity is mostly a result of how many systems were written in C i.e. how much legacy code there is, and that were it not for that momentum C would be written off as an inexpressive and difficult to work with language.

Re: The Unreasonable Effectiveness of C

#283

Post by ori_b » Thu, Jan 10, 2013, 9:45 PM UTC

madhadron wrote: post #105

looser wrote: post #103

Earlier quoted context omitted.

It may be the parent comment is referring to the Runtime-Library when using the term Virtual Machine.

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

If you're going to be pedantic, use the right terms. The C language defines an 'abstract machine', not a 'virtual machine'.

Re: The Unreasonable Effectiveness of C

#284

Post by tedunangst » Thu, Jan 10, 2013, 9:47 PM UTC

deelowe wrote: post #241

runarb wrote: post #47

Earlier quoted context omitted.

It may be cumbersome, but C has string handling: http://en.wikipedia.org/wiki/C_string_handling

This is an article about the standard library. C has no built in string handling. As an example, there are embedded systems that do no have support for string types due to a lack of support for libraries that handle it, yet they are 100% compliant with the C spec.

How you can be 100% compliant with the C spec by omitting strlen is a mystery to me.

Re: The Unreasonable Effectiveness of C

#285

Post by qznc » Thu, Jan 10, 2013, 9:53 PM UTC

_yosefk wrote: post #248

madhadron wrote: post #107

Earlier quoted context omitted.

Yes. Though I tend to use PLT Racket these days when the choice of language is not constrained by other factors.

Seriously? Actual production code in ALGOL in 2013? If I ever had to deal with that code, I think I'd feel about like you would have if I wrote this comment in Aramaic because I prefer it to English on numerous grounds. I'd very much prefer the extremely unpopular Racket which is at least alive to some degree. I think the author's criteria for "effectiveness" are very much different from yours, hence the different co…

Re: The Unreasonable Effectiveness of C

#286

Post by w3pm » Thu, Jan 10, 2013, 9:54 PM UTC

michaelochurch wrote: post #188

rayiner wrote: post #177

Earlier quoted context omitted.

The "memory is just a giant array of bytes" abstraction hasn't been true ever since DRAM has existed (because DRAM is divided into pages), ever since caches were introduced, and certainly isn't true now that even commodity mulch-processors are NUMA with message-passing between memory nodes.

Fair point. At this point, it's a very leaky abstraction because not all levels of "random access" (e.g. L1 cache vs. main memory) are created equal.

True, and this is my biggest problem with writing optimized code in C -- it takes a lot of guessing and inspecting the generated assembler and understanding your particular platform to make sure you're ACTUALLY utilizing registers and cache like you intend.

If there were some way of expressing this intent through the language and have the compiler enforce it, that'd be fantastic :)

That said, there's really not a better solution to the problem than C, just pointing out that even C is often far less than ideal in this arena.

Re: The Unreasonable Effectiveness of C

#287

Post by kscaldef » Thu, Jan 10, 2013, 9:54 PM UTC

haberman wrote: post #274

C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but even that is something you can almost completely ignore if you want to build up your own parallel stack of software that does it differently. It is for this reason that C (and sometimes C++) are what people use when they have a new idea about higher-level progr…

> C is the language that doesn't force any preconceived notions about how the world should work onto you

Some preconceived notions forced upon you by C, off the top of my head:

- problems should be solved by describing a linear sequence of steps (as opposed to logic/declarative programming)

- a variable can have different values at different times in the execution of a program (in contrast to standard mathematical conventions)

- a function can return different results when called multiple times with the same arguments (again, in contrast to the standard mathematical meaning of the term)

- there is random access storage of information (with constant time access and update)

Re: The Unreasonable Effectiveness of C

#288

Post by zvrba » Thu, Jan 10, 2013, 9:57 PM UTC

cookiecaper wrote: post #30

zvrba wrote: post #4

Oh, spare me, high-level language that can't even do arithmetic properly. It's anything but "damn successful as an abstraction over the underlying machine". Case in point: Whenever you're doing signed arithmetic, and it overflows, you're in the land of undefined behaviour. (See here for an example of how this can bite you: http://thiemonagel.de/2010/01/signed-integer-overflow/ ) Another case in point: type-punning wi…

The author doesn't claim it's perfect or that there's no way to improve on it, but I think he has a very salient point, which is that most of the OO buzzwords and programming fads that come and go in "higher-level languages" simply end up making a bigger mess of things as a project grows. Basically, the author loves C because it is simple, straightforward, and restrictive -- it forces you to write [relatively] simple…

> OO buzzwords and programming fads that come and go in "higher-level languages" simply end up making a bigger mess of things as a project grows

No, it's not the language features which make a mess. It's people lacking judgement and common sense. (Like, trying to apply patterns everywhere. Been domain-specific [crypto] consultant on such a project and watched it smash the schedule by more than 2x. It wasn't the language [Java], it were stupid people.)

> sounds like he's written multiple lines of C to me

I don't contend that he's written a lot of C. I DO, however, contend that he's written some ANSI C. If you're writing ANSI C, you have to account for AT LEAST all of the following behaviors:

https://www.securecoding.cert.org/confluence/display/seccode... https://www.securecoding.cert.org/confluence/display/seccode...

For example, if f is some function, then in the sequence

    int x = 0;
    f(x++, x++);

the call to f is undefined behavior because x is modified twice without an intervening sequence point. Anybody claiming that such language is "high-level" is a moron, regardless of their "accomplishments".

Re: The Unreasonable Effectiveness of C

#289

Post by guard-of-terra » Thu, Jan 10, 2013, 10:04 PM UTC

alexkus wrote: post #18

henrik_w wrote: post #10

Earlier quoted context omitted.

Agree completely about zero build time! I've been using IntelliJ IDEA for Java development for the last 4 years, and before that I used C and C++ using Emacs for 7 years. I am way more productive in IntelliJ IDEA than I was before. One reason is the instant feedback on syntax errors when I type the code. I don't need to compile to see them, as I used to in C and C++. Another reason is the navigation support you get i…

That's the IDE not the language. Java, itself, does not highlight your syntax errors. Nor does C. There are IDEs out there that will do exactly the same thing for you for your C code.

In fact Eclipse features a special compiler that builds your code immediately and also allows IDE to highlight your errors better than any static analysis would. So actually it kind of does. Assuming compiler IS the language.

Re: The Unreasonable Effectiveness of C

#290

Post by chromatic » Thu, Jan 10, 2013, 10:04 PM UTC

haberman wrote: post #274

C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but even that is something you can almost completely ignore if you want to build up your own parallel stack of software that does it differently. It is for this reason that C (and sometimes C++) are what people use when they have a new idea about higher-level progr…

C is the language that doesn't force any preconceived notions about how the world should work onto you.

... except for a type system based on the memory model of a machine which strongly resembles the PDP-11, a compilation strategy built for machines with less RAM than my car fob, and optimization possibilities limited by aliasing, plus everything kscaldef mentioned.