-Os

Robert Kurtys bob w pozyton.net.pl
Śro, 30 Kwi 2003, 23:51:34 CEST


On Wednesday 30 April 2003 15:25, Tomasz Pala wrote:
> On Sat, Apr 26, 2003 at 12:06:39 +0200, Robert Kurtys wrote:
> > z przebiegu dyskusji wynika ze w zaleznosci od arch nalezy stosowac
> > rozne opcje optymalizacji
>
> Raczej nie wynika, a jest takie podejrzenie - jak dotąd
> niepotwierdzone.
OK
> > do tego dochodzi specyfika danego programu : czy ma on byc
> > optymalizowany na szybkosc, wielkosc, cos innego
> > dlatego IMHO w specu powinno byc %define __typ_pakietu
> > gdzie typ pakietu to:kobyla;numeryczne;?????;specjalny
>
> 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

> > (wyglada na to ze tych typow optymalizacji nie bedzie tak duzo)
> > a w samym rpmie bylyby zdefiniowane opcje optymalizacji per %arch -
> > %__typ_pakietu
>
> 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?
ustawiasz opcje per %arch - %__typ_pakietu czyli :na ia32 trzeba
> optymalizować na rozmiar, a na sparcu na szybkość.

> > zyski:
> > -w specu dodajemy tylko 1 linijke (co ulatwia konserwacje)
> > - dla nowych specow latwo wprowadzamy optymalizacje (kwalifikacja
> > do grupy)
> > - w przypadku jakis zmian unikamy mass_commitow
> > -no i czysto estetycznie calosc ladniej wyglada
>
> Wady:
> - to, co wspomniałem wyżej - jeśli w praniu moje obawy okażą się
>   słuszne, albo za pół roku pojawi się nowy procesor, który będzie
>   chodził inaczej, czy w gcc pojawią się optymalizacje dla Via C3,
> czy cokolwiek w ten deseń - będą problemy. Krótko mówiąc: zyskujemy
> 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 
w przypadku ustawienia dania w specu tylko %define __typ_pakietu dodasz 
w rpmie nowa arch (np C3) razy ilosc_typow_pakietow
w innyp przypadku musisz "chodzic" po wszystkich specach.
> - 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 
durona stosujesz wiecejkombinacji optymalizacji dajacych stabilne 
pakiety i _zauwazalne_ roznice?



Więcej informacji o liście dyskusyjnej pld-devel-pl