Intel opowiada, PCLab.pl - dogaduje (część 2)

Kontytnuujemy pogawędkę z Pawłem Gepnerem z Intela. O tym, kto z rozmówców jest kim, czytajcie w pierwszej części.

Trochę futurologii

Paweł Gepner: Pójdźmy w przyszłość, powiedzmy sobie, poza rok 2015... nie będzie nas już interesowało, czy kod jest powiedzmy Intel64, czy assembler 8086, czy ktoś napisał coś w EPIC-u IA-64.

Ryszard Sobkowski: Doszedłeś Paweł do czegoś, co chodzi za mną już od pewnego czasu. Kolejne SSE. Kolejne wersje SSE wydają się zmierzać do tego, żeby w ogóle wyeliminować x86.

PG: Może nie wyeliminować, bo przecież czegoś trzeba uczyć studentów, ale przecież nikt im nie będzie kazał nauczyć się wszystkich instrukcji. Oczywiście, że masz rację. Wiesz, człowiek jest z natury leniwy, jak masz coś zrobić przy użyciu kilkunastu instrukcji, zrób to jedną.

rs: Dlatego właśnie widzę, tak u Intela, jak i u "innych", silny pociąg do starej, dobrej koncepcji Very Long Instruction Word.

PG: Może to nie jest tak, że dążymy do powrotu do tego... ja myślę, że SSE jest tak naprawdę po prostu wychodzeniem naprzeciw zapotrzebowaniu rynku. Jak ktoś używa często jakiejś tam kombinacji instrukcji, to dajmy mu zamiast tej kombinacji - jedną instrukcję. Krócej, szybciej, łatwiej! Very Long Instruction Word ? Co to jest takie klasyczne VLIW? Ja bym powiedział, że nie ma już takich "fundamentalistów", którzy dzielą na EPIC, RISC, CISC...

rs: Ostatnia implementacja Very Long Instruction Word nazywa się, o ile dobrze pamiętam, Itanium?

PG: Nooo... EPIC, bym powiedział, to raczej "one generation ahead"! Tylko pamiętaj o jednym - w EPIC jest paczkowanie instrukcji, a w SSE paczkowanie danych. Oczywiście efekt jest taki sam, bo na koniec dnia masz mieć wyniki i nie obchodzi Cię, co było paczkowane.

rs: No i dlatego mówię o VLIW - to jest paczkowanie jednego i drugiego - i danych, i instrukcji równocześnie.

PG: Zgoda. Znaczy, jasne - na koniec dostajesz 128-bitowe dane, będące paczką wyników uzyskanych przez dwie instrukcje, które tak naprawdę są jedną instrukcją. Jeżeli tak do tego podchodzimy - no tak, będzie coraz szerzej.

rs: Musimy tak do tego podchodzić, bo inaczej nie miałyby sensu instrukcje ALU w SSE.

PG: Jasne! Ale wydaje mi się, że rozwiązaniem zdecydowanie prostszym niż "remodyfikacja", paczkowanie, przerabianie schedulera, jest dodanie nowych instrukcji. W końcu przecież i tak sami piszemy kompilator, więc jaki problem? Dodajesz nowe instrukcje, piszesz nową wersję kompilatora. Musisz poszerzyć, oczywiście, rejestry, poszerzyć bufory...

rs: Nooo... to akurat jest najprostsze.

PG: Oczywiście, że jest najprostsze, dlatego to zrobiło AMD. To jest dość efektywne rozwiązanie...

Michał Tomaszkiewicz: Jak bardzo wiążąca jest ta data 2015 rok? Czy to tylko tak przykładowo?

PG: Nie, nie! Ona jest tak "z powietrza" rzucona. Bo tak ogólnie to wiemy, jaka będzie ewolucja. Teraz mamy Montecito, potem będziemy mieli Tukwillę, która jest na 2008, później będzie Poulson, który jest dość dużym, prawie rewolucyjnym skokiem, no a potem będziemy mieli następną generację procesorów, które będą coraz bardziej konwergowały architektury Intel 64 i IA-64, czy jakkolwiek je będziemy wówczas nazywać. Bo jak dla mnie, to już dzisiaj powinniśmy mówić o I-128 - większość instrukcji jest już 128-bitowych.