"Anonymous1157" said: Assembly is supposed to be really fast when compiled, even if the actual code is impossible to read. Your knowledge of computer architecture is... disturbingly small. Let me enlighten you.
ALL C code (and most other compiled non-VM languages) are translated to assembly on compiling. From there, it's a one-to-one mapping from the assembly commands into the (usually) 32 bits that make a processor instructions. Vocabulary: One 'compiles' a C program with a compiler, one 'translates' assembly code with an assembler.
Assembly isn't fast by nature. The opportunity you have when writing assembly is that you are programming the machine directly, without compilers interfering. Thus, it is possible to optimize stuff a LOT. Indeed, compilers need to be very careful with optimizations, because they do not know what code is supposed to do and a wrong optimization could break the code - a really bad thing for a compiler to do. However, with the assembly code, it might be possible to do the optimization your self.
However, it's also VERY easy to write code that runs a LOT slower in assembly. Poor knowledge of the computer you are writing for might contribute to this. Certain combinations of instructions run slowly. For example if you access memory, it takes a couple of clock cycles. If you need that data the very next step, the processor needs to stall the instructions, and you lose a few cycles. Do this a million times in a loop, and your code runs on (say) 25% the speed it could run. Reorder your instructions, and the code will run 4 times as fast. Assembly is a fickle beast, and you need to study computer architecture to be able to use it efficiently. Compilers are pretty good these days, so I highly suggest you don't do it .
|