Yeah! Mad Dog McCree

I nieodżałowany Krzysztof Kubeczko w TS o którym zawsze wspominam (mimo przynależności do przeciwnych obozów) przy takich okazjach... R.I.P

Dajcie sobie spokój z tymi buńczucznymi żądaniami porzucenia 'zatęchłej' architektury x86 na rzecz RISC. Szkopuł w tym, że już od wielu lat jądra wszystkich procesorów x86 działają na zasadzie RISC. Cała 'dobuddowa' CISC to tylko dekoder rozkazów, który zajmuje jedynie maksymalnie kilka % powierzchni czipu i generalnie ma znikomy wpływ na wydajność.

Też miałem swego czasu K6 II, konkretnie 500MHz, to był upgarde z P233MMX, do tego dokupione było więcej RAMu, wymieniony dysk i Inno3D Riva TNT16MB którą ostatecznie wymieniłem ze znajomym na 3dfx Voodoo Banshee 16MB, produkcji Ensoniq zdaje się. Banshee o ile niezbyt udany i wolniejszy to był mocno polecany do zestawów na K6 II, TNT potrzebowały mocnego proca, a jak gra nie korzystała z 3DNow to na K6 pograć się zazwyczaj już nie dało w bardziej wymagające gierki. Właściwie gry to była jedyna słabość tych proców, z całą resztą zastosowań radziły sobie dobrze, choć w sumie wspominam zestaw na K6 pozytywnie głównie ze względu na genialne gry z tamtego okresu jak Thief II...

Samo 3Dnow (a raczej to, co zostaje po 3Dnow po odjęciu instrukcji SEEx) faktycznie jest pomijalne, jeśli chodzi o komplikację krzemu i dekodera. Jednak całość instrukcji SEEx to już inna, wcale nie taka prosta bajka.

No wiesz. Optymalizacje ogólnie stosowanych algorytmów już załatwiają kompilatory.
Oczywiście autorskie rozwiązania to co innego. Ale wstawki assemblerowe to żaden wstyd. Do dziś chyba ludzie z firmy Esset chwalą się że rdzeń ich skanera NOD32 był lub nadal jest pisany w asemblerze. I rzeczywiście, to widać że mniej obciąża procesor od innych antywirusów. Ale jak sam zauważyłeś 'Chyba, że byłoby przeprowadzone bezbłędnie i przy całkowitej i 100% współpracy wszystkich zainteresowanych, jak również nie mogłyby się pojawić żadne 'choroby wieku niemowlęcego'. A ewolucja w tą stronę to jest jakieś 15-20 lat'. Zauważ że kobyłę CISC na RISC JUŻ sprzętowo się emuluje! Architektura obecnych CISC to tak naprawdę transkodowanie instrukcji do fizycznego RISC. Więc tutaj na tym polu emulowania CISC na fizycznym RISC, nie obawiałbym się ani braku wydajności ani braku kompatybilności czy jakis innych ceregieli.
Jak dla mnie to jest do zrobienia bez wielkich katastrof.

Późno już.
Dobranoc.

Ja wiem, że procesory dekodują z CISC na RISC. Problem jest taki, że z tego co się orientuje, a wbrew temu co pisał wyżej aszu pochłania to dość dużo zasobów procesora.

Śpij słodko

Nie ma nigdzie żadnych informacji że tam siedzi RISC! AMD owszem K5 oparło o RISC AMD29k, a K6 to całkiem inna bajka (patenty od nexgena - też risc). VLIW transkodujący x86 to transmeta. I o ile późniejsze procesory wiele z tych patentów wykoprzystują, to pisanie iż tam siedzi RISC emulujący CISC to lekkie nadużycie.

Gościu pomyśl co piszesz, odkopałeś kompa z roku 2000-2001, a nie z '98.

wspomnienia jakby cała branża IT upadła....a to tylko głupie 3dnow którego i tak nikt nie używał

'Nawet zepsuty zegar dwa razy na dobe pokazuje dobra godzine'.

Ja zaczynałem od Atari 65xe z magnetofonem. Gry wczytywało się z kaset - trzeba było wyjść z pokoju , bo najmniejsze wibracje powodowały błąd wczytywania i wczytywanie od nowa (ok. 0,5 h w plecy, choć były gry co się wczytywały ponad godzinę). Do tego często trzeba było regulować głowice śrubokrętem pod odp. gry żeby móc wczytać. Wtedy to były gierki: River raid, The goonies, Draconus, Zybex itd.

Nie zgodzę się z tym że dekoder instrukcji ma znikomy wpływ na wydajność, na pewno ma wpływ na zużycie energii.
RISC vs. CISC in the mobile era, Instruction fetch and decode
Jeżeli jest tak jak piszesz, to dlaczego instrukcje AES NI umożliwiają wielokrotnie szybsze kodowanie AES niż w przypadku zapisania tego samego algorytmu w kodzie x86 bez tych instrukcji? Odp.: bo cały algorytm został przeniesiony do mikrokodu procesora, co pozwala ominąć nieefektywny proces dekodowania i tłumaczenia instrukcji CISC na mikrokod.

