Results of 7z-4.55 performance with current GCCs.

Results of 7z-4.55 performance with current GCCs.

[J.C. Pizarro]

------------------------------------------------------------------------------
1. Unpack p7zip_4.55_src_all.tar.bz2
2. Edit CPP/7zip/Bundles/Alone/makefile adding
LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3
3. time make
4. strip --strip-all bin/7za ; ls -l bin/7za ; size bin/7za
5. time dd if=/dev/zero bs=4k count=8k | ./bin/7za a -t7z -m0=lzma -mx=9 \
     -mfb=273 -md=48m -ms=on -si trash.7z  ; ls -l *7z
# User's time is used, machine is Ath64 3200+ 2.0 GHz x1, 64+64K L1, 512K L2.
# Every compilers are compiled with this configure
../configure --prefix=/opt/gcc????????? --disable-shared \
--disable-threads --disable-checking --enable-__cxa_atexit \
--enable-languages=c,c++,fortran,objc --enable-bootstrap
------------------------------------------------------------------------------
1. gcc-3.4.6
------------------------------------------------------------------------------
2. gcc-4.1.3-20071029
export PATH=/opt/gcc41320071029/bin:$PATH
export LD_LIBRARY_PATH=/opt/gcc41320071029/lib
------------------------------------------------------------------------------
3. gcc-4.2.3-20071031
export PATH=/opt/gcc42320071031/bin:$PATH
export LD_LIBRARY_PATH=/opt/gcc42320071031/lib
------------------------------------------------------------------------------
4. gcc-4.3.0-20071026
export PATH=/opt/gcc43020071026/bin:$PATH
export LD_LIBRARY_PATH=/opt/gcc43020071026/lib
------------------------------------------------------------------------------
LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3

1. 1m24s compile, 1184180 file, 1172634 text, 6124 data, 27168 bss, 0m17s run.
2. 1m30s compile, 1204640 file, 1188955 text, 4684 data, 29160 bss, 0m25s run.
3. 1m44s compile, 1208640 file, 1192995 text, 4688 data, 29128 bss, 0m22s run.
4. 1m45s compile, 1336068 file, 1319986 text, 4396 data, 29128 bss, 0m52s run.
------------------------------------------------------------------------------
LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3 \
             -funroll-all-loops -finline-functions

1. 1m46s compile, 1731956 file, 1720453 text, 6124 data, 27168 bss, 0m12s run.
2. 1m51s compile, 1762528 file, 1746859 text, 4684 data, 29160 bss, 0m15s run.
3. 2m06s compile, 1779040 file, 1763367 text, 4688 data, 29128 bss, 0m18s run.
4. 2m35s compile, 2287204 file, 2271122 text, 4396 data, 29128 bss, 0m17s run.
------------------------------------------------------------------------------
LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3 \
             -funroll-loops -finline-functions

1. 1m42s compile, 1628564 file, 1617041 text, 6124 data, 27168 bss, 0m12s run.
2. 1m47s compile, 1627328 file, 1611675 text, 4684 data, 29160 bss, 0m15s run.
3. 2m00s compile, 1595072 file, 1579407 text, 4688 data, 29128 bss, 0m18s run.
4. 2m26s compile, 2108964 file, 2092866 text, 4396 data, 29128 bss, 0m17s run.
------------------------------------------------------------------------------
LOCAL_FLAGS+=-O2 -fomit-frame-pointer -march=i686 -msse3 \
             -funroll-loops -finline-functions

1. 1m37s compile, 1564884 file, 1553374 text, 6124 data, 27168 bss, 0m13s run.
2. 1m45s compile, 1625152 file, 1609475 text, 4684 data, 29160 bss, 0m15s run.
3. 1m58s compile, 1593280 file, 1577599 text, 4688 data, 29128 bss, 0m18s run.
4. 1m52s compile, 1623044 file, 1606958 text, 4396 data, 29128 bss, 0m17s run.
------------------------------------------------------------------------------
LOCAL_FLAGS+=-Os -fomit-frame-pointer -march=i686 -msse3 \
             -funroll-loops -finline-functions

1. 1m34s compile, 1506228 file, 1494339 text, 6124 data, 27168 bss, 0m13s run.
2. 1m05s compile,  879552 file,  863302 text, 4680 data, 29224 bss, 0m27s run.
3. 1m15s compile,  869624 file,  854430 text, 4228 data, 28996 bss, 0m25s run.
4. 1m08s compile,  957428 file,  941816 text, 3932 data, 28900 bss, 0m21s run.
------------------------------------------------------------------------------

Summary:
--------
The best compiler for p7zip-4.55 is gcc-3.4.6 and its best option is
-O3 -fomit-frame-pointer -march=i686 -msse3 -funroll-loops -finline-functions

The compile's and run's time of gcc-3.4.6 is the fastest, and i don't know
why the modern gcc4's family is little bit slower than the older gcc3's family.

The gcc-4.3 snapshot is worse than gcc-4.2/gcc-4.1 in the code generation,
due to its bad code size (~2.3MB) and sometimes long run time (52s).

------------------------------------------------------------------------------

   J.C. Pizarro

Re: Results of 7z-4.55 performance with current GCCs.

[NightStrike]

On 11/1/07, J.C. Pizarro <jcpiza@gmail.com> wrote:
> The compile's and run's time of gcc-3.4.6 is the fastest, and i don't know
> why the modern gcc4's family is little bit slower than the older gcc3's family.

I would think it'd be only natural for a newer generational compiler
to require more time to compile a large application.  If you think
about it in terms of what is actually going on behind the scenes, the
newer compiler is running more checks, doing more optimizations, and
generally working harder to produce decent, efficient, bug-free code.
I think what is more important is the resulting binary -- does it run
faster?  Do optimizations work better?  Is the resulting executable
easier to debug?  Is it more stable?  etc etc.  All of these things
come with a maturing compiler (some to more degree than others,
obviously).  The real question is this -- what is your compiler time
metric actually showing you, and what do you intend for it to show?
What conclusions do you hope to draw from it?

Re: Results of 7z-4.55 performance with current GCCs.

[David Miller]

From: NightStrike <nightstrike@gmail.com>
Date: Thu, 1 Nov 2007 22:34:33 -0400

> I think what is more important is the resulting binary -- does it
> run faster?

The answer to this is situational dependant.

For example, for me, the speed of compilation at -O2 is very important
because I'm constantly doing full tree build regressions.

There are large groups of us who pine for compilation to be as fast
as the old MIPS compilers were, and they were fully optimizing
and even had a more advanced register allocator than GCC has now.

Re: Results of 7z-4.55 performance with current GCCs.

[Ted Byers]

--- David Miller <davem@davemloft.net> wrote:
> From: NightStrike <nightstrike@gmail.com>
> Date: Thu, 1 Nov 2007 22:34:33 -0400
> 
> > I think what is more important is the resulting
> binary -- does it
> > run faster?
> 
> The answer to this is situational dependant.
> 
> For example, for me, the speed of compilation at -O2
> is very important
> because I'm constantly doing full tree build
> regressions.
> 
> There are large groups of us who pine for
> compilation to be as fast
> as the old MIPS compilers were, and they were fully
> optimizing
> and even had a more advanced register allocator than
> GCC has now.
> 
I find it hard to fathom why the OP would be concerned
with compile and run times measured in minutes and
seconds. I don't know how long your full tree build
regressions take, but for me, a very small application
will take half an hour to compile, and a large one
could take all day.  But if by hand tuning my code,
and pushing my development tools to their limits, I
can have my application finish a task in minutes where
my predecessors' versions took hours (something I
commonly see, perhaps by chance, with the projects I
find myself working on), the savings of my clients'
users' time is greater than the cost of my time by
several orders of magnitude, so I don't mind waiting
for a build to finish if the end product is provably
correct.

There is much more to both compile time and run time
performance than how fast your development tools are. 
I expect more recent tools to take longer than the
tools I used even five years ago, simply because there
is much more for them to do; and as they get better, I
can use more demanding parts of the language (my
preferred language is C++) that simply weren't
practical a few years ago.  As I do this, then my
tools must work harder still.  It isn't only the
tools, but what you do with them ...

If I may state the obvious, an outstanding programmer
can easily make a mediocre development tool look good,
while a mediocre programmer can make even the best
tools look very bad.  That said, I often download open
source applications (all good quality), and the GCC
suite takes longer to build than all the rest combined
(that is, of the ones I download), and since that
finishes in but a few hours on my machine, I won't
worry about how fast gcc compiles code until it takes
many days to compile itself.  :-)

As you say, performance questions and answers depend
on the situation.  But I say, the single most
important question is, "Is the code correct?"  that
is, does it produce output that is provably correct. 
There is no point in having an insanely fast program
if it only, or even only generally, produces garbage. 
As important as performance is, the correctness of the
code is, to my mind, infinitely more important than
either compile or runtime performance!

I would encourage the good folk who work on GCC to
focus on making the code correct first, and only after
that can be proven, worry about making it faster. 
Really bad things can happen to real people if my
programs give incorrect results (think about things
like contaminant transport, dose/risk assessments,
&c., and how someone I have never met may suffer if my
application gives a consultant or civil servant
unreliable results).  When you think about the things
relevant to the work I do, you will understand why I
don't care if my build times are measured in hours or
days or even weeks as long as my clients' users' can
work more efficiently and obtain provably correct
results from my programs.  Computers are cheap these
days, so if I find myself too often waiting for a
build to complete, I'l just get another computer to
work on while I wait for the one doing the build to
finish.

I don't help develop GCC, but may I express to those
that do that I apreciate their efforts.

Cheers,

Ted

Re: Results of 7z-4.55 performance with current GCCs.

[NightStrike]

On 11/1/07, Ted Byers <r.ted.byers@rogers.com> wrote:
> --- David Miller <davem@davemloft.net> wrote:
> > From: NightStrike <nightstrike@gmail.com>
> > Date: Thu, 1 Nov 2007 22:34:33 -0400
> >
> > > I think what is more important is the resulting
> > binary -- does it
> > > run faster?
> >
> > The answer to this is situational dependant.
> >
> > For example, for me, the speed of compilation at -O2
> > is very important
> > because I'm constantly doing full tree build
> > regressions.
> >
> > There are large groups of us who pine for
> > compilation to be as fast
> > as the old MIPS compilers were, and they were fully
> > optimizing
> > and even had a more advanced register allocator than
> > GCC has now.
> >
> I find it hard to fathom why the OP would be concerned
> with compile and run times measured in minutes and
> seconds. I don't know how long your full tree build
> regressions take, but for me, a very small application
> will take half an hour to compile, and a large one
> could take all day.  But if by hand tuning my code,
> and pushing my development tools to their limits, I
> can have my application finish a task in minutes where
> my predecessors' versions took hours (something I
> commonly see, perhaps by chance, with the projects I
> find myself working on), the savings of my clients'
> users' time is greater than the cost of my time by
> several orders of magnitude, so I don't mind waiting
> for a build to finish if the end product is provably
> correct.
>
> There is much more to both compile time and run time
> performance than how fast your development tools are.
> I expect more recent tools to take longer than the
> tools I used even five years ago, simply because there
> is much more for them to do; and as they get better, I
> can use more demanding parts of the language (my
> preferred language is C++) that simply weren't
> practical a few years ago.  As I do this, then my
> tools must work harder still.  It isn't only the
> tools, but what you do with them ...
>
> If I may state the obvious, an outstanding programmer
> can easily make a mediocre development tool look good,
> while a mediocre programmer can make even the best
> tools look very bad.  That said, I often download open
> source applications (all good quality), and the GCC
> suite takes longer to build than all the rest combined
> (that is, of the ones I download), and since that
> finishes in but a few hours on my machine, I won't
> worry about how fast gcc compiles code until it takes
> many days to compile itself.  :-)
>
> As you say, performance questions and answers depend
> on the situation.  But I say, the single most
> important question is, "Is the code correct?"  that
> is, does it produce output that is provably correct.
> There is no point in having an insanely fast program
> if it only, or even only generally, produces garbage.
> As important as performance is, the correctness of the
> code is, to my mind, infinitely more important than
> either compile or runtime performance!
>
> I would encourage the good folk who work on GCC to
> focus on making the code correct first, and only after
> that can be proven, worry about making it faster.
> Really bad things can happen to real people if my
> programs give incorrect results (think about things
> like contaminant transport, dose/risk assessments,
> &c., and how someone I have never met may suffer if my
> application gives a consultant or civil servant
> unreliable results).  When you think about the things
> relevant to the work I do, you will understand why I
> don't care if my build times are measured in hours or
> days or even weeks as long as my clients' users' can
> work more efficiently and obtain provably correct
> results from my programs.  Computers are cheap these
> days, so if I find myself too often waiting for a
> build to complete, I'l just get another computer to
> work on while I wait for the one doing the build to
> finish.
>
> I don't help develop GCC, but may I express to those
> that do that I apreciate their efforts.

I agree with you 100%.  It has always been my view that if you can't
compile fast enough, then get another machine and use distcc, or get a
quad core and do make -j5, etc etc.  Compile time should never
outweigh code correctness, and if it takes longer to compile more
correct code, then that's just the nature of moving forward into the
future.

Re: Results of 7z-4.55 performance with current GCCs.

[J.C. Pizarro]

2007/11/2, NightStrike <nightstrike@gmail.com>:
> On 11/1/07, Ted Byers <r.ted.byers@rogers.com> wrote:
> > --- David Miller <davem@davemloft.net> wrote:
> > > ...
>
> I agree with you 100%.  It has always been my view that if you can't
> compile fast enough, then get another machine and use distcc, or get a
> quad core and do make -j5, etc etc.  Compile time should never
> outweigh code correctness, and if it takes longer to compile more
> correct code, then that's just the nature of moving forward into the
> future.

"Save the planet and don't add more wood to the fire".

Re: Results of 7z-4.55 performance with current GCCs.

[David Miller]

From: NightStrike <nightstrike@gmail.com>
Date: Fri, 2 Nov 2007 10:42:01 -0400

> I agree with you 100%.  It has always been my view that if you can't
> compile fast enough, then get another machine and use distcc, or get a
> quad core and do make -j5, etc etc.

I have 64 cpu machines and use make -j64, it's still not fast enough
and I know it could be much faster.

Note that a faster GCC would also make GCC development go
significantly quicker, since every developer has to do a full
bootstrap and regression run before checking in non-trivial changes.

The world is not black and white, it is shades of gray.  Compilation
time matters to some people, and I'm not in the slightest suggesting
that it should trump code correctness.  I don't know where anyone got
that idea from what I've been saying.

Re: Results of 7z-4.55 performance with current GCCs.

[Ted Byers]

--- David Miller <davem@davemloft.net> wrote:

> From: NightStrike <nightstrike@gmail.com>
> Date: Fri, 2 Nov 2007 10:42:01 -0400
> 
> > I agree with you 100%.  It has always been my view
> that if you can't
> > compile fast enough, then get another machine and
> use distcc, or get a
> > quad core and do make -j5, etc etc.
> 
> I have 64 cpu machines and use make -j64, it's still
> not fast enough
> and I know it could be much faster.
> 
> Note that a faster GCC would also make GCC
> development go
> significantly quicker, since every developer has to
> do a full
> bootstrap and regression run before checking in
> non-trivial changes.
> 
> The world is not black and white, it is shades of
> gray.  Compilation
> time matters to some people, and I'm not in the
> slightest suggesting
> that it should trump code correctness.  I don't know
> where anyone got
> that idea from what I've been saying.
> 

