Specyfikacja techniczna pierwszych Xeonów Phi

1. Głupota... (autor: Kenjiro | data: 2/08/12 | godz.: 16:00)
   Programowanie wielowątkowe w kodzie x86 jest o niebo trudniejsze niż operacje wielotorowe robione w OpenCL, do tego dochodzi problem z wykorzystaniem wszystkich rdzeni... Jak dla mnie to głupota.
   
   P.S. Jak można pisać o architekturze x86, że jest plusem, skoro to najgorsza z obecnie istniejących architektur? Marketoidzi pozamieniali się głowami z ...
   
   
2. Kenjiro, no fakt (autor: Duke Nukem PL | data: 2/08/12 | godz.: 17:30)
   Tylko dlaczego te x86 tak wypłynęło? Może dlatego że przez to iż był to na początku układ głęboko siedzący w koncepcji kalkulatorowych rejestrów był wyceniany niżej niż reszta procesorów? Motorola miała piękne procesory. Sama lista rozkazów była już piękna. Krótka i symetryczna dla pamięci i rejestrów. Po prostu zgrabna. Nie to co x86.
   Był kiedyś taki Zilog, który mocno rozszerzył listę rozkazów x86 o piękne rzeczy ale niestety nie wybił się. I miał piękne peryferia. Niestety był nieco droższy i chyba dlatego chłam wypłynął na wierzch. Marketing panie, marketing. Liczy się taniość a nie jakość i solidna wizja prostoty.
   
   
3. @Kenjiro (autor: Promilus | data: 2/08/12 | godz.: 18:49)
   "Programowanie wielowątkowe w kodzie x86 jest o niebo trudniejsze"
   A kto ci każe pisać w x86, od tego masz m.in. OpenMP z C++ ;)
   "skoro to najgorsza z obecnie istniejących architektur"
   pokaż wydajniejszą w tej cenie.
   
   
4. x86 wygralo bo (autor: pandy | data: 2/08/12 | godz.: 23:32)
   sprzet byl zgodny z i8080 zwlaszcza wersja i8088 mogla bez problemow korzystac ze wszystkich perfyeriow i8080 a bylo ich cale mnostwo (wiecej niz w Z80 i MC68K),
   
   zostalo wybrane przez IBM wlasnie ze wzgledu na i8088 i latwiejsza w produkcji plyte glowna.
   
   a pozniej juz sie potoczylo - zamiast innowacji nasladownictwo i tyle
   
   
5. OMFG (autor: LoneStarr | data: 3/08/12 | godz.: 00:24)
   Dalej ciągną ten wóz z węglem x86, ile to już lat? :/
   
   
6. Ciagna ale z orginalego x86 malo co zostalo (autor: pandy | data: 3/08/12 | godz.: 21:53)
   juz PII wprowadzilo translacje kodu x86 na kod RISC i Intel (i nie tylko Intel) w ten sposob zalatwia problem CISC - tak naprawde implementuje sie jako RISC wiele instrukcji a reszte w postaci mikrokodu (zreszta z mozliwoscia update)
   
   
7. @pandy (autor: Promilus | data: 3/08/12 | godz.: 22:10)
   "juz PII wprowadzilo translacje kodu x86 na kod RISC"
   Nie jest to zupełnie prawda. Nie ma tam żadnego rdzenia RISC i translatora który zamienia rozkazy maszynowe CISC na wewnętrzne RISC, a ten znowu dekoduje do mikrokodu. Dekoder x86 od razu dekoduje do postaci mikrokodu, a jak ktoś się wyrwie z tym, że przecież mikrokod jest RISC to muszę ostudzić - tak, ale rozkaz CPU w architekturze RISC nie musi oznaczać 1 operacji w mikrokodzie. Prawda jest taka, że RISC też się już spasły i o ile wewnątrz dalej działa szybkie i proste jąderko, o tyle na zewnątrz już spaślaczek rośnie. Intel zaś x86 nie pogrubia zbytnio na zewnątrz, a przy okazji wewnątrz jąderko też już ładnie zapieprza - stąd nie ma większych już różnic w wydajności np. PPC vs x86 gdy jeszcze dekadę temu różnica była bardzo wyraźna.
   
   
8. @Promilus (autor: pandy | data: 4/08/12 | godz.: 13:12)
   RISC czy CISC to w tej chwili umowne - PII ma oczywiscie zaimplementowane sprzetowo znaczna czesc rozkazow, ma rowniez translacje rozkazow na mikrokod.
   Inny przyklad ze stajni intela - P4 ze brakiem barrel shiftera i jego implementacja w mikrokodzie...
   
   A juz od dawna Intel ma niewiele wspolnego z 8088/8086
   cyt za http://www.emulators.com/docs/pentium_1.htm
   
   What made the 386 so special? Well, Intel did a number of things right. First they made the chip more orthogonal. What that means is that they extended the machine language instructions so that in 32-bit mode, almost any of the 8 32-bit registers could be used for anything - storing data, addressing memory, or performing arithmetic operations. Compare this to the 8086 and 80286 whose 16-bit instructions could only use certain instructions for certain operations. The orthogonality of the 386 registers made up for the extra registers in the Motorola chips, which specifically had 8 registers which could be used for data and 8 for addressing memory. While you could use an address registers to hold data or use data registers to address memory, it was most costly in terms of clock cycles.
   
   
