Re: [9fans] GUI toolkit for Plan 9

[andrey mirtchovski <andrey@lanl.gov>]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

> 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


[-- Attachment #2: Type: message/rfc822, Size: 3775 bytes --]

From: Quinn Dunkan <quinn@bolivar.ugcs.caltech.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Tue, 26 Feb 2002 09:48:39 -0800
Message-ID: <20020226174844.9D73634086@bolivar.ugcs.caltech.edu>


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