From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam To: <9fans@cse.psu.edu> Subject: Re: [9fans] how to avoid a memset() optimization In-Reply-To: <20021114103413.A20538@sigint.cs.purdue.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 14 Nov 2002 10:59:15 -0500 Topicbox-Message-UUID: 1fa7630c-eacb-11e9-9e20-41e7f4b1d025 Let's define "slow." The last time I did a performance test was on a des module I wrote. The gcc compiled -02 ran .2-.4 seconds faster (out of 3-4s). Further optlevels were not any better. Anyone have any numbers showing that, "without optimizations, this simply wouldn't be tolerable," in the face of well written code? In these instances does the compiler generate crap code from the start, expecting an optimizer to come clean it up later? We wrote a C compiler for the language as of about '73 for a coldfire target and it was a very telling experience. It was rather obvious that a simple peephole optimizer would handle most of the inefficiencies in the generated assy. The code ran fast enough for our purpose, however, so we didn't bother. Indeed, the human-time component is the most expensive resource. It's a shame 95% of the world doesn't understand that. Cheers, Sam On Thu, 14 Nov 2002 plan9@sigint.cs.purdue.edu wrote: > On Thu, Nov 14, 2002 at 04:26:08PM +0100, Boyd Roberts wrote: > > I'd rather have slow and right over fast and broken. > > You and the other 5% of the world's consumers. >