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!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, 18 Dec 2010 23:20:20 +0200 Organization: Tidorum Ltd Message-ID: <8n4mskF7mmU1@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net /ymXAr/YYE9SNhyUZFjfiAIoyXFZl/+IZewPDmWTalFCggmq/a Cancel-Lock: sha1:UqbbybalVzePBx7wb+mrU6IAYLs= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: <1o5cbm4b1l20d$.19winbma6k5qw.dlg@40tude.net> Xref: g2news2.google.com comp.lang.ada:17000 Date: 2010-12-18T23:20:20+02:00 List-Id: Dmitry A. Kazakov wrote: > On Fri, 17 Dec 2010 13:50:26 +0200, Niklas Holsti wrote: > >> Dmitry A. Kazakov wrote: >>> On Fri, 17 Dec 2010 10:49:26 +0200, Niklas Holsti wrote: >>> >>>> Dmitry A. Kazakov wrote: >>>>> CPU_Time has no physical meaning. 2s might be 2.5s >>>>> real time or 1 year real time. >>>> CPU_Time values have physical meaning after being summed over all tasks. >>>> The sum should be the real time, as closely as possible. >>> 1. Not tasks, but threads + kernel services + kernel drivers + CPU >>> frequency slowdowns => a) wrong; b) out of Ada scope => cannot be mandated >> I believe we are talking about the intended meaning of >> Ada.Execution_Time.CPU_Time, not about how far it can be precisely >> "mandated" (standardized). >> >> Appendix D is about real-time systems, and I believe it is aimed in >> particular at systems built with Ada tasks and the Ada RTS. In such >> systems there may or may not be CPU time -- "overhead" -- that is not >> included in the CPU_Time of any task. See the last sentence in RM D.14 >> 11/2: "It is implementation defined which task, if any, is charged the >> execution time that is consumed by interrupt handlers and run-time >> services on behalf of the system". In most systems there will be some >> such non-task overhead, but in a "pure Ada" system it should be small >> relative to the total CPU_Time of the tasks. > > Yes, this is what I meant. CPU_Time does not have the meaning: > > "CPU_Time values have physical meaning after being summed over all tasks. > The sum should be the real time, as closely as possible." I said "as closely as possible", and I don't expect to find many systems in which they are exactly equal. But I still think that this (ideally exact, in practice approximate) relationship reflects the intended physical meaning of Ada.Execution_Time.CPU_Time: the elapsed real time (Time_Span) is divided into task execution times (CPU_Time) through task scheduling. > Anyway, even if the sum of components has a physical meaning that does not > imply that the components have it. If you have only one task, the sum is identical to the term, so their physical meanings are the same. Generalize for the case of many tasks. Next, we can argue if quarks have physical meaning, or if only hadrons do... :-) 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. Schedulability analysis in such systems is difficult since the "execution time" of a task depends on which other tasks are running at the same time. >> By "CPU frequency slowdowns" I assume you mean a system that varies the >> CPU clock frequency, for example to reduce energy consumption when load >> is low. This do not necessarily conflict with Ada.Execution_Time and the >> physical meaning of CPU_Time, although it may make implementation >> harder. One implementation could be to drive the CPU-time counter by a >> fixed clock (a timer clock), not by the CPU clock. > > 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. You would have to argue that a system with a lowered CPU clock frequency, running a single task with no interrupts, is only "executing the task" for a small part of each clock cycle, and the rest of each clock cycle is spent on some kind of system overhead. I don't think that is what the RM authors intended. You may be right that the RM has no formal requirement that would prevent such an implementation. (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.) But the implementation could not implement the function "-" (Left, Right : CPU_Time) return Time_Span to give a meaningful result, with the normal meaning of Time_Span, since the result would be the same Time_Span for a high CPU frequency and for a low one. >>> 2. Not so anyway under many OSes => again, cannot be mandated >> Whether or not all OSes support the concepts of Ada.Execution_Time is >> irrelevant to a discussion of the intended meaning of CPU_Time. > > ARM usually does not intend what would be impossible to implement. Not all OSes are designed for real-time systems. As I understand it, the ARM sensibly intends Annex D to be implemented in real-time OSes or in bare-Ada-RTS systems, not under Windows. Even under Windows, as I understand earlier posts in this thread, problems arise only if task interruptions, suspensions, and preemptions are so frequent that the "quant" truncation is a significant part of the typical uninterrupted execution time. Moreover, an Ada RTS running on Windows could of course use another clock or timer to measure execution time, if the Windows functionality is unsuitable. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .