This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: mips64*-*-linux multi arch handling
- From: Adam Nemet <anemet at caviumnetworks dot com>
- To: Laurent GUERBY <laurent at guerby dot net>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, Eric Christopher <echristo at gmail dot com>, Paolo Bonzini <bonzini at gnu dot org>, gcc <gcc at gcc dot gnu dot org>, doko <doko at debian dot org>
- Date: Wed, 04 Mar 2009 11:00:57 -0800
- Subject: Re: mips64*-*-linux multi arch handling
- References: <1235651945.11347.270.camel@localhost> <87wsbcvrir.fsf@firetop.home> <1236187113.11347.1135.camel@localhost>
Thanks for measuring these.
Laurent GUERBY <laurent@guerby.net> writes:
> For bzip2 trunk regress badly in performance against 4.3.2
> but n32 is indeed relatively faster than 32 (still slower than 4.3.2).
> For gzip trunk matches 4.3.2 but n32 is slower than 32 and 64 even
> slower.
Last time I checked (on Octeon) gzip was completely dominated by the hash
table search of the deflation code. The new ABIs shine when you have function
calls or 64-bit arithmetic, which I don't think is the case in gzip.
I might look at the 4.3.2->trunk regressions (if I can reproduce on Octeon).
Adam