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

Toby Thain <>
Tue May 19 23:20:10 CEST 2009


On 19-May-09, at 5:43 AM, Alexander Wingård wrote:

> Joes words are very wise, however in the world of commercial software
> development; there are a lot of things that have higher priority than
> performance: Meeting deadlines, implementing new features and not
> messing with things that work.
> ...
> Premature optimization might be the only optimization you will ever
> get paid to do.

Aren't we actually paid "to solve the problem"? That may or may not  
require making a prototype go even faster. No "need": No need to pay.

--Toby

>
> Alexander.
>
>
> On Mon, May 18, 2009 at 4:46 PM, Dennis Byrne  
> <> wrote:
>> 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 <>  
>> 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 < 
>>> avantgard.com> 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: 
>>>> [mailto:] On Behalf Of Dennis  
>>>> Byrne
>>>> Sent: 17 May 2009 07:12 PM
>>>> To: 
>>>> 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
>>>> 
>>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> 
>>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>
>>
>>
>> --
>> Dennis Byrne
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list