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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news3.google.com!feeder.news-service.com!fu-berlin.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada.Execution_Time Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1wmsukf0wglz3$.odnzonrpayly.dlg@40tude.net> Date: Thu, 16 Dec 2010 18:52:49 +0100 Message-ID: <6n1c5myuf2uz$.10jl3ln7il3aq.dlg@40tude.net> NNTP-Posting-Date: 16 Dec 2010 18:52:48 CET NNTP-Posting-Host: 44fafdaf.newsspool3.arcor-online.net X-Trace: DXC=^Fock=`KIc0nBOkdL^Lo7>McF=Q^Z^V384Fo<]lROoR18kF[ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:16958 Date: 2010-12-16T18:52:48+01:00 List-Id: On Thu, 16 Dec 2010 11:49:13 -0500, BrianG wrote: > Dmitry A. Kazakov wrote: >> On Wed, 15 Dec 2010 16:05:16 -0600, Randy Brukardt wrote: >> >>> I think you are missing the point of CPU_Time. It is an abstract >>> representation of some underlying counter. There is no requirement that this >>> counter have any particular value -- in particular it is not necessarily >>> zero when a task is created. So the only operations that are meaningful on a >>> value of type CPU_Time are comparisons and differences. Arguably, CPU_Time >>> is misnamed, because it is *not* some sort of time type. >> >> Any computer time is a representation of some counter. I think the point is >> CPU_Time is not a real time, i.e. a time (actually the process driving the >> corresponding counter) related to what people used to call "time" in the >> external world. CPU_Time is what is usually called "simulation time." One >> could use Duration or Time_Span in place of CPU_Time, but the concern is >> that on some architectures, with multiple time sources, this would >> introduce an additional inaccuracy. Another argument against it is that >> there could be no fair translation from the CPU usage counter to >> Duration/Time_Span (which is the case for Windows). >> > Isn't any "time" related to a computer nothing but a "simulation time"? No, Ada.Calendar.Time and Ada.Real_Time.Time are derived from quartz generators, which are physical devices. CPU_Time is derived from the time the task owned a processor. This is a task time, the time in a simulated Universe where nothing but the task exists. This Universe is not real, so its time is not. Or to put it otherwise, when Time has a value T, then under certain conditions this has some meaning invariant to the program and the task being run. For Ada.Real_Time.Time it is only the time differences T2 - T1, which have this meaning. CPU_Time has no physical meaning. 2s might be 2.5s real time or 1 year real time. > Yes, some times may be intended to emulate clock-on-the-wall-time, but > that doesn't mean they're a very good emulation (ever measure the > accuracy of a PC that's not synched to something? But the intent was to emulate the real time, whatever accuracy the result night have. > CPU_Time is > obviously an approximation, dependent on the RTS, OS, task scheduler, etc. An approximation of what? > What's so particularly bad about Windows (aside from the normal Windows > things)? Windows counts full quants. It means that if the task (thread) enters a non-busy waiting, e.g. for I/O or for other event, *before* it has spent its quant, the quant is not counted (if I correctly remember). In effect, you theoretically could have 0 CPU time with 99% processor load. Using the task manager, you might frequently observe the effect of this: moderate CPU load, but everything is frozen. (I don't checked this behavior since Windows Server 2003, maybe they fixed it in Vista, 7 etc). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de