Re: po co MMX?

Autor: Maciej W. Rozycki (macro_at_macro.ds2.pg.gda.pl)
Data: Thu 24 Jul 1997 - 10:10:54 MET DST


On Thu, 24 Jul 1997, Andrzej Karpinski wrote:

> > Kilka do kilkunastu procent. Wynika to z powiekszonej pamieci
> > podrecznej, usunietej pluskwy w przewidywaniu skokow (BTB) i ulepszonego
> > mechanizmu parowania rozkazow. Nota bene, to wlasnie wskutek pluskwy w
> > obsludze BTB linuxowy wskaznik "bogomips" dla Pentium wypada tak slabo w
> > stosunku do i486.
>
> Pluskwa w Branch Prediction Unit w Pentiumie? Nowosc jakas jak mniemam :>

 Starosc, niestety. ;-( Po prostu (jak Ci zapewne wiadomo) BTB w
Pentium-nie-MMX ma dla kazdego elementu dwa bity stanu kodujace akcje
zwiazana ze skojarzonym z tym elementem skokiem:

0 - "strongly not taken",
1 - "weakly not taken",
2 - "weakly taken",
3 - "strongly taken".

zmniejszany o jeden w przeciwnym wypadku. Niestety nie zawsze. Przejscie
ze stanu "0" do "1" jest (prawie) niemozliwe. "0" oznacza rowniez
nieprzydzielony element. Inzynierowie zalozyli, ze nowo alokowane
elementy inicjowane sa w stan "3". Ta asymetria powoduje, ze instrukcje
skokow, ktore sa zwykle nie podejmowane, sa do trzech razy gorzej
przewidywane od tych, ktore zwykle koncza sie skokiem. Jest to w
sprzecznosci z przykladami optymalizacji podawanymi przez Intela.

 Jest jeszcze drugi problem, o ktorym nizej.

> Po prostu BTB w P5 jest stosunkowo stabiutkie (skutecznosc ~80%, w 16-bit
> odrobinke wiecej), zas P55C ma po prostu dokladne BTB z ukladu P6 (ta
> jednostka ma dosc duzy wplyw na wydajnosc, a nie jest AZ TAK skomplikowana
> i tranzystorozerna wiec mozna ja po prostu przekopiowac z nowszego ukladu
> zapewniajac tym samym wzrost wydajnosci). Tak wiec raczej nie pluskwa a
> przestarzala konstrukcja (w sumie P5 zostalo wypuszczone w 1992 roku!,
> prace nad projektem rozpoczeto w 1988... 10 lat temu).

 Konstrukcja przestarzala czy nie, ale niestety rowniez schrzaniona...
Jezeli powyzsze Cie nie przekonalo, to spojrz nizej...

> BogoMIPS natomiast wypada tak jak wypada i jest to wyjasnione w stosownym
> FAQ jak to nalezy rozumiec. BogoMIPS nie jest jednostka przeliczalna
> miedzy roznymi procesorami w sposob liniowy - sa stosowne przeliczniki.
> Nie swiadczy tez wprost o sile procesora, czyli uklad majacy 300 BM moze
> byc tak naprawde spoooro wolniejszy od innego ktory ma tylko 200... to
> dosc zawodna metoda testowania wydajnosci procesora - raczej orientacyjna
> w ramach takich samych grup procesorow.
> P55C200MHz ma troche ponad 200BogoMIPS, a P6200MHz tylko 197 z ogonkiem.
> Czy to oznacza, ze P-MMX jest wydajniejszy pod Linuxem od PentiumPro? :>
> Ach... Cudowny K6/200 pokazuje 330 BM (zakladajac ze sie kernel
> rozkompresuje co nie wychodzi w 30% przypadkow), aczkolwiek np. czasy
> kompilacji kernela jasno pokazuja potege PentiumPro... Roznica jest
> niestety dwukrotna.

 Widze, ze powtarzasz bezmyslnie zaslyszane lub wyczytane opinie. Wlasnie
mi o to chodzilo, ze BogoMIPS (jak sama nazwa wskazuje -- falszywy) jest
liczony przez pomiar czasu wykonania mniej wiecej takiego kodu:

        mov eax,const
lp: dec eax
        jnz lp

Otoz, wskutek niedoskonalosci przewidywania skokow w Pentium-nie-MMX, skok
w powyzszej petelce jest zawsze zle przewidywany, co powoduje wymiecenie
kolejki rozkazow. Jest to oczywiscie wynikiem (!) sparowania obu rozkazow
w petli. Skutek: petelka wykonuje sie szybciej na i486 niz na Pentium,
liczac w taktach zegara (jak nie wierzysz, to sprawdz sobie przy pomocy
rejestrow PMC). Najprostszym sposobem optymalizacji jest oczywiscie
wstawienie 'nop' pomiedzy dekrementacje i skok.

 Jezeli nie podoba Ci sie okreslenie "pluskwa", to mozna to nazwac
"niedoskonaloscia projektowa". ;->

 Jesli chodzi o parowanie, to mam nadzieje, ze nie masz watpliwosci (hint:
"instruction cache end bits").

 Pozdrawiam.

--
+  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:42 MET DST