Autor: Jaroslaw Lis (lis_at_ict.pwr.wroc.pl)
Data: Thu 03 Apr 1997 - 00:01:18 MET DST
On 1 Apr 1997 23:01:17 +0200, KARPIO_at_golem.umcs.lublin.pl (Andrzej
Karpinski) wrote:
>SIMD - jest to nowa technologia, polegajaca na tym, ze pojedyncza
>instrukcja moze dotyczyc wiecej niz jednego slowa/rejestru.
Nowa to ona jest dla Pentium wypadaloby dodac. Bo na swiecie stosowana
od lat 20 lub wiecej...
>"dana" jest to pelne 64 bity informacji, chociazby o obrazie (czyli np.
>4ry pixelki z 16-bitowa glebia koloru). zaladowanie tych danych do
>rejestru (8miu pizxeli obrazu z 16 bit kolorem) zajelo 2 takty!
To pwenietyle samo co na Alph'ie. Dwa slowa po 64 bit :-).
>i teraz (!) - XORujemy przez siebie te dwa rejestry, co zajmuje (!) dwa
>takty. wynik dostajemy np. w trzecim rejestrze. co to daje? ano mamy
>przenikniecie sie 16-bitowych obrazow, wykonane dla 8 pixli dwoch
>roznych obrazkow, ktore zajelo nam... 4 takty!
Na prostym XORze to mamy misz-masz na ekranie. Ale trzeba przyznac ze
mozna robic i bardziej zaawansowane operacje na ekranie.
>Te kilkadzieisat zaledwie instrukcji to wlasnie operacje mnozenia,
>dodawania, przesuwania bitow, porownywania sporych ilosci danych (64bity
>i wiecej) pojedynczymi, krotkimi instrukcjami. Nie wiem skad rewelacje o
>braku testowania bitow, ktore juz posiadal starenki 4004 ;)
No - rozkazu typu 'sprawdz n-ty bit w rejestrze', gdzie n jest zawarte
w innym rejestrze, to w x86 faktycznie nie znajdziesz.
>>Nie. Pudlo! SunSparc 4, po swietach bedzie Ultra. Prywatnie badziewne
>>pentium (jak sie nie ma co sie lubi, to sie lubi co sie nie ma... )
>Dla ulatwienia dodam, ze PentiumPro i dowolny U*X da ci wieksze
>mozliwosci niz Spark w twoim Sunku 4 ;) Oczywiscie chyle czolo przed
>UltraSparkiem, aczkolwiek podejrzewam, ze Intel nie zasypuje gruszek w
>popiele, zas wyniki testow nie potwierdzja jakiejs miazdzacej (powiedzmy
>3-krotnej) przewagi Sparka nad Prosiakiem...
Ale dopiero Pro. A on nie ma MMX :-(.
>Nie, koprocesor (MMX) i CPU moga i nawet powinny pracowac jednoczesnie.
>Problem jedynie w takim napisaniu programu, aby nie wychodzily z tego
>glupoty z jednej strony, a z drugiej by CPU nie czekal bezczynnie na dane
>z koprocesora. Najogolniej programista (wylaczajac systemowca ktory
>siedzi nad krytycznym 15kb kernela) nie musi nawet wiedziec jak to
>zorganizowac, bo robi to za niego kompilator. Nie wyobrazam sobie pisania
>czegokolwiek w asemblerze przy dzisiejszym skomplikowaniu programow (nad
>czym nota bene ubolewam).
A wybrazasz sobie kod zrodlowy ktory bedzie mogl byc skompilowany do
instrukcji MMX? Bez zdolnego assemblerowca ktory przygotuje biblioteki
to sie tu nie obejdzie.
> Piszesz o wielkich kosztach Intela
>(CISC) wynikajacych z historii i ograniczen, a chwile dalej piszesz, ze
>Cie nie stac na alternatywe i musisz miec Intela... Przeczysz wiec sam
>sobie. Jesli RISC bylby tanszy, to kto kupowalby przestarzalego Intela?
Alez RISC'i sa tansze [mniejszy chip, prostszy projekt].
Tylko zeby to mialo odzwierciedlenie w $, to trzeba jeszcze miec
podobna ilosc sprzedanych kosci, a klienci ... chca komputer
kompatybilny ze starym softare.
J.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:00:56 MET DST