[erlang-questions] At what point am I "playing compiler"

[Dennis Byrne]

Yes, I agree with this. I put it in a certain category of "classic
mistakes", such as the 'big rewrite' or the assumption that doubling a
team size will result in a 2x improvement in productivity.  I have
however it a little helpful to know a thing or two about the
compiler/runtime optimizations of a platform because it often allows
me to convince others just how silly some optimization efforts are.
They are also just plain fascinating.

Dennis

On Mon, May 18, 2009 at 5:48 AM, Joe Armstrong <erlang@REDACTED> wrote:
> Thus spoke ye great masters:
>
>  [Kernighan and Plauger:
>   Elements of programming style 1974]
>
>    "Write clearly - don't be too clever"
>    "make it right before you make it faster"
>    "keep it right when you make it faster"
>    "make it clear before you make it faster"
>    "don't sacrifice clarity for small gains in 'efficiency'"
>    "Don't diddle code to make it faster - find a better algorithm"
>
> Knuth, quoting Hoare,  blessed be their names, spoke thus:
>
> "We should forget about small efficiencies, say about 97% of the time:
> premature optimization is the root of all evil.
>
> Knuth also wrote (though I can't find the reference) that it was not
> worth optimising
> something that got called less that 10^9 times (I think that's right)
> - he wrote that something like 20 years ago, so today the advice must
> be 10^12 times :-)
>
> I once met a guy who was optimizing a large FORTRAN program
> he was going to shave 10 minutes off a three hour batch job. I asked how often
> the program would be run - "about once every three months" - I asked
> him why he was doing this - "because I'm paid to do it"
>
>                                                              - o O o -
>
> At the start of any project you should have a time budget - the person who
> commission the code should say "this code must do its job in N seconds".
>
> Your job is to write code that is as clear as possible that executes
> in under N seconds.
>
> So you write your code as clearly as possible, then time the code. If the time
> is under N you stop - otherwise you measure where the time goes and optimize.
>
> To go back to you original question:
>
>           How often does you code get called? - how fast should it be?
>
> If you answer "Dunno" and "as fast as possible" then my answer would be
> "since you don't know how often the code is to be called then choose
> the clearest
> solution"
>
> If you know the answers then you can measure and see if your code is
> fast enough -
> then you choose the clearest version that is fast enough.
>
> Without knowing how fast it should take you cannot answer the question
> "is this fast enough".
>
> This is the difference between a specification and an
> implementation. The specification tells you how fast it should take,
> what it should do etc. The implementation tells you what it actually does.
>
> An implementation is only correct with respect to a specification - without
> a specification the notion of "best anything" is meaningless.
>
> Why do we want the "clearest version" - because most of the time
> efficiency is irrelevant (Knuths 97% figure ...) - and most of the time the
> largest cost of a program is in maintenance where understanding what
> the code means
> is vital.
>
>
> /Joe
>
>
>
> On Mon, May 18, 2009 at 8:38 AM, Valentin Micic <v@REDACTED> wrote:
>> Was it Joe's rule that goes like this:
>>
>> "Make it run first, and then optimize later -- only if you have to"
>>
>> Stick to this rule, and the life will be good to you.
>>
>> V.
>>
>> -----Original Message-----
>> From: erlang-questions-bounces@REDACTED
>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Dennis Byrne
>> Sent: 17 May 2009 07:12 PM
>> To: erlang-questions@REDACTED
>> Subject: [erlang-questions] At what point am I "playing compiler"
>>
>> The functions expressive/0 and efficient/0 have the same result.
>> Sometimes I prefer expressive syntax but I am concerned about
>> efficiency.  Should Erlang developers worry about this or do any of
>> the compilers (or runtime) make these concerns obselete?
>>
>> expressive() ->
>>        List = [1,2,3],
>>        Last = lists:last(List),
>>        Min = lists:foldl(fun min/2, Last, List),
>>        Max = lists:foldl(fun max/2, Last, List),
>>        Sum = lists:foldl(fun sum/2, 0, List),
>>        {Min, Max, Sum}.
>>
>> efficient() ->
>>        List = [1,2,3],
>>        Last = lists:last(List),
>>        lists:foldl(fun summary/2, {Last, Last, 0}, List).
>>
>> summary(X, {Min, Max, Total}) ->
>>        {min(X, Min), max(X, Max), Total + X}.
>>
>> sum(X, Y) ->
>>        X + Y.
>>
>> min(X, Y) when X < Y ->
>>        X;
>> min(_, Y) ->
>>        Y.
>>
>> max(X, Y) when X > Y ->
>>        X;
>> max(_, Y) ->
>>        Y.
>>
>> --
>> Dennis Byrne
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>



-- 
Dennis Byrne