Alex Zepeda wrote:
On Mon, 5 Apr 1999, Matthew Dillon wrote:
There is nothing beyond -O2. Well, there's -O3, which tries to
inline static functions, but that typically isn't beneficial because
it really bloats up the code and subroutine calls on intel cpus are
very
On Tue, 6 Apr 1999, David O'Brien wrote:
Well what would be the chances of getting the pgcc patches committed?
I'm quite interested in doing this, BUT only after the dust has settled
on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC
patches aren't available yet.
In the last episode (Apr 05), Alex Zepeda said:
Have you tried anything beyond -O2?
There is only -O3, which is just like -O2 except that it tries to
inline all functions.
-Dan Nelson
dnel...@emsphone.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe
On Mon, 5 Apr 1999, Matthew Dillon wrote:
There is nothing beyond -O2. Well, there's -O3, which tries to
inline static functions, but that typically isn't beneficial because
it really bloats up the code and subroutine calls on intel cpus are
very fast.
When I tested this
There is nothing beyond -O2. Well, there's -O3, which tries to
inline static functions, but that typically isn't beneficial because
it really bloats up the code and subroutine calls on intel cpus are
very fast.
The only other optimization that might be useful is
Matthew Dillon wrote:
:Totally informally, I replaced libc (compiled with -O2) with one compiled
:with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit
:slower (GNU make took longer to traverse directories and egcs took a bit
:longer to run).
:
: Which leads me to
Hi,
At 2:15 am -0700 6/4/99, Daniel Berlin wrote:
Also, -mpentiumpro will actually usually generate WORSE code for a pentium
pro.
-mpentium and -march=pentium do better at it.
OK, but according to man cc:
NAME
gcc, g++ - GNU project C and C++ Compiler (egcs-1.1.2)
[...]
-mpentium
I always use both (because it's in my darn makefiles :P), but that sounds
correct to me. If it said -mpentium implied -march=pentium, i'd say it's
lying.
most of the -mwhatever architecture alone are worthless, it's the
-march's that matter (note i say most to mean of the 4 architectures i've
-Original Message-
From: Matthew Dillon [mailto:dil...@apollo.backplane.com]
Sent: 06 April 1999 05:58
To: curr...@freebsd.org
Subject: EGCS optimizations
Compiling up /usr/src/usr.sbin with egcs and libc compiled with:
-O2 160
:I doubt that that sort of benchmark is going to say an awful lot about the
:performance of the optimisation levels since compiling /usr/sr/usr.sbin is
:going to be affected by disk i/o performance far more than it would be by
:cpu performance. The relative speed differences of the different
In message 199904062001.naa10...@apollo.backplane.com, Matthew Dillon writes:
That test was 100% cpu bound. There was no ( significant ) I/O. I ran
it a few times to build the cache before timing it.
What is the stddev on your measurements ?
a delta-T 1 second need a very tight
On Mon, 5 Apr 1999, Alex Zepeda wrote:
On Mon, 5 Apr 1999, Matthew Dillon wrote:
There is nothing beyond -O2. Well, there's -O3, which tries to
inline static functions, but that typically isn't beneficial because
it really bloats up the code and subroutine calls on intel
:it a few times to build the cache before timing it.
:
:What is the stddev on your measurements ?
:
:a delta-T 1 second need a very tight stddev to be significant.
The timing was +/- 0.5 second ( I ran the test four times ). But, remember,
this is not comparing against GCC. This
:What is the stddev on your measurements ?
:
:a delta-T 1 second need a very tight stddev to be significant.
I would say that a 1% increase or decrease in performance is not
significant, so stddev is not significant either. There are too many
other factors ( such as running a
On Tue, 6 Apr 1999, Matthew Dillon wrote:
It's no big deal, really. I think the EGCS bandwagon is going to continue
to move forward and PGCS runs on top of it, so moving to EGCS puts FreeBSD
in a better position in the long term.
Well what would be the chances of getting the pgcc
Well what would be the chances of getting the pgcc patches committed?
I'm quite interested in doing this, BUT only after the dust has settled
on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC
patches aren't available yet.
jdp and I have another round of bootstraping to fix
On Tue, 6 Apr 1999, David O'Brien wrote:
Well what would be the chances of getting the pgcc patches committed?
I'm quite interested in doing this, BUT only after the dust has settled
on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC
patches aren't available yet.
Well, I played around with egcs a bit. I had blown away my original gcc
install so I couldn't compare egcs w/ gcc, but I did mess around with
egcs's optimization options.
My conclusion: Don't bother with -mpentiumpro or -march=pentiumpro.
Not only do they not result in
Hmm. interesting. My test kernel under GCC was considerably smaller then
my test kernel under EGCS, even with -Os.
textdata bss dec hex filename
1287575 95512 122972 1506059 16fb0b kernel.gcc -O2
1326304 111628 125708 1563640 17dbf8
On Mon, 5 Apr 1999, Matthew Dillon wrote:
My conclusion: Don't bother with -mpentiumpro or -march=pentiumpro.
Not only do they not result in better performance, -march=pentiumpro
will not run on a K6-2. I dunno about a K6-3. -mcpu does not change
the assembly output at all.
:Totally informally, I replaced libc (compiled with -O2) with one compiled
:with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit
:slower (GNU make took longer to traverse directories and egcs took a bit
:longer to run).
:
: Which leads me to believe that using -Os might be
On Mon, 5 Apr 1999, Matthew Dillon wrote:
There is nothing beyond -O2. Well, there's -O3, which tries to
inline static functions, but that typically isn't beneficial because
it really bloats up the code and subroutine calls on intel cpus are
very fast.
Really?
The pgcc web
:On Mon, 5 Apr 1999, Matthew Dillon wrote:
:
: There is nothing beyond -O2. Well, there's -O3, which tries to
: inline static functions, but that typically isn't beneficial because
: it really bloats up the code and subroutine calls on intel cpus are
: very fast.
:
:Really?
:
23 matches
Mail list logo
