Re: Unsafe Optimizations (formerly Compiler Design in C...)

barmar@Think.COM (Barry Margolin)
Fri, 15 Jun 90 23:29:26 GMT

          From comp.compilers

Related articles
[3 earlier articles]
Re: Unsafe Optimizations (formerly Compiler Design in C...) marti@inf.ethz.ch (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) larus@primost.cs.wisc.edu (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) grover@brahmand.Eng.Sun.COM (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) MERRIMAN@ccavax.camb.com (George Merriman -- CCA/NY) (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) pardo@june.cs.washington.edu (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) barmar@Think.COM (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) henry@zoo.toronto.edu (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) dan@kfw.com (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) chip@tct.uucp (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) grunwald@foobar.Colorado.EDU (Dirk Grunwald) (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) marti@inf.ethz.ch (1990-06-21)
Re: Unsafe Optimizations (formerly Compiler Design in C...) pardo@june.cs.washington.edu (1990-06-21)
[3 later articles]
| List of all articles for this month |

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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.