dwuliterowe nazwy na kolejne dwie wersje PLD
Filip Kalinski
fk181140 w zodiac.mimuw.edu.pl
Śro, 21 Gru 2005, 01:25:37 CET
On day Wed, Mar 20, 2002 at 09:06:42PM +0100, Tomasz Kłoczko wrote what follows:
>
> Dlaczego dwuliterowa ?
>
> Chodzi o to że potencjalnie dawałoby to możliwość wrzucania tej nazwy do
> etykiet w cvs.
> Dotychchaswe Ra wiadomo jakie miało podteksty .. pierwiastek, egipki bóg
> słońca :)
> Potencjalnie pierwiastów jest na tyle dużo jeszcze do wykorzystania, że
> możnaby się trzymać tego schematu. Prawie każdy z sybboli perwiastków ma
> dodatrkwe pdteksty symbliczne wec w tej kwesti byłoby gucio :)
> Kwestia co najwyżekj które teraz wybrać ? :)
>
> Jeżlie ktoś miałby pomysł na jakieś inny schemat na krótkie nazwy to
> proszę :)
...
Dobry pomysł, popieram!
...
> Przykładowo uważam że nawet na wesję rozwojową PLD jeszcze nadal jest za
> wcześnie na gcc 3.x na x86 (nie mówię tu w tym momencie jeszcze nic o axp,
> sparc czy ppc). Poprostu kod 3.x jest mnie optymalny niż kod
> generowany przez 2.95.x i nadal jest jeszcze sens zostać przy tej wersji
> kompilatora.
>
Pewien czas temu wysłałem porównanie czybkości działania kilku porgramów
na systemach skompilowanych gcc 2.95.4 i gcc 3.0.3, wyniki wykazywały,
że wcale tak nie jest, jeśli chodzi o wydajność, przesiadka na 3.x nie
jest groźna. Załączam jeszce raz wyniki...
--
Filip Kaliński <f.kalinski w zodiac.mimuw.edu.pl>
-------------- następna część ---------
Metodologia
Maszyną testową był Duron 900 z 384 MB RAMu. Dla wyeliminowania wpływu
opracji dyskowych + systemu plików test był dokonywany w katalogu /dev/shm
z zamontowanym tmpfs (tzn. pliki znajowały się w pamięci opracyjnej).
Na tmpfs przydzielony było 280MB, co daje 112MB pamięci opracyjnej.
Do każdego testu instalowane były glibc, gcc, make, bzip2 orar gzip
skompilowane dla odpowiedniej architektury (przez gcc2, lub gcc3). Dodatkowo
używane było odowiadające testowi jądro linuksa 2.4.18-pre7.
Testu odbywały się na nieobciążnonym systemie (jedyne procesy to syslog-ng
oraz klogd) od razu po restarcie systemu.
-----------------------------------------------------------------------------
Skrypt testowy
#!/bin/sh
TIME='/usr/bin/time -p'
BASE=`pwd`
PROG=linux-2.4.16
cp $PROG.tar.bz2 /dev/shm
cd /dev/shm
$TIME -o $BASE/bzip2.time bzip2 -d $PROG.tar.bz2 >/dev/null
tar -xf $PROG.tar >/dev/null
rm -f $PROG.tar
cp $BASE/.config linux/
cd linux
make oldconfig >/dev/null
$TIME -o $BASE/depend.time make depend >/dev/null
$TIME -o $BASE/bzImage.time make bzImage >/dev/null 2>&1
make mrproper >/dev/null
cd ..
tar -cf $PROG.tar linux >/dev/null
rm -rf linux
$TIME -o $BASE/gzip.time gzip $PROG.tar >/dev/null
rm -f $PROG.tar.gz
cd $BASE
------------------------------------------------------------------------------
Wyniki:
----------------------------------------------
| | athlon | i686-gcc3 | i686-gcc2 |
|--------------------------------------------|
|bzip2 | 40.10 | 39.13 | 38.74 |
|depend | 19.87 | 20.09 | 20.68 |
|bzImage | 378.33 | 380.55 | 380.14 |
|gzip | 29.46 | 30.74 | 30.14 |
----------------------------------------------
I porównaie o ile szybkości (ile razy szybszy jest athlon, w %/)
----------------------------------------------
| | athlon | i686-gcc3 | i686-gcc2 |
|--------------------------------------------|
|bzip2 | 100.00 | 96.91 | 97.58 |
|depend | 100.00 | 104.08 | 101.11 |
|bzImage | 100.00 | 100.48 | 100.59 |
|gzip | 100.00 | 102.31 | 104.34 |
----------------------------------------------
W przypadku depend, bzImage i gzip prowadzi (aczkolwiek) nieznacznie athlon.
Warto zauwazyć, że w przypadku bzImage i gzip, mimo, że kompilacja gcc3 nieco
pogoszyła wyniki w tych testach.
Dziwi jedynie wynik testu bzip2, gdzie najlepiej wypada i686-gcc2, a najgorzej
(sic!) athlon.
Wydaje mi się, że ze względu na przyrost szybokości do 5% w niektórych testach
warto spróbować z portem "athlon".
Poza tym widać też, że nie ma co się bać przejścia na gcc 3.0.3, daje on
bowiem kod porównywalny z gcc 2.95.4.
--
Filip Kaliński <f.kalinski w zodiac.mimuw.edu.pl>
Więcej informacji o liście dyskusyjnej pld-devel-pl