[ale] gcc

[Jeff Hubbs]

Stephen Turner wrote:

>well im a noob to compilers especially linux so please
>forgive my ignorance.  how optimized can gcc optimize
>code? i almost started to learn about assembly but
>just read up a bit on it, from what i understand
>assembly is the machine code, it is specific to only
>an athelon  or only a k6 etc, (unless they share the
>same code?) asembly is the instruction set the
>processor speaks right? ahh well i just wanted to
>know, i want to get my code as optimized as possible
>and also wanted to experiment with it. please input :)
>
Probably the best way to think about it is to first consider just the 
x86 and x86-compatible world.  gcc goes "down" to Intel i386 and when 
you use Red Hat and Debian (among others), that is what the gcc 
invocation for your prepackaged binaries has aimed for.  However - 
again, just within x86 for this discussion - successive processors have 
changed in two key ways:  instruction set augmentation and internal 
architecture.  Intel's Web site probably has block diagrams of the 386 
all the way to the P4 that you can compare; you've got an evolution in 
instruction pipelines, registers, etc. and then there are additions to 
the instruction set, as were represented by Intel's MMX and AMD's 
3DNow!.  If you're writing compilers and you're very clever, you can 
make your compiler kick out code in such a way as to take advantage of 
the features and changes in successive CPUs.  Whereas i386 code can run 
on all that is x86 to the present day (you do this when you run your 
stock Red Hat on a P4), the reverse is not true and if you try, you risk 
having your code BURRRP really bad, like, fatally.  

Just to clarify, assembly is a crude programming language in which the 
commands are simply mnemonics for machine code.  It's the difference 
between "ROTLA" and "01001101".  For your purposes, the assembly code is 
about as "deep" as you can practically go.

Once you've invoked gcc for a specific processor, you're unlikely to be 
able to improve on the result.  However, because this is Open Source, 
you can study the code you run and determine if there is anything you 
can do to it that will benefit you somehow.  You might want to emphasize 
speed or memory footprint or you might want to clean up some I/O.  You 
might study some code looking for sections you can rewrite in hopes of 
gaining some improvement.  Of course, that which you rewrite had better 
work the same as the original or you might really hose stuff up.  This 
exercise will help teach you to test as you code, Extreme-Programming 
style.  In other words, to use your example, if you compile for K6 and 
run on Athlon, you'll probably be golden whereas if you compile for 
Athlon and run on K6, problems may arise.  The machine code will not be 
hugely different between the two, but they will be different and quite 
possibly in ways that will burn you if you try to run code for the 
Athlon on the K6.

A few years ago, I used to manage a data center and my main app was 
written in COBOL and ran under VMS on Alpha AXP.  Memory consumption was 
a big problem because the two machines in the production cluster would 
each eat up their 1GB of RAM apiece as they bore the strain of over 300 
users.  Even though I didn't know COBOL, I was still able to take a 
COBOL book and our source code and experiment with taking sections that 
I thought could have been rewritten to be more RAM-friendly.  I recall 
taking a section made mostly of conditionals and rewriting it using 
whatever the COBOL equivalent of the Pascal CASE statement is.  I 
recompiled the section and got a significant reduction in image size, 
which led me to believe that a comprehensive but careful review of the 
source code probably could have turned up a fair amount of memory 
footprint reduction


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.