Trzeba sie do tego przyzwyczajać, takie czasy.



oj chyba nie młody i raczej pamięta



Istotnie AMD wyprzedziło Intela mając nadzieje na upowszechnienie ich rozwiązania rozwijającego MMX, ale Intel porzucił MMX (to było skrojone na lata wczesniejsze i ograniczenia w liczbie tranzystorów) i wprowadził dedykowane jednostki SSE - w tej konfrontacji pośpiech AMD był niewiele wart i nie ma znaczenia poza symboliką.

skoro stypa to przydałoby sie dodać do wspominek opis zmarłego:
http://softpixel.com/~cwright/programming/simd/3dn.php

To ja proponuję przeczytanie zacytowanego fragmentu newsa - tak z pięć razy. W tekście jest o MMX, a nie o SSE.

@Stan - 3DNow! w zoptymalizowanych sterach do Voodoo dawało bardzo wiele więc znów o takim koszmarze bez realnego zastosowania nie opowiadaj.
http://www.xbitlabs.com/articles/cpu/display/k6-iii.html
30% więcej w Q2 na VooDoo z 3DNow! Szybko pojawiło się SSE, którego i K7 nie obsługiwało aż do Palomino i thoroughbred (jak dobrze pamiętam) więc 3DNow! było nadal w użytkowaniu. Gdy zarówno intel jak i amd mieli już SSE2 które rzeczywiście mogło zastąpić w większości x87 to zarówno czyste SSE jak i 3DNow! przestało mieć większe znaczenie.
EDIT - zapomniałbym - super socket 7 to także 100MHz RAM i do tego 3 poziomowa struktura cache (z L3 na płycie w wypadku K6-III, K6-2+ oraz K6-III+) i zasadniczo jest to ciut lepsze rozwiązanie niż samo PC100. Tak, wiem ile było problemów różnorakich z alladinami +agp itp. itd.

Co ma do rzeczy kto jest starszy? I tak większość ludzi pamięta czasy K6 - nawet ja

1. Sega 16bit.
2. Atari Transputer.
3. Celeron 100MHz/64MB RAM/jakaś grafa 1MB
4. Duron 800MHz/128MB RAM/TNT2
5. Celeron 2.8GHz/256MB RAM/Radeon 9200SE -mam;0
6. Pentium 3.0 GHz/512MB RAM/Radeon 9550
7. Intel Dual Core E4500 2.2GHz/2GB RAM/GF8600GE -mam
8. AMD X4 630/4GB RAM/HD4730 -mam;]
9. Server G34 w dualu X12 + 8GB RAM i używana NVidia Tesla -m(ni)am

A ja mialem Commodore VC-20 z 20 KB ram i magnetofonem.I po co to cale zamieszanie???3DNow umarlo i niech spoczywa w pokoju.

3dnow! już z 10 lat było martwe. Ale swego czasu to pierwszy Unreal z tego korzystał . Póki SSE nie było to 3dnow było dość popularne. Czyli jakiś rok

Pominę tutaj z litości jakim dziadem był K6-2 przy Celeronie z cachem . To pewno tez wplynelo na niską popularność 3dnow

'Właściciele jakichś 5 miliardów komputerów, a konkretnie aplikacji do nich itp. Przez 10 lat trzeba by pisać 2 wersje aplikacji. Jedną na x86, a drugą na nową architekturę. No chyba, że jakaś firma zdecydowałaby się wypuścić program, który na początku byłby niekompatybilny z 99,99% komputerów osobistych.'

Widzisz - i tu problemem nie jest sam procesor a .... system operacyjny.
Zamknięty kod źródłowy większości aplikacji pod winde powoduje, że ludzie oczekują wstecznej kompatybilności. Na unixopochodnych większość softu ma kod otwarty - ściągasz źródła i kompilujesz je pod siebie - 99% aplikacji ruszy od kopa, ten jeden procent który zależy od proca (np. są wstawki assemblerowe) ktoś szybko przerobi na nową architekturę.

Dokładnie.
To kwestia przyzwyczajenia oraz lenistwa. Do tego, że na kolejnych Windowsach mogą nie działać stare programy ludzie jakoś się przyzwyczaili - a na początku też był ciągle raban z tego powodu. I bardzo dobrze, że się przyzwyczaili - trzeba iść naprzód. Przynajmniej wymusza to na programistach trochę mniej niechlujne pisanie kodu.
Na komórkach też jakoś nikt nie marudzi, że stara gierka czy programik w Javie nie działa na każdym wymienianym co pół roku telefonie.
Gdyby zmienność platform i konieczność uelastycznienia sposobu dystrybucji softu, oraz elegancja pisania kodu stały się czymś normalnym - nikt by nie marudził, a większość userów by zyskała.

Thoroughbred B napewno miał SSE. Miałem Athlona 2200+ XP na tym rdzeniu i pamiętam. A co do RISC-a w x86, to przepraszam, upraszczałem. Oczywiście chodziło mi o wiele naleciałości, które zbliżyły x86 do standardu RISC-a. I tak 'tłumaczenie' tych starych instrukcji CISC-owych, które wciąż są wykorzystywane, na te zrozumiałe dla dzisiejszego procesora mocno wali po wydajności. Jak ktoś wyżej napisał wystarczy porównać wydajność normalnie napisanej instrukcji, z instrukcją napisaną w SSE. Część przyspieszenia, będzie wynikało z tego, że zajmuje się tym dedykowana jednostka, ale większość z tego, że kod nie musi być dekodowany i dopiero wtedy uruchamiany. Wszyscy tu myślą, że dekodowanie wogóle nie zabiera czasu.