I don't think anyone got that idea about your
position, but I have repeatedly seen posts about the
performance of tools, some emphasizing that the speed
of a compile is the top priority.  I just can't find,
right now, the post that was most emphatic about the
speed of compilation taking priority over all else. 
Maybe it is noise from other threads, possibly in
other lists I read, and then I see the post from the
OP about compiles that run to completion in mere
minutes.  Maybe that was the trigger that compelled me
to write about correctness trumping all else, and
other options for being productive when complete
builds take a while.  And I agreed with you that much
in the weighting of priorities is situation dependant.

On a different note, I wish I had your budget for
hardware.  :-)  With the kind of work I find most
interesting, one can never have too much hardware to
throw at a problem, and you all too easily start
hitting your head on the limits of of whatever
hardware you do have.  I know people that set up
computing clusters, with outrageously expensive
machines (relative to my budget) along with terabyte
data storage solutions, and still their environmental
models take weeks to finish.  And then the programs
required to analyze the data produced are even more
demanding.  There simply are problems I, and my peers,
would like to tackle but the computational resources
available are simply too constrainted to make an
attempt with the most defensible models without
greatly simplifying the models to be used.  Is such a
situation, the time taken by the development tools is
nothing.  But I can see others who answer to bean
counters who would place more priority on the speed of
the development tools and the impact that has on
programmer productivity.

I apologize if what I wrote created an incorrect
impression of what you had to say.  That was not what
intended.

Ted

Re: Results of 7z-4.55 performance with current GCCs.

[David Miller]

From: Ted Byers <r.ted.byers@rogers.com>
Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)

> On a different note, I wish I had your budget for
> hardware.  :-)

What budget?

These systems sit right at here with me at home, and I got all of them
for free.

Re: Results of 7z-4.55 performance with current GCCs.

[Ted Byers]

--- David Miller <davem@davemloft.net> wrote:
> From: Ted Byers <r.ted.byers@rogers.com>
> Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> 
> > On a different note, I wish I had your budget for
> > hardware.  :-)
> 
> What budget?
> 
> These systems sit right at here with me at home, and
> I got all of them
> for free.
> 
How did you manage to get such machines for free?

Ted

Re: Results of 7z-4.55 performance with current GCCs.

[Joe Buck]

On Sun, Nov 04, 2007 at 01:32:16AM -0400, Ted Byers wrote:
> --- David Miller <davem@davemloft.net> wrote:
> > From: Ted Byers <r.ted.byers@rogers.com>
> > Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> > 
> > > On a different note, I wish I had your budget for
> > > hardware.  :-)
> > 
> > What budget?
> > 
> > These systems sit right at here with me at home, and
> > I got all of them
> > for free.
> > 
> How did you manage to get such machines for free?

By being David Miller, or rather, by doing what David Miller does
(e.g. primary maintainer of Linux's networking stack as well as the Sparc
port of Linux, and a maintainer of Sparc port of gcc, in addition to many
other contributions to free software).

Re: Results of 7z-4.55 performance with current GCCs.

[David Miller]

From: Ted Byers <r.ted.byers@rogers.com>
Date: Sun, 4 Nov 2007 01:32:16 -0400 (EDT)

> --- David Miller <davem@davemloft.net> wrote:
> > From: Ted Byers <r.ted.byers@rogers.com>
> > Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> > 
> > > On a different note, I wish I had your budget for
> > > hardware.  :-)
> > 
> > What budget?
> > 
> > These systems sit right at here with me at home, and
> > I got all of them
> > for free.
>
> How did you manage to get such machines for free?

Well if you put 2 and 2 together, you'd check and notice that I
maintain the sparc64 port of Linux.  As a result you might imagine
that I have acquired quite a number of Niagara systems.