Autor: mk23z (mk23z_at_bukanier.net)
Data: nie 15 wrz 2002 - 03:37:45 CEST
On Sat, 14 Sep 2002, Lukasz Halman wrote:
>
> > Sprzetowe dodatki (typu MMX, 3D... itp.) [..]
> > SlackWare to nie system. To dopiero narzedzie, przy pomocy
> > ktorego mozesz sobie zbudowac cos tak wydajnego, ze RedHatowca i
> > fizjonomom nawet sie to nie snilo (i za to go kocham :-)))).
> >
> > I dlatego warto uzywac gcc skompilowanego dla 386: bo choc moze
> > nie wykorzystuje procka w wiecej niz 30%, to program ktory dzieki niemu
> > powstanie, bedzie mogl wykorzystac ten procek w 110%.
> >
>
> No nie powiedzialbym, ze masz racje. Dowolny program, ktory jest bardziej
> skomplikowany niz "Hallo World", skompilowany z wszelkimi opcjami dostepnymi
Tak. Ale takie programy jak mc, bash, textutils itp. nie sa
bardziej zaawansowane _sprzetowo_ niz "hallo...". Sa po prostu bardziej
zlozone strukturalnie, ale zbudowano je z tych samych klockow co
przyslowiowe "hallo". Programow bardziej skomplikowanych i zaleznych od
sprzetu w podstawowej dystrybucji nie ma (nawet XFree). Jesli
chcesz takowe miec, musisz je sobie samemu skompilowac, a wtedy hulaj
dusza :-) moj procku.
> dla danego procesora, bedzie dzialal szybciej. I nie dlatego, ze mc w
> trakcie pracy cos wykorzystuje, dlatego, ze gcc utworzylo taki kod wynikowy,
Napisze to jeszcze raz, ale inaczej.
Dla dowolnego programu z podstawowej dystrybucji slacka, roznicy
pomiedzy 386DX a Altonem nie ma! Dlaczego? Bo dajmy na to telnet, nie ma
w swoim kodzie asemblerowej obslugi dodatkowego prockowego rejestru do
szybkich obliczen w grach 3D. Gdyby mial, to pierwszy przekompilowal bym
caly systemowy suff ( patrze tu od strony programu, bo od
strony uzytkownika to czy instrukcja MOV AX,DX jest wykonana w trzech
cyklach, czy w jednym - i czy procek robi 20M czy 1500M cykli na
sekunde - jest bardzo wazne ;-))))
Dla tak specyficznego programu, jakim jest jajko linuxa roznica
jest juz zasadnicza, ale o tym mozna sobie poczytac w kerneltraffic.
> ktory wykorzystuje procesor na poziomie np. Athlon a nie i386. A miedzy 1985
> rokiem a 2000 troche sie tam w tych procesorach pozmienialo...
Myslisz ze kompilator tak naprawde przejmuje sie tym jaki masz
procek? O ile wiem (nie siedze w tym na co dzien) gcc jest rozwijany
glownie w ten sposob, ze obsluga nowych maszynowych instrukcji
najnowszych prockow, jest przede wszystkim dodawana do starego,
sprawdzonego kodu kompilatora. Oznacza to, ze niektore elementarne
kawalki kodu jakiegos programu, sa od iks wersji gcc kompilowane w ten
sam sposob, bez wzgledu na to czy kod wynikowy ma byc dla 486 czy
pentium. Podkreslam, ze mowie tu o kodzie elementarnym typu open, write,
itp. W przeciwnym wypadku tworcy gcc musieliby pisac ten kompilator od
nowa dla kazdego nowego typu procesora. Dlatego przy robieniu takich
programow jak textutils mozesz sobie przy kompilacji zaznaczac opcje
jakie tylko chcesz, a wynik bedziesz mial taki jaki chce kompilator (i
duza czesc kodu bedzie taka jak przy kompilacji dla 386DX).
> A twoj argument o gcc... wybacz, jesli lubisz czekac 2x dluzej na kompilacje
> programu to prosze bardzo.
>
Na szczescie nie jestem zawodowym programista i nie obowiazuje mnie
profesjonalizm w dziedzinie uzywanych narzedzi. Na szczescie, bo jestem
stasznie leniwy, i gdy sobie pomysle o tym, ze trzeba sciagnac zrodla,
przejrzec tomy dokumentacji, doinstalowac dodatkowe pakiety pomocnicze,
poszarpac sie z Makefilami, skompilowac, zainstalowac, a na koncu
jeszcze przetestowac czy wszystko poszlo ok - to juz mi rece opadaja.
Znacznie przyjemniej jest zapuscic sobie kompilacje czegos tam, a na
drugiej konsoli zajac cie czyms produktywnym (Linus - dzieki za system
wieloprocesowy :-), lub krotka partyjka w Adom-a (Boze, to cos za oknem
to juz swit??? :-)))).
Wiem, ze "2x dluzej" napisales przykladowo, ale fajnie by bylo gdyby
ktos, kto dysponuje nadmiarem czasu zrobil serie testow - o ile dluzej
pracuje gcc skompilowany dla 386 od gcc zrobionego na jakis nowszy
procek? Nie sadze, by roznice byly piramidalne, ale kto wie? A moze
potem artykulik do Software, czy Linux+ ? Hmm...?
pozdrawiam
--
Miroslaw Kosmala mailto:mk23z_at_bukanier.net
LinuxRUser #197007 http://www.bukanier.net
"Komplikowanie jest proste,
upraszczanie jest skomplikowane."
To archiwum zostało wygenerowane przez hypermail 2.1.5 : pią 03 sty 2003 - 19:12:40 CET
Wyprawa Shackleton 2014