Warto zauważyć że w 2001 roku Intel kupił od Compaq prawa do 64-bitowego RISC-owego procesora DEC Alpha, aby nie konkurował on z jego nieudanym Itanium na rynku serwerów i superkomputerów.
Wadą ARMów jest ich niewielka wydajność, są to ponadto procesory 32-bitowe.
Nawet MS inwestuje w ARMy, niedawno kupił licencję więc można się spodziewać porządnych Windowsów 8 na tą architekturę. Co do zachowania wstecznej kompatybilności, to jest ona przeceniana, skoro odchodzi się od programowania w językach kompilowanych do kodu maszynowego, na rzecz kodu pośredniego (.Net, JVM).
Nawet w przypadku tych pierwszych wystarczy kliknąć Rebuild i jest po problemie, jeśli nie ma wstawek asemblerowych.
Gorzej jest ze sterownikami do urządzeń, ale w przypadku większości urządzeń zewnętrznych będzie można je wykonać pod kontrolą emulatora x86 bez zauważalnego pogorszenia ich działania.
Mam nieśmiałą nadzieję że odejście MS od x86 jako jedynej wspieranej masowo architektury zmusi Intela do wskrzeszenia architektury Alpha, albo do stworzenia czegoś nowego na jej podstawie.

Andree -
http://en.wikipedia.org/wiki/AES_instruction_set
dokładnie to wygląda jak jakieś makro w samym procku uruchamiane tymi instrukcjami. Ale bynajmniej nie świadczy to o RISCowym rdzeniu w x86 Intel i AMD naprawdę świetną robotę zrobiło rozbudowując x86, ale to bez sensu jest twierdzenie że tam siedzi RISC i tłumaczy rozkazy x86. Dlaczego? Bo praktycznie cała obsługa SSE2 wzwyż (do SSE4.2 włącznie) mogłaby być zrobiona w samym (wyłącznie) dekoderze, bo i tak by wszystko przetłumaczone zostało na te same 'cegiełki'. Czyt. niektórzy starają się dowieść że intel robi coraz większe procesory z coraz nowymi rozkazami (co odbija się na dekoderze), żeby to po przetłumaczeniu na mikrokod stanowiły te same cegiełki co w i K7/P3? Bezsens - toż to niemożliwe, by SSE4 wnosiło cokolwiek do wydajności...a przecież wnosi. Tak samo SSE3. Mikrokod x86 dzieli wiele cech z instrukcjami RISC, ale nie oznacza to, że tam siedzi RISC. W końcu mikrokod jest stosowany od samego początku w x86. A przemianowanie rejestrów i inne bajerki? No to potrzebne do potokowej superskalarnej architektury...ale nadal CISC.

Ja wciąż mam w domu sprawny komputer AMD K6-2 500MHz, do tego 256MB RAM i karta grafiki Elsa 16MB. Chodzi na nim dystrybucja Slackware 9.1.

Ja nigdzie nie twierdziłem że wewnątrz CISC jest RISC.
Mikrokod jest bardzo technicznym zestawem instrukcji, jego poszczególne bity odpowiadają za uaktywnienie poszczególnych rejestrów wewnętrznych procesora i arytmometrów.
Tak więc mikrokod może się różnić w zależności od wewnętrznej budowy procesora, przy tej samej liście instrukcji.
Dlatego zaawansowane procesory RISC też używają mikrokodu, tylko w mniejszym stopniu niż procesory CISC.
http://wapedia.mobi/en/Microcode?t=6.

Andree - wiem, że POWER5 i 6 mają instrukcje na które przypada więcej niż 1 mikroinstrukcja Choć zazwyczaj jest to 1:1. W x86 jest to gorszy wskaźnik, ale i bardziej kompleksowe instrukcje, a z mikro i makrofuzjami często jeszcze bardziej.

Co portal to informacje o zmarlym jeszcze bardziej podkolorowane tu jest znośnie, na pewnym potralu autor, którego nick zobowiazuje do podstawowej znajomości technologii AMD pisze tak że aż szkoda komentować.

Do jednego sie przyczepie:
'Zestaw ten powstał jako rozszerzenie architektury x86, mające zapewniać większą wydajność obliczeń zmiennoprzecinkowych, ważnych w trakcie generowania grafiki trójwymiarowej oraz odtwarzania plików multimedialnych (filmów oraz muzyki). 3DNow! był odpowiedzią AMD na zestaw instrukcji MMX, stworzony przez firmę Intel i po raz pierwszy zastosowany w procesorach Pentium MMX.

Po dwunastu latach, 3DNow! odchodzi na emeryturę i zniknie z wielu nowych procesorów firmy AMD. Producent nie zamierza jednak rezygnować z zestawu instrukcji SSE firmy Intel - najpewniej z tego względu, że jest on znacznie częściej wykorzystywany przez programistów.'

