Author: Dann Corbit
Date: 19:57:08 06/23/04
Go up one level in this thread
On June 23, 2004 at 22:16:36, Russell Reagan wrote: >On June 23, 2004 at 21:03:33, Dann Corbit wrote: > >>I don't think I have ever disagreed with any post more than I disagree with this >>one. >>;-) > > >Yeah, yeah. It's not the first time someone has said that about something I've >written :-) > > >>My point: >>1. Write clear code. >>2. Choose good algorithms. >>3. Write abstract code that hides the implementatiion details when possible. > > >The advice, as it is usually given all over the internet, only consists of what >you have written below. By itself it is not bad advice, but I think it is >incomplete. I think it is possible for someone to obey points 4 and 5 and still >have a slow program. Your advice is more complete, and if someone followed it, >they could work their way out of a bad situation since the abstractions grant >more flexibility. > > >>4. When everything works well, profile it. >>5. Speed up the stuff that will benefit from it. > > >I'm not saying the advice should include, "Optimize early and often!" I'm saying >it should include, "Don't ignore optimization issues." That isn't to say that >you start micro-optimizing right away. Just keep those issues in mind. These >guys say it better than I do. > >Bjarne Stroustrup: > >"A good design cannot ignore basic efficiency requirements." This means nothing, as is. It is like saying, "You should write good programs." Bjarne also spouts things that are pure nonesense from time to time. An example which is pure horse excrement is: "Good C programs also tend to be good C++ programs." It is simply not true. >Scott Meyers: > >"I have a two-pronged approach to efficiency. First, when you're designing the >application, you have to consider efficiency. I'm assuming that you, as the >designer, are designing something you know something about. You must make some >educated guesses about where you think performance bottlenecks will and will not >exist. That means efficiency might appear early in the design, just because you >know certain things about the application in general. I don't think it's >inappropriate to keep efficiency in mind when you design. You don't want to >design something that will be inherently inefficient. > >The first prong of my two-pronged approach, then, is to keep efficiency in mind >from the beginning. Don't completely ignore efficiency up front in favor of fine >tuning later. You shouldn't bend over backwards for efficiency up front. Design >so things will be efficient enough most of the time. Shoot for clear, >straightforward, and maintainable code, but try to avoid introducing gratuitous >inefficiencies. > >The second prong is fine tune later with profiling. If you find some bottlenecks >in the program by running it and profiling, then go back and rewrite the >presumably localized parts of the code to improve efficiency. > >Serious efficiency problems arise when people design systems with the attitude >that, "We're just going to worry about correctness first. We won't even think >about efficiency until later." The results have been pretty disastrous." The generalizations he gives above might have some credibility, but they are stated very badly. You should select algorithms intelligently. However, microoptimization at design stage or early coding stages is pure lunacy. This is better than what Meyers said: http://www.stevemcconnell.com/cctune.htm I do know of a million dollar project that was scuttled by a bubble sort (and disk based at that!) But that is an example of a bad algorithm choice. I know of many large chunks of code that were ruined by attempts of optimization, and projects that were delayed or scuttled because programmers were trying to make things faster that did not need to go faster. Here is a piece of food for thought: http://groups.google.com/groups?q=matrix+sort++group:comp.lang.c+author:dik+author:winter&hl=en&lr=&ie=UTF-8&selm=Dw7KD5.8vF%40cwi.nl&rnum=1 Some links: http://c2.com/cgi/wiki?PrematureOptimization http://www.flounder.com/optimization.htm http://billharlan.com/pub/papers/A_Tirade_Against_the_Cult_of_Performance.html A nice quote from here: http://www.faqs.org/docs/artu/optimizationchapter.html "Don't just do something, stand there!" http://www.cocoadev.com/index.pl?PrematureOptimization http://www.faqs.org/docs/artu/ch15s07.html http://www.cs.unc.edu/~stotts/COMP144/lectures/lect34.ppt http://en.wikipedia.org/wiki/Performance_tuning http://www.ai.mit.edu/~stefie10/optimization.html For sure, I agree with Knuth. That's almost always true. Now, as you know, there is almost nothing I would rather do than make a program run faster. But it should be correct first. Fast later. That does not preclude good design decisions.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.