Raja Subramanian said:
Sridhar R wrote:
But the packages are compiled with i386
optimizations. Why should I go for old compiler
optimizations when I have modern hardware.
Somebody even got theexcels in this aspect.
This is a regular topic on most debian lists.
auto builder working and started compiling theentire debian archive
with 686 optimizations.
your CPU. How much
Its silly to have your entire system optimized for
faster is a 686 optimized version of cp/ls?Consider the logistics
involved here - additional load on package mirrors,distributing bug
fixes, etc and ask yourself if its worth the effort.compatibility over
IMO, Debian has made a good decision by choosing
I'll mention my
This is digressing, but someone wanted benchmarks so
past adventures with CPU optimization. Some yearsago, I compiled gzip
with optimizations and tried to benchmark it. I hadto compress several
GB of data daily and would benefit from a fast gzipbinary.
an AMD k7 -
I used these gzip binaries for testing on a P3 and
o default debian gzip compiled for vanilla i386686
o default redhat/mandrake binaries optimized for
o rolled several gzip binaries from src withvarious optimization
flags (used gcc 2.95)clocked similar
Fair trials were conducted with -
o a 100MB file created from /dev/zero
o a 100MB file created from /dev/random
The disappointing result was that all gzip binaries
run times. CPU optimization was not worth theeffort in this case.
However, the biggest benefit was when I created anunoptimized static
gzip binary, which was ~30% faster than everythingelse.
To unsubscribe, email ilugc-request@xxxxxxxxxxxxx
"unsubscribe <password> address"
in the subject or body of the message.