-Os

[Robert Kurtys]

On Thursday 01 May 2003 12:19, Tomasz Pala wrote:
> On Thu, May 01, 2003 at 11:55:24 +0200, Robert Kurtys wrote:
> > > 		ia32		sparc
> > > Mozilla		rozmiar		szybkość
> > > OO		rozmiar		rozmiar
> >
> > coz..w tym miejscu wracamy do pytania "czy to zachodzi?" czyli do
> > jakichkolwiek testow
>
> Żadne testy nie zagwarantują, że coś takiego nie zajdzie za rok.
> Prawidłowe założenia konstrukcyjne zawierają w sobie umożliwienie na
> ile to możliwe przyszłej rozbudowy i unikanie problemów natury
> wszelkiej niekompatybilności.
jakiej niekompatybilnosci??? - dyskusja idzie o optymalizacje wiec w 
_najgorszym_ przypadku stracisz kilka % wydajnosci _danego_ pakietu, 
czyli uzywasz "argumentow" typu strach...etc
> > > ramach minimalizacji liczby bytów stworzyłeś ich 60 w miejsce 5.
> >
> > eee...naciagasz liczby "pod publike", ale niech tam :)
>
> Nawet 10 klas to dwa razy więcej niż 5 opcji.
oo no tu to juz jawne przeklamanie z Twojej strony :
5 opcji * N specow = A
10 opcji rpm +1 define_w_specu *N specow =B
zrob se wykres i badz powazny i uczciwy w argumentacji.
> > 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
>
> JEŚLI tak będzie w _konkretnym_ przypadku to optymalizacja nie trafi
> do speca. Osobiście w to wątpię.
glownym Twoim argumentem jest rozmiar cache, a on jest dosc zmienny, 
tak, ze mozesz miec osobiste watpliwosci. ja tez je mam dlatego _przed_ 
wprowadzenie takiego lub innego rozwiazania trzeba miec wiedze (testy), 
a nie zalozenia, ot i tyle.
> > to samo dla celeron/pentium, a jak uwzglednimy 586 to dopiero
> > galimatias, a to tylko ia32! Wiec pytanie ile arch pld wspiera?
>
> W obrębie wszystkich maszyn objętych arch 586 nie ma takich różnic,
> jak między P60 a Sparcami, o których pisał kloczek.
>
> > 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.
>
> Udowodnij więc, że nie będzie prawdziwe w przyszłości. Bo nawet
> obecnie różnice między 486SX (i386) a Alphą są powalające, stary
> procesor 486 się już nie zmieni, nowe pojawiają się co kilka
> miesięcy.
Przeprowadziles caly swoj wywod w oparciu o jedno zalozenie, mocno 
watpliwe, kiedy to wskazalem reagujesz: to dowiedz ze moje zalozenie 
jest bledne, ba nawet nie jest ale nie 
_moze_byc_prawdizwe_w_przyszlosci_.
Przypomne, ze idzie o optymalizacje, czyli zwiekszenie 
szybkosci/zmniejszenie rozmiaru; nawet nie_optymalizowane pakiety 
dzialaja.
Rozwoj oprogramowania od poczatku w znacznej mierze sprowadza sie do 
wydzielania coraz wyzszych klas abstrakcji, chcby wiazalo sie to z 
nieznaczna strata wydajnosci (obecnie racze rzadko programuje sie w 
asemblerze duze rzeczy ;))
> > ta ze zapraszam wszystkich do pomocy w sprawdzeniu , ktora z tez
> > jest prawdziwa.
>
> Prawdziwe jest to, że różnica pomiędzy procesorami nowymi a
> najstarszymi przez PLD wspieranymi na pewno nie będzie się
> zmniejszała, wręcz przeciwnie.
i wlasnie dlatego programy sa pisane w jezykach wyzszego rzedu (np c), a 
nie w asemblerze, zeby moc latwo migrowac na inne platformy i tu nalezy 
myslec podobnie.
btw jak widac z poprzednich maili przedstawiles tylko 2 optymalizacje na 
rozmiar i szybkosc + 4 pozimy stabilnosci do kazdej, czy moze cos 
pominalem?