x86 nigdy nie było zbliżone do RISC. To od samego początku jest CISC, i w stronę wręcz karykaturalnie wyolbrzymionego CISC wciąż brnie. Pewnie, dziesiątki specjalizowanych instrukcji, przyspieszających obliczenia używane przy multimediach czy szyfrowaniu zwiększają wydajność w wielu zastosowaniach. Ale jednocześnie pogarszają wydajność całego systemu. Większa ilość podukładów to bardziej skomplikowane struktury zarządzania i przełączania, to więcej szyn danych i sterujących. To dłuższy czas dekodowanie instrukcji, przesyłania dodatkowych danych, większe czasy propagacji przez kolejne warstwy logiki układu.

Wiadomo, że komputer szyfrujący przez 90% czasu dane zrobi olbrzymi użytek z dodatkowych instrukcji np. dedykowanych dla AES. Ale np. dla maszyny, która nigdy szyfrowania na 'oczy' nie zobaczy, takie instrukcje to swego rodzaju balast, w pewnym minimalnym stopniu spowalniający wykonywanie innych instrukcji.
Czasem są różne jazdy w stylu 'spodziewaliśmy się po architekturze i zegarze większej wydajności, ale ten CPU nie spełnił oczekiwań; wydaje się nam, że to wina kontrolera pamięci, albo [bla, bla, bełku, bełku]'.
'Nowotwór' listy rozkazów jest jedną z tysięcy przyczyn, mogących takie cuda powodować - ale prawdę na ten temat znają w zasadzie tylko inżynierowie Intela... ;]

Niestety nie można sobie wybrać CPU z takimi a takimi 'power-up'ami', a resztę amputować Więc Intel i AMD starają się zapewnić programistom jak najmniejszy zestaw jak najprzydatniejszych instrukcji. Różnie im się to udaje Tu akurat poszli po rozum do głowy i wymiatają w końcu śmieci spod dywanu.

@FunnyPunch - napisałem wyraźnie K7 nie miało SSE aż do Palomino i thoroughbred. To rdzenie będące podstawą Athlona XP (później jeszcze Barton). Ale K7 to nie tylko XP - XP to w zasadzie końcowe modele K7... od 600MHz (IIRC) do ~1400 cały czas było 3DNow! oraz Advanced 3DNow! - I mimo wszystko AMD nie traciło względem SSE Intela. Jak wcześniej napisałem tak naprawdę era SSE zaczęła się od SSE2.

Mój błąd. Czytanie ze zrozumieniem na ogół nie jest dla mnie problemem, ale jednak czasem skrewię . I masz racje, że pierwsze SSE, było 'lepsze' tylko dlatego, że było u Intela, który był mimo wydajniejszych produktów ze stajni AMD bardziej popularny.

SSE miało o tyle znaczenie, że w czasach pierwszych Athlonów 64, Athlony XP i pochodne Semprony nadal były sprzedawane jako lowend (podobnie jak dzisiaj Intele na LGA775). Procesory te nie miały SSE2 (które P4 miały już od dawna), więc w tych czasach SSE to był najbardziej zaawansowany zestaw instrukcji obsługiwany przez wszystkie procesory na rynku.

Jak wasze rozważania na temat wydajności i energooszczędności RISC vs x86 (CISC pseudo RISC) mają się do PowerPC z którego Apple zrezygnowało na rzecz Core2Duo?

A jak się odniesiesz do specyfikacji PWRficient? Apple wykupiło producenta PA Semi i... cisza.

Nijak. To nie moja działka. Ale jak już tak porównujecie w teorii to chciałbym abyście porównali na przykładzie. Nie mam takiej wiedzy jak Wy (jako stary gracz tak hobbistycznie się interesuję takimi sprawami żeby nie być całkowitym ignorantem ) i chciałbym się dowiedzieć dlaczego Apple zrezygnowało waszym zdaniem z genialnego RISC na rzecz x86.

Bo miało tylko jednego producenta - IBM który stroił fochy bo chciał się skupić na serwerach i nie zależało mu na opracowaniu energooszczędnego procesora dla notebooków. Wykupili PA Semi razem z świetnym prockiem do takich właśnie zastosowań (prawdopodobnie trafi do Amiga X1000). I cisza...żadnego nowego projektu. No dobra, niby technologie PA Semi siedzą w iPadzie. Ale nie PWRficient.

Architektura architekturą, ale nie tylko to się liczy. Schyłkowe procesory POWER wykorzystywane przez Apple'a były prądożerne i wolne. Oczywistym jest, że dobrze zaprojektowany, nowoczesny i przemyślany procesor x86 będzie dużo lepszy od przeciętnego RISCa.
Zwłaszcza w przypadku wydajniejszych procesorów różnice w architekturze się zacierają i na pierwszy plan wychodzą inne kwestie. W przypadku procesorów energooszczędnych trudniej już ominąć ograniczenia architektury i tu bardziej widać wady x86, choć szczerze mówiąc jeśli chodzi o wydajność to dopiero Cortex A9 dogonił Atoma.

@Assasin - wracaj do swojego avatara, ok? Bo myślałem, że się ktoś podszywa.

ARM są narazie tylko dobre na rynki tabletów, komórek itp. W przyszłości się to powinno nieco zmienić. A co do tego, że RISC jest gorszy, to czy ktoś wie jakiego typu procesorem jest Cell? RISC czy CISC? Bo nawet teraz cell jest dość mocny.