Autor: Arkadiusz Dabrowski (dobrov_at_friko.onet.pl)
Data: Fri 18 Jul 1997 - 16:12:41 MET DST
On 17 Jul 1997 17:43:45 +0200, karpio_at_fenix.xyz.lublin.pl (Andrzej
Karpinski) wrote:
>> >>Oczywiscie nikt nie smie watpic, ze wszyscy uzywaja windoze, dll-e i beda
>> >>pokornie stosowac sie do zalecen naszego kochanego dobroczyncy.
>
>> >binutils.2.8.1.xx oraz czesc bibliotek linuxowych oczywiscie mozna sobie
>> >sciagnac w wersjach mmx optimized, ale tego kolega juz nie zauwaza, bo
>
>Nie odpowiedziales.. Nie tylko na to zreszta.. Przykre, ze tak sie
>zachowujesz natrafiajac na rzeczowe odparcie Twoich zlosliwostek.
>
No dobra, odpowiem. Napisales cos o ladowaniu odpowiedniego dll-a, a to
nieodlacznie kojazy mi sie z windoza. Natomiast jestem przekonany, ze
wkrotce programisci oleja dual-code (czy jak sie to tam nazywa) i wszystkie
stare pentiumy pojda na smietnik ku uciesze intela.
>[dotyczy pmaddw]
>
>> Mnozy 4 16-bitowe pary, a potem dodaje po 2 64-bitowe wyniki.
>> Ile trwa taktow - nie wiem. Intel nie raczyl zamiescic tej jakze malo waznej
>> informacji w pdf-ie, ktorego sciagnalem.
>> Przyjmuje na wiare, ze trwa krocej niz bez MMX'a.
>> Ale jak czesto mi sie to przyda ? Raz na 1e4 instrukcji ?
>
>1. Ile trwa to skomplikowane zadanie. Od momentu pobrania instrukcji przez
>procesor do momentu zakonczenia wykonywania 3 takty. Z tym, ze jest to
>przetwarzane w potoku, dlatego w czasie tych 3ch taktow procesor moze
>zajmowac sie jeszcze 3ma innymi instrukcjami. Dlatego biorac pod uwage
>efektywnosc potoku jest to 1 takt. Biorac pod uwage, ze PentiumMMX ma dwa
>potoki, wychodzi 0.5 takta na instrukcje, bo procesor potrafi wykonac w
>szczegolnym przypadku (gdy dane nie operuja na tych samych rejestrach) 2
>takie instrukcje na kazdy takt. W chwili obecnej nie mozna po prostu podac
>czasu wykonania instrukcji, bo prawidlowa odpowiedzia na pytanie ile cos
>trwa jest jedynie "to zalezy".
>
Ja wiem, ze zalezy od tego, czy sie da rownolegle, czy nie. Ja chce wiedziec
ile to trwa taktow w jednym potoku. A chce wiedziec dlatego, ze predzej, czy
pozniej bede musial oprogramowac ten wybryk (w koncu kilka procent
przyspieszenia tez sie liczy).
Jesli posiadasz taki doc, to bylbym wdzieczny za udostepnienie.
>2. Zapoznaj sie dokladnie z lista rozkazow MMX - 60% rozkazow wykonuje
>instrukcje typu pmaddw, ktore wczesniej musiales wykonywac na:
>
>a) wielu instrukcjach
>b) kawalkach rejestrow
>
>co zabieralo wiecej czasu. Nad taka akurat lista rozkazow pracowali ludzie
>znacznie lepsi w temacie niz ja czy nawet Ty, i wierz mi, sa tak
>pomyslane, by jednak przydawaly sie w obrobce chociazby dzwieku czy
>grafiki. Takie rozkazy istotnie wystepuja srednio w mniej niz 1% kodu, za
>to ten kod wykonuje dosc wazne operacje - obsluge grafiki, wyswietlania i
>inne rzeczy. Jest wiec stosowany w najbardziej czasochlonnych operacjach,
>ktore ma przyspieszac, do czego wlasnie sluzy. Mam nadzieje, ze uwierzysz
>mi na wiare, ze istnieje wiecej instrukcji SIMD (wlasnie na tym to polega
>- pobierasz raz instrukcje, ktora wykonuje wiele dzialan (pare mnozen,
>dodawanie, etc - jednoczesnie) na duzych co by nie mowic jak na tej klasy
>procesory, strukturach danych) tego typu oraz ze istotnie w zastosowaniach
>do ktorych byly pomyslane daja istotne przyspieszenie. Nie wiem czy
>powinienem sie powolywac na IMB i przytaczac wyniki testow dla procesorow
>MMX i noMMX dla roznych operacji na kodzie MMX-optimized. Niestety widac
>roznice.
>
>> W nowej wersji proponuje dolozenie nastepujacego przydatnego rozkazu:
>> a0=sin(b0+cos(c0*ln(pi^d0)))
>> a1=sin(b1+cos(c1*ln(pi^d1)))
>> a2=sin(b2+cos(c2*ln(pi^d2)))
>> a3=sin(b3+cos(c3*ln(pi^d3)))
>
>Jesli uzasadnisz istnienie takiej instrukcji to Intel pewnie ja wprowadzi.
>Jesli sie okaze, ze dzieki jej istnieniu mozna przyspieszyc nie wiem..
>ogolnie: przetwarzanie 3D bo akurat wykonuje sie srednio 15 takich
>operacji na kazdy liczony pixel, zas wykonywane osobno zajmuja 200 taktow,
>to moze sie ona okazac potrzebna! Wszystko przed Toba! :>
>
>> Czy nie lepiej zamiast dokladac milion nowych tranzystorow na MMX'a postarac
>> sie, by normalne rozkazy wykonywaly sie szybciej ? np. mul/div w jednym
>> takcie ? To sa akurat POTRZEBNE instrukcje.
>
>Nie! Bo aby uzyskac takie przyspieszenie potrzeba zbyt duzych nakladow,
>zas szlifujac MHz juz wlasciwie doszlismy do granicy mozliwosci obecnej
>technologii.
Mowilem o jednym takcie, a nie o szlifowaniu.
Nie dajmy sie zwariowac - myslac w ten sposob nalezaloby
>zapytac, dlaczego na biurkach nie stoja 8086 taktowane zegarem 50GHz -
>teoretycznie da sie ja chyba nawet teraz wykonac, a wydajnoscia
>dorownywalyby PentiumII :>
Oj bez przesady prosze. 8086 5GHz byloby pewnie szybsze niz PII.
>Przyspieszanie
>procesorow to nie tylko MHz. To takze usprawnienia samej struktury
>ukladow, rozszerzanie listy rozkakow itp. Zas w przypadku x86 Intel nie
>moze sie zdecydowac na odejscie od zgodnosci binarnej, ktora wymusza
>akurat tego typu protetyke. Btw. DIV jest zlym przykladem, bo wszystkie (w
>sensie: kazde) procesory maja z tym problemy i jest to naprawde
>skomplikowane.
Nie twierdze, ze nie jest to skomplikowane, ale wlasnie w generacji grafiki
3d div jest to BARDZO waznym rozkazem. Nie stosujac sztuczek nalezaloby
wykonywac go programie takim jak Quake conajmniej 2 razy na piksel, czego
oczywiscie sie nie robi.
Mysle wiec, ze warto powalczyc z divem (oczywiscie raczej z idivem). Na
milionie tranzystorow, przeciez mozna nawet cos stablicowac.
I mozna byloby to nazwac extension, zamiast multimedia extension.
Prawda, ze bardziej uniwersalne ?
>
>> A dlaczego to klepanie coraz wiecej MHz jest gorsze od MMX'a ?
>> Przeciez liczy sie tylko realna szybkosc procesora, a nie szpan, ze ma
>> zajebiste rozkazy. Jak mam wybierac, biorac pod uwage realia - o co tak
>> bardzo raczysz apelowac - to wybieram wiecej MHz, bo nie musze sie uczyc
>> nowych rozkazow i nie musze kupowac nowego kompilatora.
>
>A dlaczego zamiast klepac 50GHz 8086 producenci robia procesory DSP i inne
>wynalazki? Przeciez to byloby tak samo wydajne. Ba! Moznaby robic nawet
>4004/500GHz!! To dopiero bylaby rakieta! :>
>
>> Ludzie juz dawno wymyslili risc i vliw. Moze na razie zastosujmy to, co
>> znane i dobre, a w nastepnym kroku wymyslajmy nowe.
>
>Piszac "ludzie" masz na mysli "w 80% Intel" - bo niestety czysto
>statystycznie 80% nowych technologii jesli chodzi o procesory wychodzi
>wlasnie od Intela.
I tu masz jasny dowod, ze ja nie nienawidze inzynierow z intela.
Ja nienawidze ich managerow.
>Po prostu Intel wydaje najwiecej kasy (ponad rzad
>wielkosci wiecej niz nastepny w kolejce konkurent) na badania, nie tylko
>nad MMX czy nowymi P9, ale takze na badania ogolne - nowe techniki
>przetwarzania danych, nowe technologie wytwarzania ukladow itd itd.
Nie chodzi o to, by wydawac najwiecej. Chodzi o to, by wydawac madrze.
>Nie zaprzeczysz, ze uklad scalony wynalazl Intel.
>Nie zaprzeczysz, ze mikroprocesor to takze jego pomysl...
Nie zaprzecze, ale rozpamietywanie dawnych zaslug nie ma sensu.
Kiedys pewien Polak, wielce zasluzony w walce z komunizmem, w nagrode zostal
prezydentem. Ach jakie to byly nieciekawe czasy.
>AMD, Cyrix i inni robia swoje uklady
>korzystajac z technologii i doswiadczen Intela.
Zaprzecze. Technologie maja swoja, niejednokrotnie lepsza. Dostosowuja sie
tylko do chorej specyfikacji, aby nie wyleciec z rynku.
>Tych firm nie stac, na
>opracowanie wlasnych metod przetwarzania danych. Sam zreszta nsapisales
>bardzo slusznie, ze produkowanie procesorow wymaga ciezkich pieniedzy. Ich
>projektowanie to jeszcze wiekszy wysilek. Zas na prace nad nowymi
>technologiami i metodami stac tylko kilka najbogatszych firm. I tu akurat
>nie powienies chyba narzekac na Intela. Ja sie ciesze, ze jest AMD, Cyrix
>i wiele innych firm - ceny dzieki temu spadaja. Ale to jeszcze nie powod,
>bym gnoil Intela. W czasach 386 i 486 kupowalem praktycznie tylko AMD. Po
>prostu byly lepsze. K5 okazalo sie niewypalem.. K6 w praktyce takze
>absolutnie nie stanowi konkurenta dla intelowskiej konstrukcji P6.
>Poczekam wiec, az AMD znow sobie przypomni, jak sie produkuje porzadne
>procesory... Chetnie je kupie, jesli istotnie beda lepsze. Jestem
>fanatykiem, ktory chetnie wyda ciezkie pieniadze, pod warunkiem, ze
>dostanie faktycznie lepszy pod kazdym wzgledem produkt. A jest mi
>dokladnie wszystko jedno czy bedzie na nim napis Intel, MIPS, AMD czy tez
>moze FSO Polonez...
>
>> Jaka powinna byc IMHO mniej-wiecej architektura procesora, to juz pisalem w
>> tym subjeccie. Widac uszlo twojej uwadze.
>
>Nie uszlo. A napiszesz jeszcze do tego 123123GB software? A wymienisz
>darmowo procesory ilustamset milionom uzytkownikow ktorzy obecnie
>korzystaja z x86? Jesli to zrobisz, to masz szanse, ze Twoj produkt
>przyjmnie sie na rynku. Acha - jeszcze musi tylko byc w porownywalnej
>cenie jak x86 :>
>
Wlasnie o to chodzi, ze procesor RISC bedac szybszym, moze miec mniej
tranzystorow niz pentium i byc do tego tanszy.
A programy starzeja sie szybko. Szybciej niz samochody. A nikt nie wymienia
starych gratow na nowe za darmo.
Poza tym swiat jest wielki. Mysle, ze mogly by sie utrzymywac na rynku
conajmniej dwie konkurencyjne architektury. Tak byloby zdrowiej.
>
>> Karpio, nie wiesz o czym piszesz.
>> A oto argumentacja analogiczna do twojej: [ ]
>
>Podoba mi sie to. Dziekuje. Cieszy mnie, ze wszystkie Twoje listy
>utrzymane sa w podobnym tonie :>
Oj przesadzasz okrutnie.
Po primo:
Po raz pierwszy tak bezposrednio zarzucilem ci niewiedze i to wetem za wet.
Po drugie primo:
To milo, ze wyciales kilka wyzszych linijek, ktore zupelnie zmieniaja sens
tego co zacytowales. Ale oczywiscie moze ktos postronny nie zauwazy i to ja
wyjde na hama.
>
>> Ja mam swiadomosc, ze jestem skazany na MMX'a i ze jest on trochu lepsiejszy
>> od nieememixa. Ale nie przeszkada mi to twierdzic iz nie jest to dobry
>
>O... I tylko o to chodzilo - przyznales wlasnie racje, ze jednak istnieje
>sens istnienia ( :>> ) MMXa i ze istotnie jest on lepszy od nieMMXa.
Najwiekszy ma to sens dla pracownikow intela - niestety. Tak to jest jak
niema pozadnej konkurencji.
>I o to w calej dyskusji chodzilo. A teraz poczekajmy miesiac az procki
>stanieja i kupmy je sobie, cieszac sie kolejnym 30% przyspieszeniem
>odtwarzania AVIkow, mozliwoscia korzystania z wydajniejszych narzedzi itd.
>Nie oczekuje niczego wiecej :>
>
A ja oczekuje. Ja jestem swiadomym uzytkownikiem i wiem czego chce. Szybkosc
procesorow produkowanych przez intela nie odpowiada poziomowi wspolczesnej
techniki i to mnie boli. I nie obchodzi mnie, ze intel nie moze bo...
Takie sa prawa rynku. Klient placi, klient wymaga. A ze jestem wymagajacy,
bo wiem na ten temat nieco wiecej niz baba, ktora idzie do sklepu i chce
tego, co rozbawia komputer i zeby jeszcze, te no wyndowsy byly....
No coz moze to moja ulomnosc.
I jeszcze uwaga:
>>A co do tego, ze
>>>Heh... cie zawsze uczono, ze aby cos krytykowac, trzeba zaproponowac
>>>jakies rozwiazanie alternatywne. Powiedziec, ze cos jest do dupy to zaden
>>>problem. Gorzej jak samemu trzeba cos wymyslic.
>>Po primo:
>>---------
>>Mam nadzieje Andrzeju, ze zgodnie z tym czego cie uczono nigdy nie narzekasz na:
>>Gowniany film, ktory niedawno obejrzales,
>>Jakosc polskich samochodow, gdy ci sie takowy rozkraczy,
>>Jakosc windozy, gdy ci sie zawiesi,
>>Jakosc polskich drog, gdy zgubisz kolo,
>>Jakosc Cyrixa 686, ktory ponoc niektorym sie wiesza,
>>Jakosc mailera, gdy wysylasz na liste tylko cytat bez komentarza ;>
>>Disco polo, ktorym zadrecza nas polsat....
>>Dlugo by jeszcze wymieniac.
>>Chyba, ze na kazda z bolaczek masz wlasny sprawdzony patent.
>Nie odpowiedziales.. Nie tylko na to zreszta.. Przykre, ze tak sie
>zachowujesz natrafiajac na rzeczowe odparcie Twoich zlosliwostek.
^ to jest swiadomy cytat
P.S.
Wiesz cos wiecej o tym P9 ? A czemu nie P7 ? Moze tak jak z wordem u
mecrosofta - chodzilo o to, by nie miec "gorszej" wersji niz WordPerfect.
Ale abstrachujac, to mam jeszcze mala nadzieje, ze bedzie to istotny postep.
Chociaz pewnie znowu twarde zycie da kopa mojej naiwnosci. Historia lubi sie
powtarzac.
+--\ /--\ +--\ +--\ /--\ | | Arkadiusz Dabrowski
| | | | |--< |--/ | | | | dobrov_at_priv.onet.pl
+--/ \--/ +--/ | \ \--/ \/ stare konto:
dobrov_at_zeus.polsl.gliwice.pl
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:14:16 MET DST