The C Programming Language - Part 0 (oncoding.posterous.com)

In general, compiler-generated assembly is on par with naieve hand-written assembly. It's not going to beat something that anyone put any real time into, but if time to market matters at all, you're not going to be able to put large amounts of time into hand-coding assembly.

A good, clever human can generally beat a compiler.

There's a reason that the core of nearly any high performance multimedia, graphics, or encryption library is written in assembly, or compiler intrinsics (which are pretty much assembly instructions written in C syntax)

For decades people have said that compiler's code generation is at par... and it slowly has become more true. I read a lot of disassembly listings and I'm often pleasantly surprised at how clever some of the code is. However, there's also plenty of times where I see plainly wasted instructions as well.

That's not the real reason that assembly is often not worth it, even in situations where it once was. The real culprit is that for a long time CPUs were outpacing memory in speed gains, so a cache miss became more and more expensive relative to the clock speed.

This meant that more and more micro-optimization work has gotten focused on cache behavior. C gives you just as much control over how your data structures are stored as assembly would. Maybe you'll need to define some prefetch() macros depending on your compiler, but that's about it.

There are certainly some remaining cases where you really want to control things at a register-allocation level (encryption, codecs, fancy floating-point things) However, most projects are better off focusing on improving their memory behavior rather than trying to get to that cache miss in 80 instead of 82 cycles.

The other huge shift in performance-oriented computing is, of course, the availability of more and more CPU cores. Again, lots of work to do but assembly doesn't give you any advantage at all.

So even if you're good enough at writing assembly to beat the compiler (and most people aren't) you probably should have been spending your optimization effort on other things.

Yes, compiled C or C++ is almost always better. This is a major reason why the Microsoft compilers no longer support inline assembly code on the 64-bit architectures. (you can still link in assembled binaries of course)

This brings to mind another reason why the statement "Wrong: use Assembler Language" is so goofy. You're never going to use assembly language. You're going to use 99.9% C or C++ and a bit of assembly language. "Use C if you want something to go as fast as possible" is still basically correct.

Here's a good example: http://article.gmane.org/gmane.comp.lang.lua.general/75426

Granted, it's a niche case, though an important one -- using a switch statement for bytecode dispatch leads to poor branch prediction in VMs, and better alternatives require either non-standard extensions (http://eli.thegreenplace.net/2012/07/12/computed-goto-for-ef...) or assembler.

If you're really concerned with performance when writing C, try to avoid painting yourself into a corner. Profile. Consider custom memory allocators, if much of your time is spent creating short-lived or equal-sized objects. In general, look at the tricks the really hardcore game devs do in C++.

Also, use valgrind, because you'll probably cut too many corners. ;)

I thought people stopped writing Assembly a while ago but I recently interviewed at Apple and I interviewed with one group that deals with optimizations for vector mathematics using special hardware on the A4/A5 chips and he said they still write some code in Assembly because for performance reasons.

You can take better advantage of SIMD instructions and keep more performance critical things in registers for example.

As a fan of C, I have to disagree. To quote OS X's `man signal`:

    void (*signal(int sig, void (*func)(int)))(int);

    or in the equivalent but easier to read typedef'd version:

    typedef void (*sig_t) (int);
    sig_t signal(int sig, sig_t func);

In, say, Go, this would be

    func signal(sig int, newFunc func(int)) func(int)

which imo is cleaner (it's clear that the second argument and return value have the same type, without having to use a typedef) without sacrificing power.

Only one of those sets of flaws is significant.

You can be a phd mathematician and still do arithmetic wrong. And for my next trick I'll argue the semantics and usage of "idiot" in the quoted passage (exercise left for reader).

Why? These two people are clearly idiots.

It is a simple rule. Never trust user input, the issue has been known for decades and everybody should be aware of it by now.

DWM is going to be rewritten in Go.

Minor semantic point:

    Pretty much anything that's not a function is considered to be an object.

In general, the definition of object is incredibly wishy-washy and the word really ought to be retired, but as it stands, I don't think many people would agree that just any old piece of non-function data is an object. Different languages/people/formal systems have different definitions; for example, in Python, functions are themselves objects, while Java makes a clear distinction between objects and non-object primitive types like ints.

Mind you, this is as much a criticism of the original article's usage as yours; from a certain point of view (e.g. C++'s), C of course supports 'objects' inasmuch as you can store function pointers in structs and consequently have run-time selection of functions, after a fashion. From another point of view (e.g. Alan Kay's), even C++ does not have objects, because it lacks true message passing. The real criticism is that the term 'object' is so vague as to be essentially meaningless without clear context.