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,cae92f92d6a1d4b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada.Execution_Time Date: Fri, 07 Jan 2011 00:55:08 +0200 Organization: Tidorum Ltd Message-ID: <8omvicFgm0U1@mid.individual.net> References: <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1wmsukf0wglz3$.odnzonrpayly.dlg@40tude.net> <6n1c5myuf2uz$.10jl3ln7il3aq.dlg@40tude.net> <8n0mgnFv2sU1@mid.individual.net> <1n3o55xjdjr9t.1u33kb75y2jfl$.dlg@40tude.net> <8n1142Fto2U1@mid.individual.net> <1o5cbm4b1l20d$.19winbma6k5qw.dlg@40tude.net> <8n4mskF7mmU1@mid.individual.net> <8nm30fF7r9U1@mid.individual.net> <8o0p0lF94rU1@mid.individual.net> <8o4k3tFko2U1@mid.individual.net> <8o8ptdF35oU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net IA6S13VKLKxUHPXctB7auwrxXE/wdvmowrwY2h7NB/wUTUrVLE Cancel-Lock: sha1:YkLOAqLQVxS+ECUwzXhMl5j/DRM= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:17302 Date: 2011-01-07T00:55:08+02:00 List-Id: Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:8o8ptdF35oU1@mid.individual.net... >> Randy Brukardt wrote: >>> I think we're actually in agreement on most points. >> Good, and I agree. Nevertheless I again make a lot of comments, below, >> because I think your view, if true, means that Ada.Execution_Time is >> useless for real-time systems. > > Much like "unmeasurable", "useless" is a little bit strong, but this is > definitely true in general. > > That is, if you can afford megabucks to have a compiler runtime tailored to > your target hardware (and compiler vendors love such customers), The cost will depend on the number of users/customers and the extent of tailoring needed; I admit I haven't asked for quotes. At least the definition of a predefined, standard programmer interface in the form of Ada.Execution_Time and children should help make the tailoring more portable over targets, applications, and customers. > then you probably could find a use for in a hard real-time system. I think so. > But the typical off-the-shelf implementation is not going to be useful for > anything beyond gross guidance. Depends on which shelf you buy from :-) You are probably right for GNAT GPL on Linux, but perhaps there is more hope for RAVEN and the like. Although I see that Ravenscar excludes Ada.Execution_Time. > That's probably enough for soft real-time > systems anyway; and the facilities are useful for profiling and the like > even without any strong connection to reality. I don't see how Ada.Execution_Time would be very useful for profiling. While it could show you which tasks are CPU hogs, it does not resolve the execution-time consumption to subprograms or subprogram parts, which I think would be the important information for code redesigns aiming at improving speed. Real profilers usually do give you subprogram-level or even statement-level information. Of course, a profiler that collects subprogram-level execution time (per call, for example) but does not know about Ada task preemption will probably produce wildly wrong results. > ... unless you have a very > controlled environment. And if you have that environment, a > language-defined package doesn't buy you anything over > roll-your-own. I don't agree. I think a clean, standard, language-defined interface between the Ada RTS/kernel and the application will help an implementer, as I said above. Moreover, the scheduling algorithms published by Burns and Wellings and others are written to use Ada.Execution_Time. Rolling one's own interface would mean changing these algorithms. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .