Re: 12 Misconceptions

Evenbit wrote:
language implementations" but the *same algorithms*. Both are
hand-coded. Both source files are compiled. What is the difference?

The difference is that with a HLL like the C++, the compiler does the
instruction selection, register allocation, spilling etc.

With a HLL, you cannot really control that well what instructions will
be used to implement a statement. Example:

float x = y / 4.0f;

You cannot really know if there will be a floating-point division
instruction, a floating point multiplication instruction, or integer
ALU instructions *emulating* one or the other of these two or something
completely different that doesn't even spring to mind.

First you have to know the architechture the code is being compiled
for. If it is ARM w/o floating point instructions in hardware the
emulation is a possibility. If it is a platform with floating point
instructions, we are interested in the compiler that is being used and
the compiler switches that are being used. It is possible that the
division is implemented with a reciprocal multiply instead, in other
words a multiply with a constant float(1.0 / 4.0).

A lot of programmers who use C and C++ program for the Intel x86 /
AMD64 microarchitechtures and that creates a situation where a lot
these programmers are accustomed to making a lot of architechture
spesific assumptions about endianess and sizes of datatypes, alignment
and other related issues. When code spawned from this group is compiled
for other architechtures it will fail.

Using assembly for the wrong reasons just like "optimizing" code for
the wrong reasons is error plain and simple. Writing code in a specific
way because it is faster is an error plain and simple. Code should be
written to be readable and easy to follow with clean and logical
structure. If the result is fast enough or even faster than it ever
needs to be, the job is done. If it is too slow or barely fast enough
then there is room for improvement. The first step is to identify where
the problems are. Then fix them and move on.

Never make code more complicated than it needs to be. So what if you
can make some piece of code twice the performance if no one is ever
going to notice. Also, the fastest or "best" code doesn't win in the
market place. Code that does the right thing before the competition has
the best shot. When you already have the market share, you can improve
the code -- if you even need to. Is Microsoft spending their time
optimizing Windows? No, they are spending their time adding features to
sell their product and fixing bugs that make them LOOK bad. The
appearance is everything.

If your software crashes, you lose. If your software is too slow to be
usable, you lose. If it does what the customers want and they don't
notice the bugs you have, you win. It's simple as that.

This said, I always aim higher than "barely passes" standards but that
is only because I really love crafting things. I don't expect the same
standard from everyone but that is only because I am disillusioned by
the way things work. Let's face it: Good Enough is what wins, always
has, always will in software. The software application only needs to
have the APPEARANCE of being the best, it does't HAVE TO BE THE BEST.

It is sufficient to appear to be the best (in terms of code) to
function correctly and be fast enough. No more is required. The rest is
user interface, how the application looks, the graphics the workflow,
how it avoids annoying idiosynchronies and so on. When code works that
is enough. Really.

Talking about few parallel threads in this group. The size of
executable doesn't matter. Really. Gosh. Is there ANYONE out here with
smaller than a 10 GB harddrive on their computer? Anyone? Bueller?

How many executables / programs / blah blah you have installed? What
difference does it make if they are 1 MB or 10 KB? Anyone still on a
honest-to-God dialup modem here? Blah? I assume that I am not the only
one here who noticed that virtually all software these days come with a
reasonably small (< 2 MB) executable and then HUNDREDS of megabytes of
data. Why is that? In this kind of situation what difference would it
make to have smaller executable? Kekeke?

It is possible to write tiny executables with Visual C++, but it's NOT
WORTH THE HASSLE. You can load most runtime libraries as dynamic
libraries with LoadLibrary() in WIN32 and therefore reduce the size of
the executable a great deal, the import libraries even take tens of
kilobytes (!GASP!AIR!) etc. but that is just extra work to avoid, what,
having a few kilos added to executable size. I think MOST people have
better things to do.

***.

.