

How to Write Fast Code - techdog
http://asserttrue.blogspot.com/2009/03/how-to-write-fast-code.html

======
lallysingh
I'm glad to see people talking about one of the four stages of optimization:

1\. Do we have to optimize this? Time is never free, and opportunity cost in
terms of engineering effort is usually very significant.

2\. Can we do less work? (this article)

3\. What's the bottleneck? CPU, FP, memory bandwidth, lock contention?

4\. How do we squeeze out better performance? Assembly, loop unrolling, etc.

I usually cringe when I hear about people talking about #4, as very few of
them have asked #1, #2, or #3 yet.

And usually, you just hear people talking about doing what the compiler's
already doing (writing it in assembly? /The compiler already does that/),
usually doing a pretty reasonable job at high optimization levels. They just
exchange maintainability for the warm fuzzy feeling that they've been as macho
as needed.

~~~
stcredzero
Profile, Profile, Profile!

Use the 80-20 rule. 80% of your code's time is spent in 20% of the code.

Optimizing without good profiling is like painting a portrait blindfolded.

Pre-optimizing by coding your system to be "fast" before you get to profile it
is like starting to paint a portrait before your model is even sitting.

When Kent Beck came in to optimize the Chrysler C3 payroll system, he
discovered that one of the biggest time-sinks in the system was _string
concatenation_!

It's also useless to optimize before you have a system that runs correctly.
Kent also asked how he could validate the C3 system so he could optimize it.
He was told it wasn't even producing correct results yet. He replied: "In that
case I can make it run _really_ fast!"

~~~
signa11
one of my very favorite quotes of all times:

 _What are the facts? Again and again and again---what are the facts? Shun
wishful thinking, ignore divine revelation, forget what "the stars fortell,"
avoid opinion, care not what the neighbors think, never mind the unguessable
"verdict of history"---what are the facts, and to how many decimal places? You
pilot always into an unknown future; facts are your single clue. Get the
facts!_

    
    
                     - lazarus long

~~~
dinkumthinkum
Nice. :) Clearly, I am a fan!

------
bsaunder
I'm personally fascinated by the notion that efficiency and transformation
seem to be intertwined. Hard problems can sometimes seem simple with a slight
transformation in either the problem description or the data. Even the article
is suggesting that to write fast code, transform your perspective of the
problem. Do less. There seems to be something fundamental here.

~~~
signa11
and hence Xerox-PARC slogan "point of view is worth 80 iq points"

------
arien
This is the kind of advice that points at something so obvious that you really
never thought about it and feel silly once someone points it out :)

~~~
cperciva
Unfortunately, this advice falls into a very common category: Simple, obvious
in hindsight, and completely wrong.

Modern CPUs do not "execute a fixed number of instructions per second"; even
leaving aside the fact that certain instructions are faster than others,
factors such as the order in which you access memory locations and the
predictability of branches can easily result in a tenfold difference in
performance.

In many cases, code can be made faster by executing _more_ instructions; I
recently dealt with some code where changing a (theoretically) O(N) algorithm
to an O(N log N) algorithm and increasing the number of operations by a factor
of 10 nevertheless resulted in the code running twice as fast. Now, this was
an extreme case -- the code went from accessing completely random memory
locations to accessing completely sequential memory locations -- but it
demonstrates the importance of memory access patterns.

~~~
calambrac
The punchline, "To go fast, do less", is certainly not _completely_ wrong.
Sure, there may be exceptions here and there, but in general, this is good
advice (and if you know enough to know when it's bad advice, you probably
didn't need it anyways).

If you're using a higher-level language like Python or Ruby, worrying about
things like locality should be pretty low on your performance checklist.

~~~
cperciva
_If you're using a higher-level language like Python or Ruby, worrying about
things like locality should be pretty low on your performance checklist._

If you're using Python or Ruby for CPU-intensive applications, you probably
don't have a performance checklist.

~~~
calambrac
If you think that this advice applies only to CPU-intensive applications,
you're missing the point. Unfocus your programmer brain and look past the fact
that he said anything about some processor being able to perform a fixed
number of instructions per second, and absorb the larger message: to go fast,
do less. This could include IO, this could include retabulating some statistic
just when it's needed instead of on every insertion, this could include
handling special cases ahead outside of a loop body, etc. CPU-level
optimization should usually be one of the very last things you care about (and
yes, this depends, and again, if you already know the exceptions, you don't
need this advice).

And Python and Ruby both have excellent C bindings, you can rewrite CPU-
intensive portions of your application pretty much anytime you need to.

~~~
cperciva
_And Python and Ruby both have excellent C bindings, you can rewrite CPU-
intensive portions of your application pretty much anytime you need to._

Of course. But at that point you're writing your CPU-intensive code in C, not
in Python or Ruby. Saying "Python and Ruby are fast because they can call C
code" makes no more sense than saying "Humans are really good at arithmetic
because they can use calculators".

~~~
calambrac
I didn't say "Python and Ruby are fast because they can call C code". I
responded to your claim that people using Python or Ruby for their
applications don't have performance checklists, which is bullshit - part of
that checklist (towards the bottom, hopefully) is _refactor important bits to
C_.

------
iamwil
Isn't the old adage: "the fastest code is the one you never run?"

~~~
psadauskas
Or the one ezra touts: "No code is faster than no code."

------
froo
It's an unbelievably simple statement that is applicable to many different
situations, not just computer related stuff.

For example, right now I'm detailing some design principles for a project I'm
working on.

I realise there is a limited amount of time to be able to complete the project
effectively and to make it look decent, so in the process I've come to make
some hard choices.

I've found the trying to be creative with less is working out well so far and
in the end it should pay off.

------
dualogy
Off-topic maybe, but: "How to Write Code Fast", now can someone point me to
literature for _that_? Highly appreciated!

~~~
godDLL
Try the UNSW YouTube lectures with Richard Buckland, one of them mentions
"problem solving" through abstraction, targeting and planning; and may well be
what you're looking for. <http://www.youtube.com/watch?v=q1I7WKncE64>

------
zandorg
Or split your workload up so it can be run on 200 cores in an instant. Not to
advertise, but I'm not affiliated with Nvidia -
<http://www.nvidia.co.uk/page/tesla_deskside.html>

------
yawniek
"no code is faster than no code" (comes from yehuda katz afair)

------
10ren
I get the feeling that "John" is a literary device for the alter-ego of the
author.

------
ezmobius
no code is faster then no code.

