HS>Maybe some people don't rely on compilers to compile the fastest code
HS>possible.
ROFL!  In a few years, when you've learned a bit more about programming,
differences in the code different compilers generate, how different
switches and optimizations can radically change the generated code,
programming for different platforms or even similar platforms but
different CPUs, etc., you'll realize just how incredibly funny that
statement is!! 
There is only so much you can do algorithmically in a HLL.  There comes
a point where it is very much up to the compiler as to how well / fast
the resulting executable runs.
For example, switching from a bubble sort to a quick sort might decrease
your run time from O(N^2) to O(N log N), but then after that, it's up to
the compiler whether it generates code that needs 10 seconds for 'x'
items, or 20 seconds for the same 'x' items.
Does the compiler generate inline ABS() and memcpy() functions or are
they so dumb they require calling a library routine.  When it transfers
memory, does it do it a byte at a time, or is it smart enough to take
advantage of things like 32 bit registers which can move 4 bytes at a
time.  Does the compiler automatically align things on word boundaries,
or does it generate code where a variable can be misaligned and require
more memory accesses?  Does the compiler allow generating better 486
level code, which is tuned to the way a 486 CPU operates, or does it
generate code for cruddy, slow 386s?
For many things, such as the few I mentioned above, you _have_to_depend_
on the compiler, because there is a good chance they are outside of your
control, and even if not, they might be dependant upon the user setting
or not setting some particular switch that may not be the default or
that may interact with some other switch.
--- QScan/PCB v1.19b / 01-0162
---------------