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.
>>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...
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.
>>22
If you're having Linux problems, I feel bad for you neckbeard.
Name:
Anonymous2009-12-08 19:14
>>10
a "perfect compiler" solves the halting problem, so you're quite correct. >>11
Mike Pall can.
Name:
Anonymous2009-12-08 19:18
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%
Name:
Anonymous2009-12-08 19:25
>>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
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.
Name:
Anonymous2009-12-08 19:52
>>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.
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.
Name:
Anonymous2009-12-08 20:16
>>29
Nobody's time is worth anything. People who program in ASM just like to program in ASM.
>>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.
My sick CFLAGS will take on your ASSembly cireclejerk anyday. Don't be shy, come up with your best optimizations. Oh wait, you don't have CFLAGS right? More like ASSFAGS right?
Aye carumba! Are you absolutely sure you've got enough CFLAGS in there? How
about adding -O3 and -ffastmath in there for good measure...?
Seriously, the root of your problems here, is the insane CFLAGS you have set.
Just because a certain flag is recognised by GCC, doesn't mean it's necessarily
a good idea to go playing with it, unless you're familiar with what it does, and
what the consequences are.
Likely, due to the abuse of these flags, your system is most likely messed up
beyond all repair. (FUBAR, as some of my mates would call it... I'll leave it
to others to derive the definition of that acronym)
Might I suggest, trimming back on the CFLAGS (e.g. I'd recommend "-O2 -pipe
-march=athlon-xp" and leave it at that) and see how that goes. You may also
need to rebuild glibc and other components of your system -- so it may be easier
to reformat and reload.
The performance gained by CFLAGS on x86 is minimal at best -- largely because
the machines are still basically overclocked 386's at their core. RISC
architectures (e.g. MIPS) can benefit by compiling to a particular ISA and CPU,
(e.g. throwing in -mips4 on an SGI O2 will get it humming nicely) however, going
beyond that only causes major headaches.
In short though, the only thing gained by lots of CFLAGS is über instability,
horrendous compile errors, and next to no speed gain.Aye carumba! Are you
absolutely sure you've got enough CFLAGS in there? How about adding -O3 and
-ffastmath in there for good measure...?
Seriously, the root of your problems here, is the insane CFLAGS you have set.
Just because a certain flag is recognised by GCC, doesn't mean it's necessarily
a good idea to go playing with it, unless you're familiar with what it does, and
what the consequences are.
Likely, due to the abuse of these flags, your system is most likely messed up
beyond all repair. (FUBAR, as some of my mates would call it... I'll leave it
to others to derive the definition of that acronym)
Might I suggest, trimming back on the CFLAGS (e.g. I'd recommend "-O2 -pipe
-march=athlon-xp" and leave it at that) and see how that goes. You may also
need to rebuild glibc and other components of your system -- so it may be easier
to reformat and reload.
The performance gained by CFLAGS on x86 is minimal at best -- largely because
the machines are still basically overclocked 386's at their core. RISC
architectures (e.g. MIPS) can benefit by compiling to a particular ISA and CPU,
(e.g. throwing in -mips4 on an SGI O2 will get it humming nicely) however, going
beyond that only causes major headaches.
In short though, the only thing gained by lots of CFLAGS is über instability,
horrendous compile errors, and next to no speed gain.