From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-23 03:48:27 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!newsmi-eu.news.garr.it!NewsITBone-GARR!newsserver.cilea.it!news.crs4.it!not-for-mail From: Jacob Sparre Andersen Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: Tue, 23 Sep 2003 12:48:24 +0200 Organization: CRS4, Center for Adv. Studies, Research and Development in Sardinia Message-ID: <3F7024F8.1000102@crs4.it> References: <3F650BBE.4080107@attbi.com> <3F67AAC6.2000906@attbi.com> NNTP-Posting-Host: sparre.crs4.it Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: pietro.crs4.it 1064309536 7987 156.148.70.170 (23 Sep 2003 09:32:16 GMT) X-Complaints-To: news@nntpserver.crs4.it. NNTP-Posting-Date: 23 Sep 2003 09:32:16 GMT User-Agent: Any Browser, HTML 4.01, XHTML 1.0 X-Accept-Language: fo, da, no, sv, is, fr, de, it, In-Reply-To: Xref: archiver1.google.com comp.lang.ada:42792 Date: 2003-09-23T09:32:16+00:00 List-Id: Russ wrote: > Wes Groleau wrote in message news:... >>(Russ insists that A += 1 never needs temporaries >>and that A := A + 1 always does.) Which as far as I know is not quite true. > That's not *quite* what I insist. What I insist is that, for > vector/matrix operations, "+" is a *function* that must create a > temporary vector/matrix and return it, and it must be *copied* to the > lhs. I haven't got the LRM right here, but IIRC the compiler just has to generate code that is _equivalent_ to that, i.e. code that gives the same result. And at least for simple cases like matrix operations, it is possible to make the compiler check if a temporary variable is needed or not. We can thus (at least in theory) leave it to the compiler to check if the temporary variable is needed or not _and_ to consider which of the solutions - with or without the temporary variable - is actually faster on the hardware in question. > On the other hand, "+=" is a *procedure* that does not > necessarily need any temporaries because it can do its operations "in > place". No temporaries, no extra copying. Yes. But would you really like to have to mess with writing code that you just as well could leave it to the compiler to generate _if_ it actually would make a efficiency difference for the program? I prefer to leave as much work as possible to the compiler. > Someone else also claimed that a good Ada compiler can make "+" as > efficient as "+=", but I don't see how that could be possible, > considering that I could define "+" and "+=" to do anything I want. Remember that the compiler has access to the code for your "+" function and can look at what it actually does. This is simply a matter of optimization. And it is not really on an algorithmic level, so it should be left to the compiler, unless you can prove that it is strictly neccessary to improve the code beyond what you compiler manages. > Nothing in the language requires me to define "+" to actually do > matrix addition. I could define it to write poetry if I wish. Yes. But then the compiler will just notice that and optimize accordingly. > And let's not forget that a properly defined "+" should be able to > handle sequential addition, such as A = B + C + D + E. No matter how > you slice it, each of those additions needs a temporary. Assuming that we are discussing something nice like simple matrix addition here, I don't see why. If your hardware has an "add four numbers" operation, you don't need any. And in general should such an operation be done on a per element basis, which would mean that one would need one (if the operations are done sequetially) or two (if the operations are done in parallel) registers in the CPU for storing intermediate results. But still: Leave this kind of optimization to the compiler! > On the other hand, you could write > > A = B > A += C > A += D > A += E > > It's not as elegant, but no temporaries or extra copying are required > (unless the language imposes them for extraneous reasons). I can't see why the resulting code from this should be any faster. I would rather say that it makes it more _difficult_ for the compiler to optimize the operation and for the maintenance programmer to understand it. Jacob -- "Any, sufficiently advanced, technology is indistinguishable from magic."