This is the talk page for discussing improvements to the Program optimization article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated B-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||
|
To-do list for Program optimization:
|
I've done the assessment very quickly, the article still feels like having some issues. For instance, the "premature optimization" mantra has been added over and over without a global review, so the article needs a global restyling to fix this. --Blaisorblade (talk) 12:02, 7 January 2009 (UTC)
'Software Optimization' redirects here. In the UK that would be spelt 'Software Optimisation', which currently does not redirect here. I don't know how to do it, but if we could have that redirect here too, that would be very handy, as I keep on landing on the search page, wondering what I've done wrong. 152.78.162.177 (talk) 14:39, 24 October 2011 (UTC)
I know you may say load balancing is a performance tuning not optimization but one likely says "optimize the whole system by balancing load" so. -- Taku
About this addition
I know this completely sounds awfully redundant for computer programmers. But what I found is that often people who have no knowledge about compliers assume optimizers actually covert code written by human to better, efficient code. And of course, we know what's not actually happening. At18, sorry but I think your revision misses this point. I will try once again. See and fix if needed. -- Taku 22:44 May 14, 2003 (UTC)
I think this article tries to discuss too many distinct topics at once, and should be split into different articles discussing compiler optimizations, manual optimization by humans, and performance tuning of large systems with things like load balancing. They can cross-link all they like, but this article isn't focused enough, in my opinion. Derrick Coetzee 15:39, 15 Nov 2003 (UTC)
Remember the other uses of optimization in computer science. I've written programs to optimize the efficiency of routing of bulk cargo ships and done outline design for a system to optimize the crude oil shipping system of the Kuwait National Oil Company and there's the ever-present travelling salesman optimization problem (which the other two are somewhat representative of). This article seems more about code and compiler optimization that the whole spectrum of optimization in computer science. I think that Derrick made a good point and that this article needs to cover the general concepts in a shallow overview, then link to the detailed articles for specific techniques in each field. JamesDay 12:34, 17 Nov 2003 (UTC)
"Premature Optimization" gets redirected to this page - I don't think it should. Premature optimization is a subtle problem which isn't obvious to a novice. That's why Donald Knuth chose to highlight it. I'd like to see some rules of thumb or red flags which signal that an optimization is premature. Something like, when someone says "this will improve performance two-fold and we can easily manage the slight increased risk", or, as the project nears completion, there is a mad rush to implement a few more performance improvements before release.
I agree with Exophase 100%. I've been in the Snes homebrew development scene for a long time and there certainly are a lot of arrogant pricks who use this phrase as an excuse for sloppy horrible code. The Snes always had a bad reputation for having a slow cpu because of this reason. They complain about how they optimize their finished code for so long and not seeing a significant speed increase. I always advise them to program their code consistantly efficient to begin with, so they don't have to worry about it later, but they never take my advise and incorrectly quote the phrase "premature optimizations are the root of all evil" and continue writing sloppy slow code thinking that they can fix all their problems at the end. (UTC)
I dont know exactly what parts of the article are inspired by the cited source 'the art of programming'. I know of one book entitled like that, but it has no real focus on optimization. Instead, since D.E. Knuth is cited several times in this article, the real source may be his book, 'the art of computer programming'. Am I wrong ?
King Mike
Well, this is a classic, isn't it? (regardless if this article is too long or not). Ripper234 20:35, 2 April 2006 (UTC)
Improving about 20% of code is often responsible for 80% of the results contradicts with 90% of the time is spent in 10% of the code, and only 10% of the time in the remaining 90% of the code Sjord 17:59, 14 April 2006 (UTC)
in the article it says that python is a "very high level language". I would say very high level languages are Domain-specific_programming_languages (DSLs). IMHO Python is just a high-level language and it's definitely no DSL!
--Riedel 21:57, 19 July 2006 (UTC)
This article should also address hardware and energy aspects of efficiency and optimization. But it does not currently address them at all, and has no links at all to any such info!-69.87.202.60 12:05, 17 May 2007 (UTC)
The link
refers to an article requiring paid subscription to read. WP:EL guidelines state: "6. Links to sites that require payment or registration to view the relevant content." should general be avoided. If the IEEE is hosting it, I expect it is a classic article. Nevertheless, it's not accessable without payment. Is it OK to remove the link? Regards, --Camacan 03:33, 26 July 2007 (UTC)
It appears to me that this topic starts out correctly -- talks about system optimization -- then goes right down into talking about optimizing pieces of code. But these are two separate beasts. The comments about premature optimization (by Knuth and others) focuses on optimizing pieces of code. But note -- many of these quotes are very old -- 30 years or so. And they are applicable to that domain (code optimization) but not to systems optimization which holistically cover the entire infrastructure.
What do you think? SunSw0rd 17:58, 13 November 2007 (UTC)
The section on interpreted languages is bullshit. Interpreters usually work in 3 phases: parsing the source into a series of tokens, parsing the tokens into a syntax tree, and then interpretation of the syntax tree. By far, the most computationally expensive is the last phase, because that's where the code is actually executed. Removing extraneous whitespace and comments only affects the first phase (the lexical analyzer), which is already extremely fast.
This section is really talking about size optimization over networks. This has nothing to do with interpreted languages. You see this for any form of data. For any data, whether it is source code, executables, or plain media, it is better to have smaller sizes so it takes less time to transfer over a network.
In conclusion, I suggest this section be removed, and possibly replaced with an obvious "data should be optimized for size to speed transfer over networks" statement.
--72.177.62.3 (talk) 22:58, 11 December 2007 (UTC)
The macros section seems inaccurate to me. First, the claim is made that C preprocessor macros are mainly limited to performing the same function as inline. I've seen this argument before, which has led people to largely condemn macros as inline is safer and more practical. In reality, C preprocessor macros are capable of many of the same things that Lisp-like macros or C++ templates are. This is because they do not merely expand to text limited to one pass but will also recursively expand all expansions. This allows macro names (or parametric parts of macro names) to be passed as macro parameters, and although the expansion is either very wide and specific or very general (as opposed to something mixed like what template specialization allows) it can be hierarchically arranged to minimalize the amount of redundant macros needed to allow for specialization. I've seen few people actually use CPP macros in this fashion but it can be done and it's quite powerful (and I regularly program with this technique).
Second, I don't understand what kind of claim is being made that "compiled code" is substituted in Lisp-like macro systems. Compiled code is neither modified nor inserted. Macro expansion is as much textual expansion as the CPP style is, it merely has more facilities for pattern matching, hygiene, self recursion, specialization, etc. It's certainly a much more powerful system however.
I'd appreciate it if some others who feel experienced with these topics could give their input. I feel that this entire section should be rewritten, although it might not really belong in this node to begin with.
Exophase (talk) 19:53, 8 February 2008 (UTC)
In my opinion, this section does not belong at all. Macros (whether C++ or Lisp like) offer some performance efficiencies at the cost of parsing and compilation time, but such efficiencies rarely apply to the concept of optimization being discussed in the main article. I suggest removing this section completely. 97.117.232.119 (talk) 03:55, 27 September 2008 (UTC) Faraz Babar.
I agree that macros are a much broader topic than optimization. Specifically, I think of macros as a "poor man's automatic programmer", and if used intelligently they can turn your source code into something that gets closer to a domain-specific-language. I suppose that will raise some people's fur. MikeDunlavey (talk) 22:06, 7 November 2008 (UTC)
I agree with Faraz Babar that the section on macros is not directly relevant to optimisation, or at least certainly does not warrant such expansive coverage. It implies that macros are of themselves an optimisation technique, which they are not - it is possible to degrade performance with a macro in C through multiple evaluation of argument expressions. It is also incorrectly placed as a sub-section of "When to optimize" —Preceding unsigned comment added by 217.40.148.115 (talk) 10:05, 13 March 2009 (UTC)
"In some procedural languages, such as C and C++, macros are implemented using textual substitution, and so their benefit is mostly limited to avoiding function-call overhead."
Anyone that's read the inlining article on wikipedia would know that removing the function-call overhead is the -least- effect that inlining code has. Constant folding and dead code removal have a far greater impact. I'm not game to change it myself, as I don't know anything about functional programming languages. Themania (talk) 10:19, 5 April 2008 (UTC)
The third paragraph of the opening:
is a mishmash of several ideas; I tried to edit it and was unable to find a good way to handle it. Any suggestions?
I see the following points:
Which of these need to be covered in the opening, and need they all be in this paragraph together?
CRGreathouse (t | c) 04:33, 11 February 2008 (UTC)
I totally agree with Exophase, hand coding can benefit from experience and good practise far more than a compiler can ever be capable of. A compiler can not do what a cleverly designed JIT 'compiler' can do for instance. I know, because most of my programs have been designed by me that way for 40 years plus, since I realized the advantages around 1968. My code was also exceedingly robust, far more so than most other compiled or otherwise and usually clearer, shorter and built on decision table lines showing each decision type and actions clearly. I still believe Assembler is the easiest language to write good code in, far more efficient than C and, properly documented is actually easier to maintain. It is a myth that Assembler cannot be produced economically and using macros, can be actually shorter than equivalent HLL stuff. See [[1]] for a branch table example where SWITCH/case style branch table is implemented in about 4 machine instructions with no comparison at all!81.129.233.212 (talk) 14:34, 17 September 2008 (UTC)
"With modern optimizing compilers and the greater complexity of recent CPUs, it takes great skill to write code that is better than what the compiler can generate, and few projects need resort to this ultimate optimization step. Although a large amount of code written today is still compiled to run on the greatest percentage of machines. As a result, programmers and compilers don't always take advantage of the more efficient instructions provided by newer CPUs."
I have to disagree, in the case of streaming instructions and common assembler optimisations the only skills required are to be able to write assembler and to know of their existence. Its very easy to out do even the MS C++ compiler with some asm... my first foray into assembler programming was for just this purpose and was so easy that my horribly inefficient inline assembler was faster. Even simple stuff like the memcpy and memset packaged in the latest runtime libraries for MSVC++ can be easily optimised by using unrolled loops and the non-temporal copy instructions... Certainly nothing more skillful than just using the provided instructions as they were intended to be used.
Another classic example is that you have to specify the instruction set in the MSVC++ compiler, whereas it is easy (though time consuming) to write code that operates on all Intel CPUs utilising the SSE/SSE2 etc... instructions as appropriate.
I think its just that these technologies are still relatively new to the compiler and so the support is not yet full or powerful. I'm sure the compilers and libraries will catch up, but there will forever be new technologies available that will allow people with knowledge of them to outdo the compilers...
Of course this only applies to a small set of optimisations, its certainly not easy in all cases... but in many cases where you want to do it it is.
I find it disappointing that assembly programming is labelled as "something hard that you probably don't need", when really its easy and useful... particularly when you run out of optimisations to do... you may even find that optimising memcpy or memset will provide a signifcant boost (in a ~512x512 software triangle renderer used in Winamp AVS the speed gain from zeroing memory with assembler was about 3-4fps, from 27fps up to about 30fps).
I'm going to edit this statement to remove the "great skill" part, it seems out of place even once I ignore my personal feelings on the matter... "it is most often diffcult" is better imo... —Preceding unsigned comment added by 194.168.3.18 (talk) 15:28, 25 March 2008 (UTC)
oops... not logged in -- Jheriko (talk) —Preceding unsigned comment added by 194.168.3.18 (talk) 15:31, 25 March 2008 (UTC)
I might have missed it in the "unbulleted lists" presented at the end of this article, but a discussion of AST-based optimizations seems to be conspicuous in its absence. There are other forms of "optimization" in computer science that don't necessarily center on code rewriting and rearrangement; caching comes to mind. SqlPac (talk) 03:01, 19 September 2008 (UTC)
Use of multi-core processors, multiple threads and other concurrent processing techniques have been totally omitted from this article. (I added a reference on the list). But really in this age it is one of the key techniques to optimising software with regards to time. (Even on a single-core processor, using multiple threads will often be faster as the operating system is often able to slice up the processor time more optimally). — Preceding unsigned comment added by 141.228.106.150 (talk) 09:56, 11 October 2012 (UTC)
I have a comment on the Trade-offs section. It don't doubt that there is an optimal trade-off curve between, for example, time and memory usage in an algorithm. However, the reader should be given to understand that very few programs (as opposed to theoretical algorithms) are actually on that curve. In my experience, many programs can be improved in both time and memory usage, and thus be brought closer to the curve. MikeDunlavey (talk) 15:50, 8 November 2008 (UTC)
This is what 99% of the article is discussing. Attempting to generalize this to XXX optimization in computer science, e.d. disk defragmentation, IP route optimization (google this, since we don't seem to have an article) or even various forms of hardware optimization, e.g. VLSI optimization is hopelessly broad. Pcap ping 18:11, 1 September 2009 (UTC)
I suggest changing the name further to "code improvement". The term 'optimize' is such a misnomer since it is sometimes used in an exact sense in mathematics and information theory. When we try to make code faster, we can rarely say for sure there isn't an even better way to do the same thing. 188.126.200.132 (talk) 04:34, 20 July 2014 (UTC)
I remember a quote to the effect of: The only appropriate optimization is when you've measured the speed and it is too slow (for whatever purpose it's being used for). Where is that quote from? Could it be worked into this page? It seems extremely relevant.
Also consider that the speed of computers is always increasing (ref. Moore's Law), and the ability of humans to comprehend software code only decreases over time due to various factors. Therefore we should not optimize for computer speed, our time would be better off spent optimizing for human understanding. — Preceding unsigned
The article starts with the goals of optimization.
One goal is missing up to now: readability/maintainability.
If you compare this to cars: Most people tune their car to be faster, but cars can be tuned to look nicer or to increase convenience — Preceding unsigned comment added by Guettli (talk • contribs) 14:48, 9 January 2019 (UTC)