Newsgroups: | comp.compilers |
From: | barmar@Think.COM (Barry Margolin) |
References: | <1990Jun13.143951.2129@esegue.segue.boston.ma.us> <1990Jun12.163959.2593@esegue.segue.boston.ma.us> <1990Jun14.152939.2578@esegue.segue.boston.ma.us> |
Date: | Fri, 15 Jun 90 23:29:26 GMT |
Organization: | Thinking Machines Corporation, Cambridge MA, USA |
Keywords: | code, optimize |
In article <1990Jun14.152939.2578@esegue.segue.boston.ma.us> larus@primost.cs.wisc.edu (James Larus) writes:
[Regarding optimizing array bounds checking:]
>After all optimizations were
>applied, programs with bounds checkings ran 0-46% slower than programs
>without bounds checking (down from 78-325% slower). That's a pretty
>large performance degredation, considering it also had a large cost in
>compiler time and complexity.
Looks to me like it was a performance improvement, not a degradation, from
325% slower to 46% slower. Assuming N% slower means that programs take
1+N/100 times as much time to run (I haven't read the paper, so I don't
know what the actual numbers are), this is almost a 3x improvement. What
were you expecting, miracles? Without architectural support it's hard to
optimize out all the overhead of array bounds checking, so you have to
accept a tradeoff.
And, according to the numbers you quote, some programs aren't slowed down
at all, so it's possible to optimize out all the overhead of bounds
checking in some cases.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.