From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] GUI toolkit for Plan 9 From: andrey mirtchovski MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-uhzycouzfsbuzehinumzkbtfis" Message-Id: <20020226175826.A0EC319A84@mail.cse.psu.edu> Date: Tue, 26 Feb 2002 11:00:51 -0700 Topicbox-Message-UUID: 57175118-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-uhzycouzfsbuzehinumzkbtfis Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > On the other hand, though I hardly use C much (though I compile a lot of it), I > have had weird behaviour under -O2, which went away when I removed it. The gcc > people are always messing with the optimizer. That personal experience > combined with reading docs that say things like "the loop unroller is buggy, so > be careful when you use -O3" (and what's the deal with all this -O6 stuff? I > thought -O3 was the "possible overkill, may slow down code more than speed it > up" setting) has made me paranoid and now when the compiler segfaults or the > program segfaults (often C generated by a compiler for another language, which > is probably particularly strangely written), the first thing I do is remove -O. > And it sometimes fixes the problem. For example, the sather compiler will > segfault if compiled with -O. http://www.netlib.org/benchweb has several integer-intensive cpu benchmarks. i downloaded the tower of hanoi to try a few benchy-marks just to continue yesterday's tests. i gave up after finding out that the optimized fbsd ran slower than the unoptimized one (2.95).. same behaviour was observed with gcc3.0 on linux... i can only explain this with the recursive structure of the program... having such (weird?) results kind-of defeats the purpose of doing a benchmark... so i never looked at compiling it on p9 if anyone else is interested, the cpu section of the abovementioned web page has some more programs. i tried a few but didn't find anything interesting --upas-uhzycouzfsbuzehinumzkbtfis Content-Type: message/rfc822 Content-Disposition: inline Received: from acl.lanl.gov ([128.165.147.1]) by acl.lanl.gov; Tue Feb 26 10:50:12 MST 2002 Received: (qmail 2203163 invoked by uid 18927); 26 Feb 2002 10:50:12 -0700 Delivered-To: andrey@acl.lanl.gov Received: (qmail 2079077 invoked from network); 26 Feb 2002 10:49:15 -0700 Received: from mailrelay2.lanl.gov (128.165.5.47) by acl.lanl.gov with SMTP; 26 Feb 2002 10:49:15 -0700 Received: from mailproxy1.lanl.gov (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (8.11.6/8.11.6/(ccn-5)) with ESMTP id g1QHnFA16173; Tue, 26 Feb 2002 10:49:15 -0700 Received: from mail.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mailproxy1.lanl.gov (8.11.6/8.11.6/(ccn-5)) with ESMTP id g1QHox216545; Tue, 26 Feb 2002 10:50:59 -0700 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 6EB1B19A7B; Tue, 26 Feb 2002 12:49:10 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from bolivar.ugcs.caltech.edu (bolivar.ugcs.caltech.edu [131.215.43.204]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id A1E8F19A68 for <9fans@cse.psu.edu>; Tue, 26 Feb 2002 12:48:49 -0500 (EST) Received: by bolivar.ugcs.caltech.edu (Postfix, from userid 2738) id 9D73634086; Tue, 26 Feb 2002 09:48:44 -0800 (PST) Received: from bolivar.ugcs.caltech.edu (localhost [127.0.0.1]) by bolivar.ugcs.caltech.edu (Postfix) with ESMTP for <9fans@cse.psu.edu> id 47470F803; Tue, 26 Feb 2002 09:48:39 -0800 (PST) To: 9fans@cse.psu.edu Subject: Re: [9fans] GUI toolkit for Plan 9 In-Reply-To: Your message of "Tue, 26 Feb 2002 17:13:14 GMT." <87664kgoie.fsf@becket.becket.net> From: Quinn Dunkan Message-Id: <20020226174844.9D73634086@bolivar.ugcs.caltech.edu> Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Tue, 26 Feb 2002 09:48:39 -0800 > rob@plan9.bell-labs.com (rob pike) writes: > > > Ten percent buys you, what, a couple of weeks of Moore's Law? I'm not > > against fast compilers - I'm actually rather impressed by good > > compilers - but I do fret about optimizing compilers breaking my code. > > Oh, of course, but that's a matter of writing correct code. > > Your concern reminds me of people who are scared of garbage collection > because they think it will have a bug and free live memory. I've always used gc-ed languages, and I've never had any problems due to buggy gc (except some surprising performance differences between cmucl on x86 and cmucl on everything else, since they use different gcs). Once they get the gc right they tend to leave it alone. On the other hand, though I hardly use C much (though I compile a lot of it), I have had weird behaviour under -O2, which went away when I removed it. The gcc people are always messing with the optimizer. That personal experience combined with reading docs that say things like "the loop unroller is buggy, so be careful when you use -O3" (and what's the deal with all this -O6 stuff? I thought -O3 was the "possible overkill, may slow down code more than speed it up" setting) has made me paranoid and now when the compiler segfaults or the program segfaults (often C generated by a compiler for another language, which is probably particularly strangely written), the first thing I do is remove -O. And it sometimes fixes the problem. For example, the sather compiler will segfault if compiled with -O. --upas-uhzycouzfsbuzehinumzkbtfis--