Autor: Maciej W. Rozycki (macro_at_macro.ds2.pg.gda.pl)
Data: Fri 25 Jul 1997 - 23:31:00 MET DST
On 24 Jul 1997, Andrzej Karpinski wrote:
> [wyjasnienia teoretyczne bp]
>
> > Widze, ze powtarzasz bezmyslnie zaslyszane lub wyczytane opinie. Wlasnie
> >mi o to chodzilo, ze BogoMIPS (jak sama nazwa wskazuje -- falszywy) jest
>
> [dalsza czesc...]
>
> Zastanawiam sie, po jakiego czorta wstawiasz takie zdanka do swoich
> listow. Niby z glowa facet ktory wie co mowi, a sam sie prosi zeby
> wyszukiwac bledow w jego postingach i odpowiadac w tym samym tonie. Wierz
> mi, do KAZDEJ wypowiedzi sie mozna przyczepic, jesli wiec mozesz, nie
> badz az tak zaczepny... Powoli zaczyna mi sie nudzic dyskusja w ten
> sposob :) Poza tym jakiez to opinie zaslyszane bezmyslnie powtarzam?
Widzisz, wydawalo mi sie, ze akurat to co pisalem (innymi slowy, ale
chodzi o sens): "wskutek bledow w BTB, Pentium wypada slabo w tescie
BogoMIPS w porownaniu do i486" implikowalo, ze test jest z gruntu
falszywy. Niemniej jednak do tego, do czego zostal zaprojektowany, nadaje
sie swietnie, gdyz wlasnie mierzy rzeczywiste opoznienie generowane przez
petle opozniajaca.
Byc moze tez nazbyt ostro zareagowalem na pomow^H^H^H^H^Hsugestie, ze nie
wiem co pisze, ale (nawet nie majac pojecia o problemach z BTB w Pentium),
powinienes przeczuwac, ze jakas przyczyna takiego zachowania BogoMIPS na
Pentium musi istniec.
Jakie opinie powtarzasz? A mianowicie takie, ze BogoMIPS jest pomiarem z
gruntu falszywym. Jest oczywiscie falszywym benchmarkiem, ale niemniej
jednak pomiarem jest zupelnie dobrym. Tylko oczywiscie nalezy sie
zastanowic co on mierzy (patrz wyzej)...
> > Jezeli nie podoba Ci sie okreslenie "pluskwa", to mozna to nazwac
> >"niedoskonaloscia projektowa". ;->
>
> O.. juz lepiej :> Starajmy sie pisac nie az tak ostro nazywajac rzeczy po
> imieniu, bo ostatnio mamy (wszyscy, ja tez) tendencje do
> przekoloryzowywania...
Niektore eufemizmy bywaja rowniez denerwujace...
W kazdym razie, o ile blad z przewidywaniem skokow w "ciasnych" petlach
mozna uznac za przypadkowa wpadke (malo istotna, w rzeczy samej), to
niestety problem z tranzycja ze stanu "0" do "1" zasluguje na miano dosc
powaznego bledu (zwlaszcza, ze nie zostalo to przez Intela odpowiednio
udokumentowane). A wystarczyloby, aby oznaczac nieprzydzielone elementy
BTB jako "3" (przy okazji zniknalby tez drugi problem)...
Jest to niestety rowniez kwestia polityki firmy. Przypomina sie tez
(moze dosc malo znany) blad w postaci zasmiecania stosu w sytuacji, gdy
wartosc DPL furtki przerwania rozna od "0" w trybie V86, powoduje wyjatek
#GP. Firma Intel stwierdzila, ze "w poprawnych programach taka sytuacja
nie wystepuje i w zwiazku z tym nie przewidujemy poprawienia bledu".
Teraz powiedz mi co to znaczy "poprawny program" (dla ulatwienia mozesz
wczesniej zajrzec do zrodla zalecanej przez Intela, a uzywajacej
zarezerwowanych bitow rejestru EFLAGS, procedury identyfikacji procesora).
;-)
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro_at_ds2.pg.gda.pl, PGP key available +
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:14:53 MET DST