This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Benchmarks: 7z, bzip2 & gzip.
- From: Bernardo Innocenti <bernie at codewiz dot org>
- To: "J.C. Pizarro" <jcpiza at gmail dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 04 Mar 2008 20:21:51 +0100
- Subject: Re: Benchmarks: 7z, bzip2 & gzip.
- References: <998d0e4a0802290748y3d4535c4qd780fb1533c0ce8c@mail.gmail.com>
J.C. Pizarro wrote:
> p7zip-4.57
> [...]
> 1. 1m50s compile, 1630164 file, 1618639 text, 6120 data, 27168 bss, 5m50s run.
> 2. 1m53s compile, 1665952 file, 1649829 text, 4668 data, 29160 bss, 6m04s run.
> 3. 2m08s compile, 1629088 file, 1613313 text, 4672 data, 29160 bss, 5m54s run.
> 4. 2m36s compile, 2063216 file, 2047420 text, 4380 data, 29160 bss, 6m14s run.
> 5. 2m30s compile, 1976228 file, 1960164 text, 4380 data, 29160 bss, 6m12s run.
Has anybody analyzed this code size and performance regression?
For simplicity, we could limit our comparison to 3 (gcc-4.2.4)
against 4 (gcc-4.3.0) or 5 (gcc-4.4.0).
For the performance regression, one could proceed like this:
- profile the 7z run to find the hot-spot(s)
- disassemble the output of both compilers
- look for obvious pessimizations in the hot parts
We're looking for a 6-7% change in time, so it may very well
be a single instruction.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/