-Os

[Robert Kurtys]

On Thursday 01 May 2003 00:46, Tomasz Pala wrote:
> On Wed, Apr 30, 2003 at 23:51:34 +0200, Robert Kurtys wrote:
> > > Gdzie mają być określone optymalizacje 'specjalnego'
> > > (optymalizowane na 'coś innego')?
> >
> > specjalne to "jak narazie" glibc i kernel - czy tez jest jeszcze
> > cos rownie wrazliwego
> > (dla specjalnych opcje (o ile w ogole beda) musza trafic do speca
>
> To oprócz 'specjalnych' stwórz kategorię 'inne'. Aha - jak w Twoim
> modelu opcje mają trafić do speca, skoro tam nie przewidujesz miejsca
> na jakiekolwiek opcje? Mnożysz byty.
>
> > > Wszystko to będzie pięknie, dopóki nie okaże się, że na ia32
> > > trzeba optymalizować na rozmiar, a na sparcu na szybkość.
> >
> > ???
> > czy ja jestem tak malo komunikatywny?
>
> Albo jesteś niewyspany, albo ja tak mało komunikatywny.
>
> > ustawiasz opcje per %arch - %__typ_pakietu czyli :na ia32 trzeba
> >
> > > optymalizować na rozmiar, a na sparcu na szybkość.
>
> 		ia32		sparc
> Mozilla		rozmiar		szybkość
> OO		rozmiar		rozmiar
coz..w tym miejscu wracamy do pytania "czy to zachodzi?" czyli do 
jakichkolwiek testow
> To, co na ia32 jest tą samą klasą 'kobyła', na sparcu stanowić może
> różne klasy. Właśnie podwoiłeś liczbę swoich klas.
>
> > > niewiele ryzykując koniecznością przebudowywania wszystkiego. Nie
> > > podoba mi się nieprzyszłościowe podejście, wyżej już jest wątek o
> > > db3, db*, gdbm etc.
> >
> > rzeklbym, ze jesli zapakujesz to wprost w spece to wlasnie to
> > zajdzie, a
>
> Optymalizacje są _dla konkretnego pakietu_, więc wystarczy chłopski
> rozum żeby pojąć, że poza specem dla nich miejsca nie ma.
jezeli dla dowolnych 2 pakietow A i B zachodzi opcje dla A rozne od 
opcje dla B to powyzszy argument jest prawdziwy. (logika formalna)

> > w przypadku ustawienia dania w specu tylko %define __typ_pakietu
> > dodasz w rpmie nowa arch (np C3) razy ilosc_typow_pakietow
>
> Tak, dla różnej klasy-tej samej klasy. Przy okazji znów się namnożą
> byty. Oprócz kobyła_all i kobyła_sparc_only będzie jeszcze
> obliczeniowy_via_only i obliczeniowy_all. Wszystko razy
> *_with_frame_pointer i *_c++_optimization.

o ile zalozenie ze nie da sie wydzielic wspolnych klas jest prawdziwe

> > w innyp przypadku musisz "chodzic" po wszystkich specach.
>
> Ba, musisz chodzić po wszystkich pakietach i je kompilować! Na tym
> polega SOLIDNA optymalizacja, że się ją przeprowadza osobno dla
> każdego krytycznego pakietu (jak krytycznych braknie to będzie można
> się zabrać za niekrytyczne - w ich przypadku wystarczy wybrać tą,
> która daje mniejszy rozmiar) i porównuje rezultaty.
przebudowanie <>modyfikacji speca , a do argumentu SOLIDNA pozniej
> > > - gdzie w powyższym jest rozróżnienie na obecność
> > > -fomit-frame-pointer? Na kodzie c++ z -Os powoduje to
> > > _zwiększenie_ kodu wynikowego, zatem 'kobyły' będziesz musiał
> > > dalej dzielić.
> >
> > tak, zgadza sie dalej musze dzielic - masz racje!
> > dla mnie ilosc typow pakietow < 10 jest nadal zupelnie sensowna,
> > czy dla
>
> Ja już się doliczyłem około 40 typów. Z KAŻDĄ niespodzianką w postaci
> pakietu o odmiennym zachowaniu dojdzie kolejne 5.
> Zresztą, będę się produkował. Zajrzyj do duke3d.spec - jego można
> ładnie zwinąć do:
>
> %define	specflags	'-DPLATFORM_UNIX=1 -funsigned-char'
>
> i już zwiększa się czytelność
>
> > durona stosujesz wiecejkombinacji optymalizacji dajacych stabilne
> > pakiety i _zauwazalne_ roznice?
>
> Dla durona:
> -O2
> -O2 -fomit-frame-pointer
> -O2 -fno-exceptions -fno-rtti
> -O2 -fomit-frame-pointer -fno-exceptions -fno-rtti
> -Os
> -Os -fomit-frame-pointer
> -Os -fno-exceptions -fno-rtti
> -Os -fomit-frame-pointer -fno-exceptions -fno-rtti
>
> 1. obliczeniowe, które nie chcą być 2 i 3.
> 2. obliczeniowe, które nie chcą być 3.
> 3. obliczeniowe, które nie chcą być 2.
> 4. obliczeniowe.
>
> To samo dla -Os - to już 8 typów. Do tego typ 'specjalne' oraz 'inne'
> - mamy już 10. Doliczamy inne optymalizacje, które w poszczególnych
> przypadkach mogą się sprawdzić (-O3, -funroll-loops, -fforce-addr) -
> do 15 dobijamy lekko. Poza tym kobyła z ia32 może być mała dla
> Sparca, czyli i tak muszą być osobne typy na każdy procesor:
> kobyła_4_all, obliczeniowy_2_sparc etc - właśnie wygrałeś nagrodę, w
> ramach minimalizacji liczby bytów stworzyłeś ich 60 w miejsce 5.
eee...naciagasz liczby "pod publike", ale niech tam :)
tyle klas wychodzi jesli klasy dla roznych arch nie sa wspolne (tak jak 
pisales o mozilli i oo). Tyle tylko , ze jest pytanie o ilosc 
wspieranych arch przez pld. Tu przedstawiles "klasy" dla durona - czy 
klasyfikacja tych pakietow nie ulegnie zmianie pomiedzy duronem i 
athlonemXP? czyli czy nie bedzie tak ze:
           duron            athlonXP
