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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a1a88c4d509f6381 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: scope and/or parameters (beginner) Date: 1999/04/14 Message-ID: <7f23j5$4mu$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 466267569 References: <37064309.889106243@news.dsuper.net> <37084459.8616007@rocketmail.com> <370b0c99.1137352783@news.dsuper.net> <7ei04q$o$1@nnrp1.dejanews.com> <7et4vr$sdj$1@nnrp1.dejanews.com> <7euskv$d91$1@nnrp1.dejanews.com> <7evbei$opm$1@nnrp1.dejanews.com> <7f1jce$nt4$1@nnrp1.dejanews.com> X-Http-Proxy: 1.0 x1.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Apr 14 13:01:29 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-04-14T00:00:00+00:00 List-Id: In article <7f1jce$nt4$1@nnrp1.dejanews.com>, czgrr wrote: > I use ObjectAda Professional Edition version 7.1.1.543, > on Windows NT 4.0 with 128MB memory. Output was... > > 3.67944E+04 Calling global... > 3.67945E+04 Calling local... > 3.68065E+04 Finished. > > That is, 0.1 second (to nearest 0.1 second!) to do the > global verison, 12.0 seconds to do the local version. And that statement is ALL you can conclude from this experiment, namely that on the particular compiler you used, with this particular program, you get these particular results. You can't conclude anything general about even your particular implementation, let alone about local and global variables in general. There is absolutely NO reason to see any difference between the local and global array accesses here, except that of course a good compiler should completely and easily eliminate the code for the local version all together, since the array is dead, and it is easy to see that it is dead. You do have a dynamic frame in your local procedure (I hope you understand the fundamental and critical difference between a dynamic or static local frame), and this means that there is a dynamic stack check in the local version that is probably avoided in the global version. GNAT gives the following results for this program: 3.12079E+04 Calling global... 3.12079E+04 Calling local... 3.12079E+04 Finished. i.e. neither case takes detectable time, which is what you would expect. This particular test is deeply flawed in several respects. a) As I noted above, the local version is far too easy to optimize away. b) Even the global version is too attackable by an optimizer. c) linking the size of the array to the number of test loops is conceptually wrong. d) using calendar and time of day to measure CPU performance is fundamentally flawed. e) Your can't tell whether the result of your code is from the call or the array access, so it is hard to interpret the results. f) You have not considered issues of optimization issues etc in deciding how to run this benchmark. We find that people who try to run their own timing tests almost always make these kinds of mistakes. Writing meaningful benchmark tests is VERY tough. Almost always when someone reports some anomoly with GNAT timing from some little test program they have written, the anomoly is a direct consequence of an incorrectly written test. So how come you saw such bizarre results from your test run with Object Ada? There could be many reasons. 1) You have run into some strange anomoly in code generation. This seems unlikely, but is possible, 12 seconds for the local case makes no sense. Let's do some quick calculations: You are calling a routine only 100,000 times. In 12 seconds, this means 10,000 calls/second, which on a slowish PC (you did not give the analysis platform) which gives you at least 200,000,000 instructions per second, probably more, something like 20,000 instructions per call. That of course is completely absurd. The expected time for this execution should be in the region of 10-50 instructions per call at most, even with lousy optimization, so you should be talking something like 1000 times that speed or in the range of 10-20 milliseconds for your test. Nevertheless an anomoly is always possible. Suppose for example, that the stack check for the local case involved a system call to find the current task to get the stack limit. That's unimaginably horrible, but strange things have been seen. You can of course look at the assembly language generated by your compiler, to see if there is some such nasty anomoly, but I would doubt this is the reason 2) Your setup or observations are flawed in some way. 3) The calendar mistake cost you meaningful results 4) Something else completely unrelated is wrong The point is that you cannot draw ANY conclusions from a test that is poorly written, and whose results you cannot explain when they clearly make little sense. Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own