3DNow to nie byla odpowiedz na MMX ale UZUPEŁNIENIEM stałoprzecinkowego MMX o instrukcje zmiennoprzecinkowe na MMX'owych 64bitowych rejestrach, notabene zapożyczonych ze stosu FPU i przełączanych na zmiane(nie można wykorzystać float i jednocześnie pracować na MMX)..[moim zdaniem to spore utrudnienie dziwacznej technologii wymyślonej przez intela].
Był rozwinięciem, włączało się jednoczesnie z MMX tą samą instrukcją emms lub szybszą femms(zawartość rejestrów nie była czyszczona), można było korzystać naprzemiennie z MMX i 3DNow! na tym samym zestawie danych. Nazwy instrukcji również umownie rozpoczynające się od 'P'.

Pomimo użytkowej elegancji takiego rozwiązania 3DNow! nie miało szans w konfrontacji z SSE z conajmniej 3 zasadniczych powodów.

1. Bazowalo na MMX kontynułując błędy - wmieszanie w FPU i problem we włączaniu, wyłączaniu..zamiast stanowić odrębną jednostkę wspomagającą.
Dzięki temu było to rozwiązanie sprytne i tanie w produkcji - do teraz gdy stanowi kule u nogi.

2. Operowało na 64bitowych rejestrach, chociaż umożliwiało bezpośrednie operacje na pamięci(z racji marnej architektury Socket7 było to koszmarnie powolne) to jednak nie zapewniało właściwej bazy dla zastosowań 3D a wiec możliwości operowania na całych wektorach. np. 3x32bit+32bit skalar (128bit)

3. Brak wsparcia u konkurencji doprowadził(zbyt mała siła marki) i zbyt małe korzyści z zastosowania tej technologii.

SSE nie powiela błędów MMX, 3DNOW!, wprowadza odrębne 128bitowe rejestry, bogaty zestaw instrukcji, brak konieczności przełączania('wyłączania' FPU), możliwości rozwoju i wsparcie silniejszej marki, a ostatecznie wszystkich - ku zadowoleniu programisty.
Ten zestaw rzeczywiscie może sie przydawać do operacji na wektorach, MMX i 3Dnow! jedynie na multimediach(np. kodowanie, dekodowanie strumienia audio, video) wbrew nazwie. Która powinna brzmieć FloatNow! albo FMMX

Zgaduje że możliwym przyczynkiem do wywalenia 3dnow poza zbędnym i rozbudowanym dekoderem rozkazów, jest wkomponowanie tego w FPU a w nowej AMD'owskiej architekturze byłoby jedynie balastem, tym bardziej że będą dwa rdzenie dwa FPU i jeden blok ALU tworząc zmutowane HT/2 rdzenie, mamy wielowątkowe procesory, out of order execution, sporo pracy tranzystorków wymaga zapewnienie tej narośli niezakłucalnej pracy.
Bo 3Dnow! i MMX to moim zdaniem pewnego rodzaju pleśń w procesorach.

PS Wydajność jednostki zmiennoprzecinkowej w K6 była koszmarna w porównaniu do Intelowskiej, możliwości platformy Socket7 bardzo słabe(chipsety, kontroler RAM) ten drugi element nadrabiał K6-III dodatkowym cache, ale nie mial szans ze wzgledu na ekonomie produckcji. Mialem do czynienia z K6-2 266@3x100MHz ostatnio u mamy K6-2 450MHz, pomimo jakiegoś programu/fixa aktywatora czegoś - nie wiem jak, ale dawalo spore wzrosty w testach podsystemu pamieci..to jednak różnica lata temu po przesiadce na Celerona 466MHz, różnica na kompie który mam w kuchni PIII 500MHz szybkości podstawowych zadań (rendering strony internetowej, otworzenie JPEGA) jest zdecydowanie na korzyść Intela, pomimo ogromu sympatii dla AMD z uwagi na pierwszego kompa. 3DNow! mialo swoje liczne rozwinięcia..tylko czy ktoś z tego wogóle korzystał poza benchmarkami?

'3DNow! był odpowiedzią AMD na zestaw instrukcji MMX, stworzony przez firmę Intel i po raz pierwszy zastosowany w procesorach Pentium MMX.'

Dziwi mnie, ze poważny portal podaje tak mylne informacje. Proponuję Panu Redaktorowi trochę poczytać, nim się głupotki napisze. Przecież AMD wyprzedziło Intela w SSE. Chyba, że Pan Redaktor jest młody i nie pamięta tych procesorów.
Odsyłam choćby do Wiki i proszę nie pisać więcej bzdurek za które jeszcze Panu płacą.

'K6-2 był pierwszym procesorem w którym wbudowano obsługę operacji zmiennoprzecinkowych SIMD (nazwanych 3DNow!) które znacznie ułatwiały i przyspieszały wykonywanie aplikacji związanych z grafiką trójwymiarową. 3DNow! wyprzedziło pojawienie się na rynku intelowskiego odpowiednika SSE o kilka miesięcy.'( Z Wikipedii)

haha miałem gdzieś takiego procka.