pakietA  rozmiar         rozmiar
pakietB  rozmiar         szybkosc
to samo dla celeron/pentium, a jak uwzglednimy 586 to dopiero 
galimatias, a to tylko ia32! Wiec pytanie ile arch pld wspiera?

teraz optymalizacje , ktore podales: "nie chca byc" to klasa 
stabilnosci.
czyli podales dwie klasy optymalizacji Os O2 i cztery klasy stabilnosci
podsumowujac
calosc swojej argumentacji oparles na zalozeniu, ze nie da sie wydzielic 
wspolnych klas dla roznych arch, a ja mam watpliwosci co do 
prawdziwosci tego zalozenia.
moze tak:
wspierane arch AR{A,B,C,D}
warianty danej arch ARW{AW,BW,cW}
klasy pakietow KP{O1,O2,O3,O4}
pakiety P{P1,P2,...,Pn}
istnieje N pakietow P ktore nalezy przypisac do innej klasy KP w 
zaloznosci od tego na jaka arch AR sa budowane bo daje to _znaczaca_ 
roznice wydajnosci
i jednoczesnie powyzsze zdanie nie jest prawdziwe po wstawieniy ARW w 
miejsce AR( bo inaczej trzeba by zwiekszyc ilosc AR)
ta ze zapraszam wszystkich do pomocy w sprawdzeniu , ktora z tez jest 
prawdziwa.