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.
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
> >
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 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, 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 pg
: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 single
:>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 wa
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
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 st
: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 egcs/l
> -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 compi
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 -m alone are worthless, it's the
-march's that matter (note i say most to mean of the 4 architectures i've
played with -m and -march
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)
[...]
> -mp
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
>
> 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 i
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
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 "unsubscri
: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?
:
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
: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 bene
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. -m does not change
> the assembly output at all.
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 k
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 better
23 matches
Mail list logo
