IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
-mtune=i686 does not differ from -mtune=generic for gcc-4.1.x
(see gcc/config/i386/i386.c for details),
but -mtune=generic is not implemented in older gcc.
- platform.in: Changed %%optflags_kernel to %%nil.
- rpmrc.in: Changed %%optflags_default to use -mtune=generic
instead of -mtune=pentium4 for i[3456]86 (Alexey Tourbin).
We use i586 as our default generic arch for x86 processors.
But -mtune=pentium4 is preferable only for Intel processors,
and possibly disadvantageous for AMD chips.
I suggest we use -mtune=generic instead. Here is what "man gcc" says
about -mtune=generic:
Produce code optimized for the most common IA32/AMD64/EM64T
processors. If you know the CPU on which your code will run, then
you should use the corresponding -mtune option instead of
-mtune=generic. But, if you do not know exactly what CPU users of
your application will have, then you should use this option.
As new processors are deployed in the marketplace, the behavior of
this option will change. Therefore, if you upgrade to a newer
version of GCC, the code generated option will change to reflect the
processors that were most common when that version of GCC was
released.
Now if you're willing to take a look at gcc/gcc/config/i386/i386.c,
you can see that -mtune= option affects only "instruction costs".
For example, AMD chips take fewer cycles to execute some divide/mod
instructions than Intel processors. Instruction costs can affect
peephole optimizer or something to make the resulting instruction
sequence take fewer cycles. It appears that "generic32_cost" provides
reasonable compromise so that the resulting code runs quite well
on all modern CPUs.
Update. I've been requested to provide some numbers.
I use perlbench-0.93 suite to measure libperl.so performance.
A) libperl.so compiled with -march=i586 -mtune=pentium4
B) libperl.so compiled with -march=i586 -mtune=generic
AMD Athlon 64 A B
------------- --- ---
arith/mixed 100 106
arith/trig 100 100
array/copy 100 104
array/foreach 100 94
array/index 100 108
array/pop 100 109
array/shift 100 107
array/sort-num 100 103
array/sort 100 100
call/0arg 100 105
call/1arg 100 96
call/2arg 100 101
call/9arg 100 107
call/empty 100 108
call/fib 100 103
call/method 100 106
call/wantarray 100 107
hash/copy 100 99
hash/each 100 91
hash/foreach-sort 100 96
hash/foreach 100 100
hash/get 100 102
hash/set 100 110
loop/for-c 100 104
loop/for-range-const 100 102
loop/for-range 100 103
loop/getline 100 106
loop/while-my 100 109
loop/while 100 113
re/const 100 104
re/w 100 102
startup/fewmod 100 104
startup/lotsofsub 100 107
startup/noprog 100 100
string/base64 100 102
string/htmlparser 100 102
string/index-const 100 110
string/index-var 100 74
string/ipol 100 105
string/tr 100 102
AVERAGE 100 103
Intel Xeon A B
---------- --- ---
arith/mixed 100 98
arith/trig 100 138
array/copy 100 101
array/foreach 100 100
array/index 100 94
array/pop 100 99
array/shift 100 117
array/sort-num 100 103
array/sort 100 105
call/0arg 100 101
call/1arg 100 97
call/2arg 100 93
call/9arg 100 98
call/empty 100 100
call/fib 100 116
call/method 100 92
call/wantarray 100 101
hash/copy 100 104
hash/each 100 102
hash/foreach-sort 100 102
hash/foreach 100 98
hash/get 100 102
hash/set 100 96
loop/for-c 100 128
loop/for-range-const 100 100
loop/for-range 100 103
loop/getline 100 94
loop/while-my 100 107
loop/while 100 102
re/const 100 99
re/w 100 92
startup/fewmod 100 101
startup/lotsofsub 100 98
startup/noprog 100 101
string/base64 100 100
string/htmlparser 100 70
string/index-const 100 103
string/index-var 100 101
string/ipol 100 105
string/tr 100 94
AVERAGE 100 101
Look ma, I've got about 3% performance boost on Athlon64 and even some
minor improvement on Intel Xeon! Also notice that, on Xeon, the
numbers are more diverse. I believe that the numbers prove that,
compared to -mtune=pentium4, -mtune=generic is beneficial for Athlon64
and at least makes no harm for Xeon.
Here is how to run perlbench:
$ echo ${PWD##*/}
perlbench-0.93
$ cat perl1 perl2
LD_LIBRARY_PATH=$PWD/lib1 exec /usr/bin/perl "$@"
LD_LIBRARY_PATH=$PWD/lib2 exec /usr/bin/perl "$@"
$ ls -l lib?/libperl*
-rw-r--r-- 1 at at 1173944 Jan 9 03:42 lib1/libperl.so.5.8
-rw-r--r-- 1 at at 1204984 Jan 9 03:46 lib2/libperl.so.5.8
$ ./perlbench-run ./perl1 ./perl2
...
- GROUPS: New group: Graphical desktop/Rox (#10268).
- Makefile.am: Link rpm.static with -pthread.
- lib/query.c: Flush query format buffer before listing files (CVE-2006-5466).
- build/parsePrep.c:
+ Change %patch to be more verbose by default, introduce -s option
to make %patch as silent as before this change (#10261).
+ Change %setup to enable -q option by default, introduce -v option
to make %setup as verbose as before this change.
- rpmio/rpmrpc.c (Glob): Override gl_stat to allow broken symlinks.
- Implemented mono reqprov hooks and enabled them by default,
based on patch from Ildar Mulyukov (#9426).
- autodeps/linux.req.in:FindLibReqs():
If object contains .gnu.hash section but does not
contain .hash section, add rtld(GNU_HASH) requirement.
- GROUPS: Removed trailing whitespaces (#9963).
- Rename athlonxp platform to athlon_xp (#9991).
- scripts/brp-compress.in:
Recognize "false|no|none|off" as well as "skip" (#9854).
- scripts/brp-strip.in:
Recognize "skip" as well as "false|no|none|off" (#9854).
- rpmdb: Honor rpmdbInit() return code (#9406).
- rpmQueryVerify(): when rpmReadPackageManifest() is disabled,
treat RPMRC_BADMAGIC return code from rpmReadPackageHeader()
like other read errors (#9433).
- showMatches(): Backported --querybynumber looping fix (#9773).