9. @06 (autor: Plackator | data: 4/08/12 | godz.: 22:42)
   K5 od AMD był przed PII :/
   http://twojepc.pl/...ga_ku_wydajnosci&strona=9
   
   
10. @9 Pierwszy byl NexGen (autor: pandy | data: 5/08/12 | godz.: 12:20)
    bo Nx586 byl w 1994 roku, K5 bylo w 1996. I zdaje sie ze w artykule jest blad AMD kupilo NexGen'a po failu K5 i technologia NexGen'a byla uzyta w K6. W K5 AMD uzylo elementow swojego RISC'a AM29050.
    
    
11. @pandy (autor: Promilus | data: 5/08/12 | godz.: 15:35)
    Źle to rozumiecie. NexGen miał swój RISCowy rdzeń i używał translacji rozkazów x86 na ten rdzeń (gdzie każdej instrukcji RISC odpowiadała jedna instrukcja mikrokodu). Tak samo AMD w K5 użyło rdzenia AM29k i tłumaczyło rozkazy x86 na rozkazy tego rdzenia. Ale w K7 nie użyło ani rdzenia am29k, ani alphy, ani żadnego innego RISC. 8086 (czy 8051) także mimo modelu programowego CISC nie miał instrukcji mov x,y jako najniższych niepodzielnych mikrooperacji, a tylko TAKŻE z mikrooperacji składał to co miał dekodek obsługiwać. Cały pic z wojenką CISC vs RISC był taki, że CISC na większość operacji potrzebował wiele cykli, szczególnie jeśli dot. pamięci zewn, natomiast operacji RISC zazwyczaj wykonywały się w 1 cyklu, ale nieraz potrzeba było tych instrukcji więcej do zrealizowania tego samego działania. W początkach kompilatorów z tego powodu CISC miały drobną zaletę bo łatwiej się tłumaczyło taki C czy Pascal na kompleksowe instrukcje niż grupy prostych. Ale co się stało później? :) Ano proste. CISC dostał superskalarną potokową architekturę i W TYM WŁAŚNIE momencie różnice między RISC, a CISC zaczęły się zacierać, bo CISC także mógł kilka instrukcji naraz przetwarzać oraz także wypadkowo wychodził w okolicach 1instrukcję/cykl dla danego potoku. RISC ma nadal taką przewagę, że mniej tranzystorów trzeba do dekoderów, a dodatkowo mogą pracować zazwyczaj z wyższymi zegarami taktującymi, ale nie jest tak, że nagle od K5/NexGen w x86 siedzi RISC - to nieprawda.
    
    
12. @11 Nie bardzo rozumiem (autor: pandy | data: 6/08/12 | godz.: 22:36)
    w K5 AMD uzylo elementow architektury AM29K akurat to mieli - calkiem niezly CPU, z kolei NexGen mial cos wlasnego natomiast nie utozsamialbym RISC z konkretna ISA.
    
    Generalnie RISC operuja na rejestrach wewnetrznych ktorych maja duzo, ich lista instrukcji jest prosta i zoptymalizowana by wiekszosc instrukcji byla wykonana bezposrednio w hardware. Z rozwojem technologi duza ilosc rejestrow zastapil cache i przewaga RISC zmalala.
    
    Co do reszty prosze zwroc uwage na P4 ktory ma wyrozniony Execution Trace Cache - tu nie chodzi o RISC w stylu AM29K czy Alpha ale o koncept rozbijania instrukcji na mikroperacje (to akurat rozwiazanie znane od dawna wystarczy wspomniec bitslice processors takie jak np AM2900 - mikroprogramowane ktore mogly w teorii udawac dowolna ISA - nawet Rosjanie zrobili w ten sposob swoj pierwszy komputer osobisty Agat - zgodny z Apple II emulujac 6502 ktorego nie produkowali).
    
    
13. @pandy (autor: Promilus | data: 7/08/12 | godz.: 18:22)
    "Generalnie RISC"
    Generalnie RISC i CISC odnoszą się do listy rozkazów procesora, a nie mikrooperacji czy samej struktury wewn. rdzenia. W przypadku CISC masz kilkadziesiąt rozkazów * kilka trybów adresowania i już robi się zasadniczo kilkaset realnych różnych dla procka instrukcji. W przypadku RISC było inaczej. Zazwyczaj było dużo rejestrów ze względu na to, że nie było możliwości operować bezpośrednio na danych w pamięci. I tak jeśli wezmę 8051 mogę każdą komórkę z pierwszych 128B traktować niemal jak rejestr - tzn. mogę dać etykietę DUPA i stosować inc DUPA i procek to wykona. W przypadku RISC najpierw muszę załadować zawartość DUPA do rejestru, zinkrementować go i zapisać spowrotem do komórki pamięci DUPA. Obecnie RISC się mocno rozrosły w tryby adresowania i instrukcje, a CISC mają register renaming, mikrofuzje itp. Zasadniczo więc przynależność jest głównie historyczna, albo bardzo umowna.