Re: 'others' - inefficient esp. DEC Ada? [1/1]

[Rob Kirkbride <rk-comp@rk-comp.demon.co.uk>]

In article <344168c5.21239761@SantaClara01.news.InterNex.Net>, Tom Moran
<tmoran@bix.com> writes
>Testing your sample with two Ada 95 compilers on a Pentium 60, one of
>them takes roughly twice as long for the "others" as for the loop and
>the other compiler takes the same time either way (and looking at the
>generated code, it's pretty nearly the same loop in both cases).  
>  Why does copying 160*354 =56,640 bytes need a 3MB task stack?
>  On my P60 a single copy takes a couple of milliseconds.  If your
>program performs such large copies so often that the time matters,
>perhaps this should be viewed as  a golden opportunity to recode such
>foolishness.
>  It certainly would be nice if each compiler came with a crib sheet
>showing what it does especially well or poorly, instead of each
>programmer having to discover for himself (usually painfully).  Does
>the standard Ada benchmark suite (whose name escapes me at the moment)
>include an others/loop timing test?

Sorry I had cut down Active_Errors_List_Range_Type from 160 to 7920!
You may need to retry to get more representative figures.

The clear is only actually done once (in this particular example).
However, even once will still require the stack to be large which is why
it is worse.

The smaller ones will be having a less if still noticeable affect on
performance.

Having found this issue with the 'others' construct, I tend to agree
with you about a benchmark program, I guess it would difficult to
implement, but with all the pipelining and optimisation that can be done
these days on processors I think it should become an issue.

Rob
-- 
Rob Kirkbride