[Klug-general] Obscure C at saturday's meeting

[Thomas Edward Groves]

Reminds me of my answer to an interview question:
which resource is most important in developing a program?
Answer: that which is in shortest supply.
Then it was memory and cycles, now it's skilled manhours.

Tom
  ----- Original Message ----- 
  From: David Halliday 
  To: Kent Linux User Group - General Topics 
  Sent: Wednesday, December 01, 2010 2:23 PM
  Subject: Re: [Klug-general] Obscure C at saturday's meeting


  In many contemporary cases (I have seen some examples otherwise) the cost of extra hardware to run a heavy application is lower than the cost of a developer to optimise code.


  Especially when optimising the code makes that code harder to maintain or causes the next developer who looks at it days lost in understanding what is going on. 


  If optimisation across the board increases the man hours by one month and then increases the time for a new developer to understand it then you have covered some significant hardware upgrades (Lets face it a stick of RAM costs less than one day of contractor time). 


  TCO rears its interesting and confusing head.


  The obvious exceptions to this are things like hardware drivers and the difference between highly optimised code and badly (sometimes this is semi accidental) written inefficient code (Recently had an application using very high amounts of memory because it was loading thousands of large objects when it only needed to load an ID and one other attribute).


  On 1 December 2010 14:12, Mike Evans <mike at tandem.f9.co.uk> wrote:


      OK I understand that in the scheduler you want good performance and
      compact code to get the most out of it, but some things were never meant
      to be written.


    This may have been true once - but hasn't been so for a long time.  This is because an optimising compiler will produce the same or better machine code from simply written, well structured and legible program code.

    I remember (about 18 years ago) in a quick panic wanting to slow something down and just added:

    for (i=0, i<1000, i++) /* do nothing */;

    Yes - I know I should have used sleep(), but never mind.  This didn't make the code slow enough, so I changed it to:

    for (i=0, i<1000000, i++) /* do nothing */;

    and it didn't take any longer.  When I stopped the compiler at the assembly stage and looked at the machine code what the compiler had actually done was the equivalent of:

    i=1000000;

    Served me right really.  Valuable lesson though: write the code as clearly as possible and let the compiler optimise.  It will probably do a better job than me, and will introduce fewer bugs in the process.



    _______________________________________________
    Kent mailing list
    Kent at mailman.lug.org.uk
    https://mailman.lug.org.uk/mailman/listinfo/kent





------------------------------------------------------------------------------


  _______________________________________________
  Kent mailing list
  Kent at mailman.lug.org.uk
  https://mailman.lug.org.uk/mailman/listinfo/kent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/kent/attachments/20101202/e1a7f990/attachment.htm>