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-Thread: 103376,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Thread: 108717,a7c8692cac750b5e X-Google-Attributes: gid103376,gid115aec,gidf43e6,gid108717,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 15 Mar 2005 00:52:32 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada,comp.realtime,comp.software-eng,comp.programming References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <112sonip5v4dca6@corp.supernews.com> <112t3de6fu04f38@corp.supernews.com> <1110396477.596174.285520@o13g2000cwo.googlegroups.com> <112vb2t8eonuhed@corp.supernews.com> <1110422108.925127.54110@o13g2000cwo.googlegroups.com> <11329cb96h2p19f@corp.supernews.com> <113394jjvppao64@corp.supernews.com> <1133s3qnmqmbjfb@corp.supernews.com> <4232a9f7$0$26552$9b4e6d93@newsread4.arcor-online.net> <11369p5jrcc6835@corp.supernews.com> <1136h6a12qv8282@corp.supernews.com> <113cfqv380t2dc7@corp.supernews.com> Subject: Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada)) Date: Tue, 15 Mar 2005 00:54:54 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-kpjaUgthtrQCT9EtLibIdVVwWteRgsEoj4qu2rD0EKPxzuTLARga2QKXYdv/x1OZkNIIiW1RJonBRFB!qB5pn7yg29X3eDc217lQyHyZQeGn3WnxF2LeL0cVGkiwrl/L9xkOf50gLAEMtBce7O+gVub8bljQ X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:9427 comp.realtime:1506 comp.software-eng:5078 comp.programming:17962 Date: 2005-03-15T00:54:54-06:00 List-Id: "CTips" wrote in message news:113cfqv380t2dc7@corp.supernews.com... > Randy Brukardt wrote: ... > > As previously mentioned, it will be added to Ada 2005 (expected approval > > this summer). > > > > I believe that the reason that it didn't exist in previous versions of Ada > > was that directly targeting bare machines was an intended implementation of > > Ada. That is, the Ada RTS would provide the entire RTOS for the target, > > including tasking, exceptions, and so on. In that case, providing a CPU time > > function would have added overhead that may not have had any value to the > > user (you would have to keep track of it on every task switch whether it was > > used or not). > > How about the ANSI C solution: clock() must be defined, but can always > return -1 if the service is not available. Isn't that a better way? Well, in Ada it would raise an exception, not return some answer that could be mistaken for an actual result. And indeed there are plenty of things that work that way, like I/O and the command line. But time functions are not that way; every Ada implementation is expected to have them. I presume that they were considered fundamental. That seems to be the case for the new execution-time functions as well. Since they're in the real-time annex, they only have to be provided for implementations that implement that annex. So implementations running in non-real-time environments (like Windows) don't necessarily have to provide these functions. Anyway, I don't know as a fact why there wasn't any such functions in the past; I don't recall them having been suggested during the Ada 9X project (which eventually lead to Ada 95), and I wasn't involved in the definition of Ada 83. So it's possible that they simply never were in the requirements. Perhaps no one ever thought to individually time parts of tasks. (I've generally benchmarked complete systems, so the wall time from start to finish is the most interesting, as all of the components of the program, including the OS calls and tasking overhead, contribute.) I've given my best guess, but it's just a guess. Randy.