Re: optimizing compiler against iaverage assembly programmer.

"Graham C. Hughes" <graham.hughes@resnet.ucsb.edu> wrote:


>Are all assembler programmers conspiracy theorists? People don't
>write large scale editors, OSes, compilers, and other things in
>assembler because it's too hard, not because there's some mythical
>organization devoted to pushing MFTLs.


Of course, you don't use assembler for those tasks. That would really
be a waste of time. Being a full time games programmer, hand written
assembly is certainly needed for the speed. A lot of graphics
programming has to be done in assembly to achieve the great speed.
Usually this is tight loops somewhere in the program. A smart
programmer definitely profiles his program to find where most of the
execution time goes, and writes parts of that code in assembly if
possible. Texture mapping being an obvious example where this will
have an enormeous impact on execution speed.


Anyway you look at it, a human can optimize a small portion of code to
run much faster than a compiled version. The human has a big
advantage, he knows what the routine is supposed to do, and can do a
lot of dirty tricks that work in that special case. A compiler often
have to think of the general case. This is especially true for CISC
CPU's like the Pentium. Today one have to be very careful about
rearranging code to be able to utilize the CPU to it's fullest (e.g.
both pipes in the Pentium). Most compilers I have seen are not very
good at actually performing this shuffling of the instructions to be
able to pin that blazingly fast routine. As an example that I think a
compiler can not do is to execute some of the code in a loop before
entering a loop to be able to shuffle the instructions in any order
one want. The easiest example being to move e.g. an "inc eax" up
before it is actually needed, and perform a "dec eax" before entering
the loop. I'd like to see a compiler do stuff like this.


Of course, a human spends several hours (often days) just to make that
one loop go really fast, in contrast to the compiler that spends a
couple of minutes compiling the whole program. I'd like to see a
compiler that you can give a task and tell it to "optimize this" and
let it do some crunching for a couple of hours. Actually it can
probably shuffle instructions to test all valid combinations and time
them much faster than the average assembly programmer can do by
hand. Sort of how you make a computer beat a human in chess.. :)


On another side, it's hard to think about the fact that your code
should run on several generations of X86 CPU's, so one tend to
optimize for the computer you run your code on. That lightning fast
code for the Pentium might not run so well on the Pentium Pro... :(


John


-----------------------------------------------------------------
    John Christian Lonningdal - http://www.lis.pitt.edu/~john
  john@lis.pitt.edu - Ph: (412) 521-9386 - MSIS at Univ. of Pitt.
[x86 compilers don't do much global optimization because the instruction
set is so irregular and there are so few registers. Hoisting operations
out of a loop is pretty standard on RISC compilers. -John]




--

Return to the comp.compilers page.
Search the comp.compilers archives again.