From: Alan W. I. <ir...@be...> - 2012-02-19 18:01:52
|
On 2012-02-19 11:31-0000 arj...@us... wrote: > Revision: 12170 > http://plplot.svn.sourceforge.net/plplot/?rev=12170&view=rev > Author: arjenmarkus > Date: 2012-02-19 11:31:08 +0000 (Sun, 19 Feb 2012) > Log Message: > ----------- > Change the local declaration of "square* s" - the original was not accepted by MS VC/C++. Hi Arjen: The new declaration location is still inside two for loops so doesn't that mean at run time the memory required for s is put on the stack/removed from the stack (a->ni)*(a->nj) times, i.e., the number of iterations of the inner loop times the number of iterations of the outer loop? For large a->ni and a->nj this could become a run-time efficiency concern. In other words, isn't this an example of the general case of a statement that should be be moved outside a loop (or loops) since it doesn't depend on anything happening within the loop? I suppose a good optimizing compiler would effectively move all such statements outside of loops, but I never completely trust such optimizations. (I still vividly remember the case of the IBM fortran compiler in the 70's that calmly removed statements that _did_ depend on the loop outside of the loop when you told it to "optimize". So the programmer lore then was to never ever use the optimizer for that compiler, and it took IBM years to fix that bug.) In any case, I think it is simply a matter of good programming practice to place statements in the right location outside a loop or loops whenever we notice (as now) such statements don't depend on anything in the loop. I know this code was not your original responsibility, but since your change to separate the declaration from the assignment has made a further efficiency change possible, I think we should do that (and also in any other case where we have an obvious case of a statement in a loop that depends on nothing in the loop). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@de...> - 2012-02-20 09:23:36
|
Hi Alan, I too come from a school where all declarations are put at the top of a program unit, but it seems more and more "fashionable" to restrict the scope of variables as much as possible, in this case the variables s and p. The code in csa.c is full of that type of local declarations. I will try and get some information on possible performance impacts, but a friend already informed me that compilers are very likely to take care of that automatically. Regards, Arjen On 2012-02-19 19:01, Alan W. Irwin wrote: > On 2012-02-19 11:31-0000 arj...@us... wrote: > >> Revision: 12170 >> http://plplot.svn.sourceforge.net/plplot/?rev=12170&view=rev >> Author: arjenmarkus >> Date: 2012-02-19 11:31:08 +0000 (Sun, 19 Feb 2012) >> Log Message: >> ----------- >> Change the local declaration of "square* s" - the original was not >> accepted by MS VC/C++. > > Hi Arjen: > > The new declaration location is still inside two for loops so doesn't > that mean at run time the memory required for s is put on the > stack/removed from the stack (a->ni)*(a->nj) times, i.e., the number > of iterations of the inner loop times the number of iterations of the > outer loop? For large a->ni and a->nj this could become a run-time > efficiency concern. > > In other words, isn't this an example of the general case of a > statement that should be be moved outside a loop (or loops) since it > doesn't depend on anything happening within the loop? I suppose a > good optimizing compiler would effectively move all such statements > outside of loops, but I never completely trust such optimizations. (I > still vividly remember the case of the IBM fortran compiler in the > 70's that calmly removed statements that _did_ depend on the loop > outside of the loop when you told it to "optimize". So the programmer > lore then was to never ever use the optimizer for that compiler, and > it took IBM years to fix that bug.) In any case, I think it is simply > a matter of good programming practice to place statements in the right > location outside a loop or loops whenever we notice (as now) such > statements don't depend on anything in the loop. > > I know this code was not your original responsibility, but since your > change to separate the declaration from the assignment has made a > further efficiency change possible, I think we should do that (and > also in any other case where we have an obvious case of a statement in > a loop that depends on nothing in the loop). > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2012-02-20 17:31:56
|
Hi Arjen: I changed the subject line to something more appropriate. On 2012-02-20 10:23+0100 Arjen Markus wrote: > Hi Alan, > > I too come from a school where all declarations are put at the top > of a program unit, but it seems more and more "fashionable" to restrict > the scope of variables as much as possible, in this case the variables > s and p. The code in csa.c is full of that type of local declarations. Actually, I generally like that fashion/style. If you declare the variables at the top of the smallest block of code (delimited by "{" and "}") where they are used (as opposed to declaring them at the top of the largest possible block of code, i.e., the function where they are used) I just think it makes the code a lot easier to read and helps you to keep better track of communication of data between blocks of code. As stated previously in this thread, I was a bit concerned from the efficiency perspective with the case of declarations in a block of code for a loop, but I am also pretty sure your friend is right (that compilers will do the right thing from the efficiency perspective and move the stack allocations/deallocations associated with the declaration outside the loop). Is there anyone else here with thoughts or experience with this largely stylistic issue? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: chm <dev...@gm...> - 2012-02-20 19:32:44
|
On 2/20/2012 12:31 PM, Alan W. Irwin wrote: > Hi Arjen: > > I changed the subject line to something more appropriate. > > On 2012-02-20 10:23+0100 Arjen Markus wrote: > >> Hi Alan, >> >> I too come from a school where all declarations are put at the top >> of a program unit, but it seems more and more "fashionable" to restrict >> the scope of variables as much as possible, in this case the variables >> s and p. The code in csa.c is full of that type of local declarations. > > Actually, I generally like that fashion/style. If you declare the > variables at the top of the smallest block of code (delimited by "{" > and "}") where they are used (as opposed to declaring them at the top > of the largest possible block of code, i.e., the function where they > are used) I just think it makes the code a lot easier to read and helps > you to keep better track of communication of data between blocks > of code. > > As stated previously in this thread, I was a bit concerned from the > efficiency perspective with the case of declarations in a block of > code for a loop, but I am also pretty sure your friend is right (that > compilers will do the right thing from the efficiency perspective and > move the stack allocations/deallocations associated with the > declaration outside the loop). > > Is there anyone else here with thoughts or experience with this > largely stylistic issue? I think current compilers can keep this efficient and lift out the initializations oft of loops and other such optimizations. A related point is that not all compilers can deal with declarations that are not at the beginning of the enclosing block (some versions of MSVC come to mind) and will complain or quit if "sloppy" C++ style declarations are used. --Chris > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1424 / Virus Database: 2112/4821 - Release Date: 02/20/12 > > |
From: Arjen M. <arj...@de...> - 2012-02-21 09:00:39
|
Hi Chris, On Mon, 20 Feb 2012 14:32:30 -0500 chm <dev...@gm...> wrote: > > I think current compilers can keep this efficient > and lift out the initializations oft of loops and > other such optimizations. > > A related point is that not all compilers can deal > with declarations that are not at the beginning of > the enclosing block (some versions of MSVC come > to mind) and will complain or quit if "sloppy" > C++ style declarations are used. > The latter was exactly the problem that raised the question. I corrected it in csa.c, so that the MSVC compiler woudl accept the code. One thing I find quirky about this style of programming (and it is ubiquitous in Java and C++, where declarations can occur anywhere in the code) is that sometimes, changing the code in a loop forces you to move the declaration outside the loop, thus increasing the scope of the variable. If that does not happen, however, such a restricted scope can greatly help understanding the code. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |