comp.lang.ada
 help / color / mirror / Atom feed
From: StationSteve <Steven.Suchting@computer.org>
Subject: Re: Worst Case Execution Time Tool?
Date: Thu, 6 Dec 2001 21:27:58 GMT
Date: 2001-12-06T21:27:58+00:00	[thread overview]
Message-ID: <3C0FE2DE.4BD905B9@computer.org> (raw)
In-Reply-To: ccNP7.51478$xS6.84875@www.newsranger.com

Ok, do you have time to educate me a little bit?
Why would a tool have to be "pretty darn smart" to measure the worst-case execution
time of a list traversal?  What's the big driver in making such a thing hard to do?
How hard are we talking?  Ph.D/New Theory Required hard or Grad Student Thesis hard
or Kappa-Key undergrad hard or Lock-the-new-hire-in-the-lab-just-get-it-done hard?

Ted Dennison wrote:

> In article <3C0F7B36.52960668@computer.org>, StationSteve says...
> >
> >Of course.  Er, I mean sorry, I guess I should have said that I was looking
> >for a *practical* tool that could *productively* address a *real world*
> >problem! ;-)
> >
> >Ted Dennison wrote:
> >> Ah. So we aren't looking for something that can handle any old program
> >> (which it still seems to be would be reducable to the Halting Problem), but
> >> rather one that can handle programs that fit certian restrictions.
>
> :-)
>
> For that to be accurate though, you'd have to be able to say that all programs
> that don't fit within the restrictions are not "real world" programs for some
> reason. That could be the case I suppose. However, I'd bet quite a few "real
> world" programs wouldn't meet all the restrictions in any such existing tool.
> Certianly "No recursion" and "no loops with a dynamicly determined amount of
> iterations" (which is what Stuart said) would take out a great deal of the "real
> world" code I have seen.
>
> For instance, just about anything that handles terminated I/O would be out. A
> lot of dynamic data structure code would be out too. I could easily see where a
> hard realtime app might want to measure the worst-case execution time of a list
> traversal (eg: the scheduler's list of scheduled tasks). It'd be a pretty darn
> smart tool if it could handle that, no matter how the list is implemented.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>
> No trees were killed in the sending of this message.
> However a large number of electrons were terribly inconvenienced.




  reply	other threads:[~2001-12-06 21:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-04 22:51 Worst Case Execution Time Tool? StationSteve
2001-12-05  0:10 ` Ted Dennison
2001-12-05 17:28   ` Stuart Palin
2001-12-05 18:33     ` Ted Dennison
2001-12-06 14:05       ` StationSteve
2001-12-06 16:40         ` Ted Dennison
2001-12-06 21:27           ` StationSteve [this message]
2001-12-06 22:44             ` Ted Dennison
2001-12-07  1:00               ` annonymous
2001-12-05 10:00 ` Rod Chapman
2001-12-05 14:54   ` StationSteve
2001-12-05 15:31     ` Jeffrey L. Susanj
2001-12-05 17:32     ` Stuart Palin
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox