gnat: Execution_Time is not supported in this configuration
in [ADA]
|
From: John B. Matthews on 4 Dec 2009 16:50 In article <1wjhklygzok25.t79koxbbtlcj$.dlg(a)40tude.net>, "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: > On Fri, 04 Dec 2009 13:28:24 -0500, John B. Matthews wrote: > > > In article > > <5e5d6fb5-e719-4195-925c-d1286699393d(a)f16g2000yqm.googlegroups.com>, > > singo <sander.ingo(a)gmail.com> wrote: > > [...] > > I defer to Dmitry A. Kazakov about Windows, but this variation > > produces similar results on MacOS 10.5 & Ubuntu 9.10 using GNAT > > 4.3.4: > > > > <code> > > with Ada.Text_IO; use Ada.Text_IO; > > with Ada.Real_Time; use Ada.Real_Time; > > > > procedure ExecutionTime is > > task T; > > > > task body T is > > Start : Time := Clock; > > Interval : Time_Span := Milliseconds(100); > > begin > > loop > > Put_Line(Duration'Image(To_Duration(Clock - Start))); > > delay To_Duration(Interval); > > end loop; > > end T; > > begin > > null; > > end ExecutionTime; > > </code> > > > > <console> > > $ ./executiontime > > 0.000008000 > > 0.100168000 > > 0.200289000 > > 0.300409000 > > 0.400527000 > > 0.500575000 > > ... > > </console> > > Your code counts the wall clock time. On the contrary > Ada.Execution_Time should do the task time, i.e. the time the task > actually owned the processor or, maybe, the time the system did > something on the task's behalf. Ah, thank you for clarifying this. Indeed, one sees the secular growth in the output as overhead accumulates. I meant to suggest that other parts of Annex D may be supported on a particular platform, even if Ada.Execution_Time is not. > This package heavily depends on the OS services at least when the > tasks are mapped onto the OS scheduling items (like threads). > > As far as I know it is impossible to implement it reasonably under > Windows, because the corresponding service (used by the Task Manager > too) counts time quants instead of the time. This causes a massive > systematic error if tasks are switched before they consume their > quants. I.e. *always* when you do I/O or communicate to other tasks. > The bottom line, under Windows Ada.Execution_Time can be used only > for tasks that do lengthy computations interrupted by only by the > scheduler, so that all counted quants were consumed and no time were > spent in uncounted quants. > > I don't know, if or how, this works under Linux or Max OS. I should have mentioned that both systems specify "pragma Unimplemented_Unit" in Ada.Execution_Time. On Mac OS X 10.5, Ada.Real_Time.Time_Span_Unit is 0.000000001, but I'm unaware of a Mac clock having better that microsecond resolution, as suggested in the output above. I'm running Linux in VirtualBox, so I suspect any results reflect the host OS more than anything else. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Randy Brukardt on 4 Dec 2009 21:59 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:1wjhklygzok25.t79koxbbtlcj$.dlg(a)40tude.net... .... > This package heavily depends on the OS services at least when the tasks > are > mapped onto the OS scheduling items (like threads). > > As far as I know it is impossible to implement it reasonably under > Windows, > because the corresponding service (used by the Task Manager too) counts > time quants instead of the time. This causes a massive systematic error if > tasks are switched before they consume their quants. I.e. *always* when > you > do I/O or communicate to other tasks. The bottom line, under Windows > Ada.Execution_Time can be used only for tasks that do lengthy computations > interrupted by only by the scheduler, so that all counted quants were > consumed and no time were spent in uncounted quants. Obviously this depends on the purpose. For many profiling tasks, the Windows implementation is just fine. The quants seem to be short enough that most tasks run long enough to be counted. (And I/O has probably already be reduced to the minimum before even applying a profiler, if not, you're probably profiling the I/O first, not the CPU.) But I would have to agree that it isn't all that real-time. In any case, thanks for the clear explanation of the limitations of the Windows services. I'm sure that I'll run into them sooner or later and I'll hopefully remember your explanation. Randy.
From: singo on 7 Dec 2009 03:08 On Dec 4, 1:10 pm, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> wrote: > The reason are explained in the GNAT source files. The ones I have show > a note, after the © box: > ------------------------------------------------------------------------------ > -- -- > -- GNAT RUN-TIME COMPONENTS -- > -- -- > -- A D A . E X E C U T I O N _ T I M E -- > -- -- > -- S p e c -- > -- -- > -- This specification is derived from the Ada Reference Manual for use with -- > -- GNAT. In accordance with the copyright of that document, you can freely -- > -- copy and modify this specification, provided that if you redistribute a -- > -- modified version, any changes that you have made are clearly indicated. -- > -- -- > ------------------------------------------------------------------------------ > > -- This unit is not implemented in typical GNAT implementations that lie on > -- top of operating systems, because it is infeasible to implement in such > -- environments. > > -- If a target environment provides appropriate support for this package > -- then the Unimplemented_Unit pragma should be removed from this spec and > -- an appropriate body provided. > > with Ada.Task_Identification; > with Ada.Real_Time; > > package Ada.Execution_Time is > pragma Preelaborate; > > pragma Unimplemented_Unit; Thanks to all of you for your help! Still I wonder why it is written in the GNAT reference specification that the real time annex is fully implemented [1]. "Real-Time Systems (Annex D) The Real-Time Systems Annex is fully implemented." According to the ARM 'Execution Time' is part of the real-time annex [2], so it should be implemented. So, does "fully implemented" mean that it only in principle is fully implemented, but that the underlying OS/hardware (in my case 64-bit Ubuntu-Linux (9.10) on an Intel QuadCore) has to support this features as well? Or how do I have to read "fully implemented"? Best regards Ingo [1] http://gcc.gnu.org/onlinedocs/gnat_rm/Specialized-Needs-Annexes.html#Specialized-Needs-Annexes [2] http://www.adaic.org/standards/05rm/html/RM-D-14.html
From: John B. Matthews on 7 Dec 2009 12:13 In article <213be370-c1da-4d5b-89c4-cd30ad6aef18(a)e20g2000vbb.googlegroups.com>, singo <sander.ingo(a)gmail.com> wrote: > On Dec 4, 1:10 pm, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> > wrote: > > > The reason are explained in the GNAT source files... > > -- This unit is not implemented in typical GNAT implementations > > -- that lie on top of operating systems, because it is infeasible > > -- to implement in such environments. > > > > -- If a target environment provides appropriate support for this > > -- package then the Unimplemented_Unit pragma should be removed > > -- from this spec and an appropriate body provided. [...] > Or how do I have to read "fully implemented"? I'm guessing "fully implemented" on supported platforms and "not required in all implementations [1]." GNAT actually meets the implementation and documentation requirements [2]. My OS simply doesn't have the required facilities; it's designed for a GUI user, not real-time. If I were cross-developing, I'd perhaps create a fake body. On Linux, it might be possible to get something relatively informative out of /proc/<PID>/task/<TID>/stat. [1]<http://gcc.gnu.org/onlinedocs/gnat_rm/Specialized-Needs-Annexes.html# Specialized-Needs-Annexes> [2]<http://www.adaic.org/standards/05rm/html/RM-D-14.html> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
First
|
Prev
|
Pages: 1 2 Prev: Mike Yoder Next: GNAT.Sockets, Create_Selector and error 10055 on Windows |