[erlang-questions] At what point am I "playing compiler"
Toby Thain
toby@REDACTED
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
> <dennisbyrne@REDACTED> 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 <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
>>> 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: 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
>> _______________________________________________
>> 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
More information about the erlang-questions
mailing list