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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,71b19e01eae3a390 X-Google-Attributes: gid103376,public From: Joel Sherrill Subject: Re: delay until and GNAT - expand Date: 1999/05/10 Message-ID: <7h7jm5$l8n$1@nnrp1.deja.com>#1/1 X-Deja-AN: 476314934 References: <7gpukr$s82$1@nnrp1.dejanews.com> <7grkbb$cee$1@nnrp1.deja.com> <7grvka$lc5$1@nnrp1.deja.com> <7h1e10$drg$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x32.deja.com:80 (Squid/1.1.22) for client 136.205.144.145 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Mon May 10 21:39:17 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.05 [en] (WinNT; I) Date: 1999-05-10T00:00:00+00:00 List-Id: In article , rracine@draper.com (Roger Racine) wrote: > >In article , > > rracine@draper.com (Roger Racine) wrote: > > >> The implementation of "delay", given today's processor speeds, is pretty good. > >> I have recently single stepped my way (in assembly) through it, and while I > >> did not count the instructions, it had to be on the order of 100 instructions. > >> > >> So, given a good real-time operating system and a reasonably fast processor, a > >> reasonable upper limit would probably be close to 1 microsecond (conservative > >> estimate). > >> > >> I am surprised GNAT documentation does not have this, except that the number > >> will be different for every underlying OS. > >> > >> Roger Racine > > >This is a highly misleading figure. The completion of a delay, in the sense > >that we are talking about, requires a preemptive context switch. To expect > >this to happen in 1 microsecond when running over an operating system like > >Unix, or even over a light real time executive is wildly optimistic. > > >I am not sure what you are measuring, but it is quite wrong. We don't document > >upper limits for such things in the GNAT manual, because it is impractical to > >do so in almost all operating systems contexts, since we depend on the > >underlying OS, and this information is not available for the OS. > > It is not misleading at all. It is a consequence of the speed of today's > processors. Back a few years (1983), it was reasonable to expect a simple > delay 0.0, which is what the issue is about, to take somewhere near 100 -200 > microseconds on a real-time OS. This included the context switch, but not the > activities of other tasks. Is this the meaning of the metric in D.8(10,11)? > > I was somewhat surprised to see numbers, for context switches, in the range of > 1 microsecond, but not when I thought of the current speed of processors. And > the metric is for processor clock cycles. I am assuming waiting for memory > does not count, but even if that is true, the result will not be very much > longer. > > Note that I said, "given a good real-time operating system". That does > not include any form of Unix (with the possible exception of LynxOS and any > other real-time versions; I have not looked at their documentation recently). > > I understand why compiler vendors can not document upper limits for host-based > systems. I would think that VxWorks and RTEMS could have the bounds > documented. And something like "GNAT takes xxx clock cycles + the underlying > operating system context switch" would meet the spirit of the RM. I know Wind > River publishes their bounds. It is quite reasonable to have users of the > metrics look at other documentation, as long as it is referenced. > > Roger Racine This information is documented for some RTEMS targets. But better than this is that the test suite used to generate this information is included with RTEMS and you can generate these numbers yourself on your target hardware. The context switch performance test in particular is "tm26". The mvme167 BSP reports a basic context switch at 3 microseconds on a 25 Mhz board. An important thing to remember is that often these older CPUs look quite good at context switches compared to newer high performance RISC CPUs. Context switches tend to be memory bound and RISC CPUs tend to have more state to save. But then again new RISC CPUs have incredibly high clock rates which covers up a lot. :) --joel joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (205) 722-9985 --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---