The Myth of Speed

Why everyone thinks C is the fastest thing evar?

I don't think anybody thinks that. Obviously writing code in assembly is the way to achieving most performance, but that isn't portable. C is almost portable assembly, thus it's one of the faster languages.

Most C code can be compiled fairly straightforwardly to ASM, and the performance is somewhat predictable. C also has many limitations when it comes to how well you can abstract, and it lacks powerful metaprogramming features.

no exceptions

>>2
Most C code can be compiled fairly straightforwardly to ASM
you seem confused. maybe you shoulnt program at all.

>>4
MAYBE YOU SHOULD MY ANUS

>>2
Homework: write a compiler for harvard architecture microcontrollers

>>6
I just wrote an assembler for one. Do you love me now, daddy?

>>7
Is that you, /prog/snake?

>>2
It depends on the architecture.  A lot of times code written in C is faster than code written in ASM.

>>9
Not really, it's impossible to make the best compiler (NP-hard,...), and C compiles to platform specific code(ASM), so you can always improve upon the generated code or write better code yourself. It's another question how well can a human compiler take advantage of the CPU architecture(for example: compilers tend to be smarter when it comes to scheduling), but it's common to be able to do better than the "sufficiently decent compiler". Wether there's any point in humans wasting their time doing that is another question...

>>10
Go back to programming "Hello World" in your basement if you actually think you can hand code better ASM than a compiler for any real program.

>>11
I never inspect my compiler's output

>>12
I use Microsoft's compiler so I do have to.

13
Now you have two problems.

>>14
He's probably got 99 problems.

I can't believe people seriously think that compilers generate decent code.

Go compile x264 or libavcodec or whatever with ASM disabled and see if you can even approach half of the speed you had before.

Even intrinsics suck aplenty (usually ~30% slower than proper ASM, can be 5% if you're lucky or 50% if you're not) and they only require the compiler to solve the "easy" problems (register allocation and maybe scheduling if your CPU is too sucky).

Of course it's not really viable to write everything in ASM, but the notion that a shitty compiler (that is: all of them) can even approach any assembler programmer worth his salt is alien for anybody with experience.

When I'm debugging stuff I'm still amazed at the limitations of modern compilers. They even let trough stuff that a simple peephole optimizer would catch, specially GCC.

>>15
But my compiler ain't one.

>>15
While I do agree with you, the 'two problems' meme is part of the /prog/scape.

>>17
Using MickeySoft is a waste of a perfectly good computer. You certainly do have over nine thousand problems.

>>19
Keep compiling with your GCC.

LOL

>>18
/prog/::Meme<"two problems"> m;

>>17
hit(&me)

>>22
If you're having Linux problems, I feel bad for you neckbeard.

>>10
a "perfect compiler" solves the halting problem, so you're quite correct.
>>11
Mike Pall can.

writing a medium sized program in ASM:
    20,000 hours, 100% speed, portability 10%
writing a medium sized program in C:
    1000 hours, 80% speed, portability 50-100% depending
writing a medium sized program in JAVA:
    20 hours, 30% speed, portability 100%

>>23
The year is 94 and in my comp is Forth
And in my TCP ports is the mothafuckin law
I got two choices, y'all, shut down the comp or
Counter-DOS the devil put the bandwidth to the floor

>>25
Making up figures on /prog/:
  0.01 hours, 5% speed, portability 50%

>>25
Figures are somewhat wrong.
Here's my own figures from my own recollection,
Some archiving program:
- 5 hours + 5 hours spent debugging in Asm
- 4 hours + 3 hours spent debugging in C
- 1.5 hours + ~20 minutes spent debugging in C#
- 45 minutes (debugging time included, each function was tested live after writing) in Lisp.

I'm sure some programmers out there that write perfect code won't need the debugging time, but I'm not a perfect programmer.
Regarding speed, ASM and C performed roughly the same, when C was compiled with high optimization settings. C# was fairly fast as well, but the runtime has some fixed loading time, which makes it slower to run. The Lisp implementation does have its loading time as well, but it's not an issue if you're like me and keep it running all the time. It would be an issue if you loaded it each time. Overall speed was about 3 times slower than the C version.
C code was C89 compatible, and Lisp didn't make use of anything non-standard except for sb-ext:*posix-argv* when ran from the command line, but that's trivial to make de-facto portable.
C# code is portable, except it only runs on Microsoft's .NET and MONO, so it's slightly less portable than C or the Lisp code, but it doesn't matter in practice, as I don't need it running on that many platforms.

>>27
you know they're right.
only somebody whose time is worthless would program in ASM willingly

>>29
There are some uses. I'm glad those making decoders/encoders(codecs) for various video/audio formats are such speed/optimization freaks. For example, x264 has most of the routines are written in C, then rewritten in ASM for specific platforms. Many other multimedia apps follow the same route. This has resulted in huge speedups in encoding times, which is beneficial to a lot of people. While I know x86 asm myself, I avoid writing ASM unless absolutely necessary or I really need the speedup. It's all about how well one can balance the need for speed and the need for abstraction/portability.

>>29
I'm sure all those people that wasted their time writing kernel code in asm, when it could have been written so much faster in python, will be upset to hear that [/sarcasm]

>>31
The amount of minimum needed asm code in the kernel and library runtime isn't that huge, but that code is needed for either doing things which are not possible to do portably in the language in which they're implementing the OS/language or things which require very compact/fast code(such as thunks/multi-processing code which is ran very often). It's fair to say that anyone writing an OS or language which natively compiles is going to have to write at least some assembler.

>>31
Most kernels that are written after the invention of Python are written in C.

I find it funny people actually think that code written in ASM is faster than code written in C.  You can make code written in ASM as fast as code generated by a decent compiler if you want to hack your way through it (manually unrolling loops, etc.), but even if you do that you are going to be roughly the same speed as code generated by a compiler if you are lucky. 

Of course, this is talking about real programs, not the 10 line fibs that most of you saying ASM code is faster than compiled are probably writing.  Also, this is using real-world ASM coders and C compilers.  Yes, there is still reasons to use ASM, and you can write ASM code that is faster than code generated by a compiler, but not programs.

>>29
Nobody's time is worth anything. People who program in ASM just like to program in ASM.

>>34
My CISC processor has a FIBS intruction :P

>>31
kernel code authors generally try to keep ASM to the bare minimum.
99% of kernel code is written in C

>>34
Few compilers can actually generate efficient code which takes advantage of the latest and greatest new instructions some CPUs provides(SSE/MMX for x86 as an example), which is why a lot of optimized multimedia code is written in asm.

>>38
SSE and MMX are not the best examples there.

C is the fastest thing evar.