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: a07f3367d7,cae92f92d6a1d4b1 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.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: Sat, 25 Dec 2010 13:31:27 +0200 Organization: Tidorum Ltd Message-ID: <8nm30fF7r9U1@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net vCxTyzvW2NI4TnYnWTyUAgWTleoDtE1xeX2YGuTJV1hWEzZ2y3 Cancel-Lock: sha1:CERiD81S8Su6LJaZQn1tq9sfmw0= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:17109 Date: 2010-12-25T13:31:27+02:00 List-Id: Dmitry A. Kazakov wrote: > On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote: ... >> The concept and measurement of "the execution time of a task" does >> become problematic in complex processors that have hardware >> multi-threading and can run several tasks in more or less parallel >> fashion, without completely isolating the tasks from each other. > > No, the concept is just fine, Fine for what? For schedulability analysis, fine for on-line scheduling, ... ? However, this is a side issue, since we are (or at least I am) discussing what the RM intends with Ada.Execution_Time, which must be read in the context of D.2.1, which assumes that there is a clearly defined set of "processors" and each processor executes exactly one task at a time. > it is the interpretation of the measured values in the way you > wanted, which causes problems. That is the core of my point. The > measure is not real time. I still disagree, if we are talking about the intent of the RM. You have not given any arguments, based on the RM text, to support your position. >>> I am not a language lawyer, but I bet that an implementation of >>> Ada.Execution_Time.Split that ignores any CPU frequency changes >>> when summing up processor ticks consumed by the task would be >>> legal. >> Whether or not such an implementation is formally legal, that would >> require very perverse interpretations of the text in RM D.14. > > RM D.14 defines CPU_Tick constant, of which physical equivalent (if > we tried to enforce your interpretation) is not constant for many > CPU/OS combinations. The behaviour of some CPU/OS is irrelevant to the intent of the RM. As already said, an Ada implementation on such CPU/OS could use its own mechanisms for execution-time measurements. > On a such platform the implementation would be as perverse as RM D.14 > is. But the perversion is only because of the interpretation. Bah. I think that when RM D.14 says "time", it really means time. You think it means something else, perhaps a CPU cycle count. I think the burden of proof is on you. It seems evident to me that the text in D.14 must be interpreted using the concepts in D.2.1, "The Task Dispatching Model", which clearly specifies real-time points when a processor starts to execute a task and stops executing a task. To me, and I believe to most readers of the RM, the execution time of a task is the sum of these time slices, thus a physical, real time. >> (In fact, some variable-frequency scheduling methods may prefer to >> measure task "execution times" in units of processor ticks, not in >> real-time units like seconds.) > > Exactly. As a simulation time RM D.14 is perfectly OK. I put my comment, above, in parentheses because it is a side issue. And you still have not defined what you mean by "simulation time", and how you come there from the RM text. > It can be used for CPU load estimations, How, if it has "no physical meaning", as you claim? > while the "real time" implementation could not. Why not? That is the way ordinary schedulability analysis works. And again, it is irrevelant that some CPU/OS do not provide a good way to measure the physical execution time of tasks. > BTW, even for measurements people usually have in mind (e.g. > comparing resources consumed by tasks), simulation time would be more > fair. What is "simulation time"? > The problem is with I/O, because I/O is a "real" thing. I assume by "I/O" you mean time consumed in waiting for some external event. I agree that such I/O is a (solvable) problem in schedulability analysis, but it is not relevant for understanding the intent of RM D.14. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .