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

Dirk Grunwald <grunwald@foobar.Colorado.EDU>
Wed, 20 Jun 90 04:23:51 GMT

          From comp.compilers

Related articles
[7 earlier articles]
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)
Re: Unsafe Optimizations (formerly Compiler Design in C...) kend%mrloog.wr.tek.com@RELAY.CS.NET (Ken Dickey) (1990-06-21)
Re: Unsafe Optimizations (formerly Compiler Design in C...) chittamu@dino.cs.umass.edu (1990-06-22)
Re: Unsafe Optimizations (formerly Compiler Design in C...) harrison@necssd.NEC.COM (1990-06-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Dirk Grunwald <grunwald@foobar.Colorado.EDU>
Date: Wed, 20 Jun 90 04:23:51 GMT
Office: 6-1 EECR (303) 492-0452
Organization: Compilers Central
Keywords: optimize, code



>>>>> On 14 Jun 90 15:29:39 GMT, larus@primost.cs.wisc.edu (James Larus) said:
JL> applied, programs with bounds checkings ran 0-46% slower than programs
JL> without bounds checking (down from 78-325% slower). That's a pretty


JL> [How does this compare with IBM's results? The papers I've seen on PL.8
JL> suggest that they didn't think bounds checking was very expensive. -John]
JL> --
--


markstein, cocke & markstein report figures of ~2%.


Static insn counts are...


No Check Unopt Checks Opt Checks
Matrix Multiply 2198 2358 2198
Shuttle sort 10382 11826 10583




perhaps the author of the recent paper in SIGPLAN needs to show why
their method doesn't do as well.




Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)
(grunwald@boulder.colorado.edu)
--


Post a followup to this message

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