In article <1118916402.66792381a7012eb59f1dd4438ce355a4@teranews>, nobody@spam.prevent.net says...> On Tue, 14 Jun 2005 22:49:54 -0400, R Adsett > <radsett@junk.aeolusdevelopment.cm> wrote: > > >In article <pan.2005.06.14.07.57.25.334427@magic.fr>, > >l_indien_no_more_spams@magic.fr says... > >> On Tue, 14 Jun 2005 08:59:01 +0200, David Brown wrote: > >> > >> > l'indien wrote: > >> > And I presume you are only doing this optomisation for interest and > >> > understanding, not because you are setting vectors so often that 3 > >> > cycles delay here will be a serious issue? > >> > >> We always want optimal code, don't we ? ;-) > > > >Actually no. Readable (human readable) and correct first. Optimal is, > >at best, a distant third. > > Optimal implies correct code.Well, yes. The converse is not, I think, true. Unless of course you define correct as a synonym for optimal. In this case though the context suggests that optimal meant fast. To quote Knuth "Premature optimization is the root of all evil". I think that was Knuth anyway. Clear, fast enough and small enough are good for me. No need to go to the trouble of as small as possible or as fast as possible in most cases. I've seen attempts to optimize that ended up only optimizing the obvious and missed doing the correct thing for the whole set of inputs when the clear version worked correctly for all cases. This in a case where the clear version was fast enough and small enough.> One cannot decribe anything as an > optimal solution, if it does not do what it is supposed to do. > Things that are obscure at first, become very "Human Readable" if it > is the optimum solution to a problem.On this I will disagree. We've all done clever things at one time or another that when we went back to them later were far from clear. If you have ever used APL I can guarantee it ;)> Readable code for even a complete newby programmer is total black > magic to the avarage lay person.Yes, but so what? If it is necessary to optimize a sequence to fit it within tight constraints then sufficient supporting comments must be added to make it clear what is being done and why even to someone who is encountering it for the first time. Basic knowledge of the implementation language and external HW can probably be assumed but when you start relying on multiple side effects or delay testing a flag for several instructions you had better warn the unwary reader of the traps that lay in the code. I don't expect I get this right all the time either but I do try. Robert
Inline assembler on PowerPC
Started by ●June 13, 2005
Reply by ●June 16, 20052005-06-16
Reply by ●June 16, 20052005-06-16
On Thu, 16 Jun 2005 10:57:03 -0400, R Adsett <radsett@junk.aeolusdevelopment.cm> wrote:>In article <1118916402.66792381a7012eb59f1dd4438ce355a4@teranews>, >nobody@spam.prevent.net says... >> On Tue, 14 Jun 2005 22:49:54 -0400, R Adsett >> <radsett@junk.aeolusdevelopment.cm> wrote: >> >> >In article <pan.2005.06.14.07.57.25.334427@magic.fr>, >> >l_indien_no_more_spams@magic.fr says... >> >> On Tue, 14 Jun 2005 08:59:01 +0200, David Brown wrote: >> >> >> >> > l'indien wrote: >> >> > And I presume you are only doing this optomisation for interest and >> >> > understanding, not because you are setting vectors so often that 3 >> >> > cycles delay here will be a serious issue? >> >> >> >> We always want optimal code, don't we ? ;-) >> > >> >Actually no. Readable (human readable) and correct first. Optimal is, >> >at best, a distant third. >> >> Optimal implies correct code. > >Well, yes. The converse is not, I think, true. Unless of course you >define correct as a synonym for optimal. In this case though the context >suggests that optimal meant fast.No correct code is not neceserally optimal, but I believe that for code to be the optimal code for a specific problem, it should be correct. Under all conditions within the specific problems domain. Optimal code is the smallest and/or fastest set of instructions to do the specific thing one wants to do.>To quote Knuth "Premature optimization is the root of all evil". I think >that was Knuth anyway. Clear, fast enough and small enough are good for >me. No need to go to the trouble of as small as possible or as fast as >possible in most cases. > >I've seen attempts to optimize that ended up only optimizing the obvious >and missed doing the correct thing for the whole set of inputs when the >clear version worked correctly for all cases. This in a case where the >clear version was fast enough and small enough.If the code is broken when trying to optimize, then the resultant code is not optimal, but wrong. And yes I do agree that trying to optimize a total application to the point where it is impossible to get it faster/smaller is in 99.999% of the cases just a waste of time.>> One cannot decribe anything as an >> optimal solution, if it does not do what it is supposed to do. >> Things that are obscure at first, become very "Human Readable" if it >> is the optimum solution to a problem. > >On this I will disagree. We've all done clever things at one time or >another that when we went back to them later were far from clear. If you >have ever used APL I can guarantee it ;) > >> Readable code for even a complete newby programmer is total black >> magic to the avarage lay person. > >Yes, but so what? If it is necessary to optimize a sequence to fit it >within tight constraints then sufficient supporting comments must be >added to make it clear what is being done and why even to someone who is >encountering it for the first time. Basic knowledge of the >implementation language and external HW can probably be assumed but when >you start relying on multiple side effects or delay testing a flag for >several instructions you had better warn the unwary reader of the traps >that lay in the code. I don't expect I get this right all the time >either but I do try.What I mean is that when confronted with a section of code for the first time, it might be quite obscure. If this sequence of code is the optimal solution to a specific problem, and many programmers end up using this sequence, then it become "Human Readable" by the mere fact that it is used often, by many people in a well defined context. For someone used only to high level code, simple basic assembly can be quite obscure and not readable at all. What is obscure to a beginner might actually be quite clear to a more experienced person. As in all most things the difference is not Black/White and exactely where the line lies is open to debate. Regards Anton Erasmus
Reply by ●June 16, 20052005-06-16
Anton Erasmus wrote:>... snip ...> > What I mean is that when confronted with a section of code for the > first time, it might be quite obscure. If this sequence of code is > the optimal solution to a specific problem, and many programmers > end up using this sequence, then it become "Human Readable" by the > mere fact that it is used often, by many people in a well defined > context. For someone used only to high level code, simple basic > assembly can be quite obscure and not readable at all. What is > obscure to a beginner might actually be quite clear to a more > experienced person. As in all most things the difference is not > Black/White and exactely where the line lies is open to debate.I recall an exposition of Knuths some years ago, in which he reworked some fairly normal code into a peculiar monster. It was developed step by step to improve efficiency in a perfectly logical manner. IIRC it ended up with a goto into the middle of a structured statement, which is considered a no-no. One of the points he made with it was that such derivations should include the original, and the various steps taken to attain the end result. Otherwise it has virtually no chance of making sense to the later reader. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●June 17, 20052005-06-17
R Adsett wrote:> In article <1118916402.66792381a7012eb59f1dd4438ce355a4@teranews>, > nobody@spam.prevent.net says... > >>On Tue, 14 Jun 2005 22:49:54 -0400, R Adsett >><radsett@junk.aeolusdevelopment.cm> wrote:<snip>>>> >>>Actually no. Readable (human readable) and correct first. Optimal is, >>>at best, a distant third. >> >>Optimal implies correct code. >Yes, it is easy to write code that is fast but incorrect!> > Well, yes. The converse is not, I think, true. Unless of course you > define correct as a synonym for optimal. In this case though the context > suggests that optimal meant fast. > > To quote Knuth "Premature optimization is the root of all evil". I think > that was Knuth anyway. Clear, fast enough and small enough are good for > me. No need to go to the trouble of as small as possible or as fast as > possible in most cases. >Knuth also gave two rules of optimization: 1) Don't do it. 2) (For experts only) Don't do it yet. Readability goes hand-in-hand with correctness in priority - code that is unreadable is unlikely to be correct, and even less likely to be checked to be correct (either by testing or proof). Getting optimal code, or at least close to optimal, involves two things - thinking about your code as you write it, and using a good compiler. The biggest difference to the speed and size of code is made when thinking about what your code should do (i.e., at the algorithmic stage), then by thinking about your implementation (e.g., using integers instead of floats, and understanding how your code will fit with the target's capabilities). Small things, such as when to use arrays and when to use pointers, are best left to the compiler if it has a good optimizer.
Reply by ●June 17, 20052005-06-17
On Fri, 17 Jun 2005 09:20:04 +0200, David Brown <david@westcontrol.removethisbit.com> wrote:>R Adsett wrote: >> In article <1118916402.66792381a7012eb59f1dd4438ce355a4@teranews>, >> nobody@spam.prevent.net says... >> >>>On Tue, 14 Jun 2005 22:49:54 -0400, R Adsett >>><radsett@junk.aeolusdevelopment.cm> wrote: > ><snip> > >>>> >>>>Actually no. Readable (human readable) and correct first. Optimal is, >>>>at best, a distant third. >>> >>>Optimal implies correct code. >> > >Yes, it is easy to write code that is fast but incorrect! > >> >> Well, yes. The converse is not, I think, true. Unless of course you >> define correct as a synonym for optimal. In this case though the context >> suggests that optimal meant fast. >> >> To quote Knuth "Premature optimization is the root of all evil". I think >> that was Knuth anyway. Clear, fast enough and small enough are good for >> me. No need to go to the trouble of as small as possible or as fast as >> possible in most cases. >> > >Knuth also gave two rules of optimization: > >1) Don't do it. >2) (For experts only) Don't do it yet. >The problem is that many programmers seem to understand. "Write code as sloppily as possible, and do not even think about whether the current approach is easy or difficult for the processor" The worst I have seen was an application where a set of different routines was called based on configuration data. There was an array of function pointers, and obviously for readability they decided that calling function[3](args) is not clear. Calling something like function[FOO](args) is a lot clearer where FOO gives some indication of what the function does. In stead of just have a #defined or enumerated list, the programmers put the names in a character array. They then had a function that did a string compare on the character array every time it was called to decide which function pointer in the array to take. Needless to say this was VERY slow. A very simple optimization speeded the code up by more 100 times. Of course it is debatable whether this was optimization or fixing incorrect code.>Readability goes hand-in-hand with correctness in priority - code that >is unreadable is unlikely to be correct, and even less likely to be >checked to be correct (either by testing or proof). Getting optimal >code, or at least close to optimal, involves two things - thinking about >your code as you write it, and using a good compiler. The biggest >difference to the speed and size of code is made when thinking about >what your code should do (i.e., at the algorithmic stage), then by >thinking about your implementation (e.g., using integers instead of >floats, and understanding how your code will fit with the target's >capabilities). Small things, such as when to use arrays and when to use >pointers, are best left to the compiler if it has a good optimizer.Having now read the rest of yout post :) I totally agree with your additions to the Knuth optimization rules. A better algorithm is worth more than a poor algorithm optimized to the core. Regards Anton Erasmus
Reply by ●June 18, 20052005-06-18
In article <1118949838.101c02e5d7c78f654f62183750680f48@teranews>, nobody@spam.prevent.net says...> On Thu, 16 Jun 2005 10:57:03 -0400, R Adsett > <radsett@junk.aeolusdevelopment.cm> wrote: > > >To quote Knuth "Premature optimization is the root of all evil". I think > >that was Knuth anyway. Clear, fast enough and small enough are good for > >me. No need to go to the trouble of as small as possible or as fast as > >possible in most cases. > > > >I've seen attempts to optimize that ended up only optimizing the obvious > >and missed doing the correct thing for the whole set of inputs when the > >clear version worked correctly for all cases. This in a case where the > >clear version was fast enough and small enough. > > If the code is broken when trying to optimize, then the resultant code > is not optimal, but wrong. And yes I do agree that trying to optimize > a total application to the point where it is impossible to get it > faster/smaller is in 99.999% of the cases just a waste of time.I think we are agreeing here. My only point in the above was that the obsession with optimization appears to often result in somewhat faster and/or smaller but broken code.> >> One cannot decribe anything as an > >> optimal solution, if it does not do what it is supposed to do. > >> Things that are obscure at first, become very "Human Readable" if it > >> is the optimum solution to a problem. > > > >On this I will disagree. We've all done clever things at one time or > >another that when we went back to them later were far from clear. If you > >have ever used APL I can guarantee it ;) > > > >> Readable code for even a complete newby programmer is total black > >> magic to the avarage lay person. > > > >Yes, but so what? If it is necessary to optimize a sequence to fit it > >within tight constraints then sufficient supporting comments must be > >added to make it clear what is being done and why even to someone who is > >encountering it for the first time. Basic knowledge of the > >implementation language and external HW can probably be assumed but when > >you start relying on multiple side effects or delay testing a flag for > >several instructions you had better warn the unwary reader of the traps > >that lay in the code. I don't expect I get this right all the time > >either but I do try. > > What I mean is that when confronted with a section of code for the > first time, it might be quite obscure. If this sequence of code is the > optimal solution to a specific problem, and many programmers end up > using this sequence, then it become "Human Readable" by the mere fact > that it is used often, by many people in a well defined context.Again we will have to disagree on this. Once an implementation goes beyond the straightforward it becomes obscure. It may be completely transparent while you are working on it, but once you leave it for 6 months or a year it will no longer be so. I still find myself at least occaisionally beefing up the comments on code when I revisit it later. As far as a frequently used sequence being clear, it seems to me that more than once I've read code with a comment that goes something like "For some reason everyone does this, I don't know why it works but it does". Frequently used obscure code appears to also have a tendency to devolve into magic incantations ;)> For someone used only to high level code, simple basic assembly can be > quite obscure and not readable at all. What is obscure to a beginner > might actually be quite clear to a more experienced person. As in all > most things the difference is not Black/White and exactely where the > line lies is open to debate.True enough, but there is a difference between a implementation being obscure because you are not familiar with the language, processor or harwares and it being obscure because you are using non-straightforward techniques. It's this latter that demands special care and attention. particularly in making sure that whoever follows can figure out what is going on without needing to spend a lot of time re-inventing the solution. Sometimes that involves a short note, sometimes a long description and sometines a reference to a discussion in a lab book or paper. An example might be an FFT. Any implementation of that should either contain a full description or better a reference to a full description. In this case the refernce would be better since the explanation is almost certainly more complete than one any of us are likely to have the patience to complete to accompany the code. Robert
Reply by ●June 18, 20052005-06-18
In article <d8tsve$52v$1@news.netpower.no>, david@westcontrol.removethisbit.com says...> Knuth also gave two rules of optimization: > > 1) Don't do it. > 2) (For experts only) Don't do it yet. > > > Readability goes hand-in-hand with correctness in priority - code that > is unreadable is unlikely to be correct, and even less likely to be > checked to be correct (either by testing or proof). Getting optimal > code, or at least close to optimal, involves two things - thinking about > your code as you write it, and using a good compiler. The biggest > difference to the speed and size of code is made when thinking about > what your code should do (i.e., at the algorithmic stage), then by > thinking about your implementation (e.g., using integers instead of > floats, and understanding how your code will fit with the target's > capabilities). Small things, such as when to use arrays and when to use > pointers, are best left to the compiler if it has a good optimizer.Well put. Robert
Reply by ●June 18, 20052005-06-18
In article <1119002425.b7ad46355833ac9e63bd16368286f661@teranews>, nobody@spam.prevent.net says...> On Fri, 17 Jun 2005 09:20:04 +0200, David Brown > <david@westcontrol.removethisbit.com> wrote: > > >R Adsett wrote: > >> In article <1118916402.66792381a7012eb59f1dd4438ce355a4@teranews>, > >> nobody@spam.prevent.net says... > >> > >>>On Tue, 14 Jun 2005 22:49:54 -0400, R Adsett > >>><radsett@junk.aeolusdevelopment.cm> wrote: > >> To quote Knuth "Premature optimization is the root of all evil". I think > >> that was Knuth anyway. Clear, fast enough and small enough are good for > >> me. No need to go to the trouble of as small as possible or as fast as > >> possible in most cases. > >> > > > >Knuth also gave two rules of optimization: > > > >1) Don't do it. > >2) (For experts only) Don't do it yet. > > > > The problem is that many programmers seem to understand. "Write code > as sloppily as possible, and do not even think about whether the > current approach is easy or difficult for the processor" > > The worst I have seen was an application where a set of different > routines was called based on configuration data. There was an array of > function pointers, and obviously for readability they decided that > calling function[3](args) is not clear. Calling something like > function[FOO](args) is a lot clearer where FOO gives some indication > of what the function does. In stead of just have a #defined or > enumerated list, the programmers put the names in a character array. > They then had a function that did a string compare on the character > array every time it was called to decide which function pointer in the > array to take. Needless to say this was VERY slow. A very simple > optimization speeded the code up by more 100 times. > > Of course it is debatable whether this was optimization or fixing > incorrect code.Well there is a difference between badly designed code and un-optimized code :). OTOH this might have made sense if this was part of a command parser or interpreter. In a command parser the lookup might have been small comapred to the typing time ;). In a straightforward case of substituting different run-time routines it seems unnecessarily complex though.
