> Dobrze napisana aplikacja obciąży na tyle mocno jedną jednostkę
> logiczną HT, że ta druga nie będzie miała wiele wolnych zasobów,
> a potencjalny znikomy zysk wydajności zostanie stracony przez
> narzut rozdzielania wątków.
Mało prawdopodobne. Nie samymi obliczeniami program żyje. Co do narzutów
rozdzielania wątków to pojęcie to ma sens w przypadku wykonywania kilku
wątków przez jedną jednostkę wykonawczą (jakieś np. przerwanie timera w
którym przełącza się stos i zamienia rejestry). W przypadku dwóch jednostek
wykonawczych ze wspólną cache, problem ten nie występuje (jest tylko kwestia
rozpoczęcia wykonania wątku na określonej jednostce wykonawczej).
Rozdzielanie procesów pomiędzy rdzenie HT czy nawet w obrębie jednej
jednostki wykonawczej jest bardziej kosztowne - procesy operują na osobnych
fragmentach kodu i osobnych obszarach danych. Zatem przy przełączaniu trzeba
przepisywać spore ilości danych do pamięci i vice versa (chyba że CPU ma
monstrualnych rozmiarów cache).
Poza tym "dobrze napisana aplikacja" dzieli problem na wątki jeśli algorytm
na to pozwala. Dlatego "dobrze napisane aplikacje" działają szybciej na
nowych procesorach.
>
> No ale teraz stosuje się wspólne cache w nowych rozwiązaniach.
Nie do końca, L1 nie jest wspólne. Dzięki temu unika się prawie 50% wait
state-ów przy dostępie jednostki wykonawczej do cache. Natomiast co do L2 to
się zgadzam, jest to niewątpliwie krok na przód.
Naturalnie można wyobrazić sobie cache L1 "triple-port" (ci którzy bawią się
współczesnymi strukturami FPGA wiedzą o co chodzi:)) ale ciekawe kiedy
producenci procesorów na to wpadną. Pewnie jak zwykle już wpadli, ale
przecież chodzi o sprzedaż.
> No i w przypadku architektury AMD ten problem rozwiązuje
> niezmiernie szybkie łącze HyperTransport. To, co piszesz,
> jest problemem jedynie dla wczesnych odmian procesorów
> dwurdzeniowych Intela, w których rdzenie komunikowały
> się przez FSB.
Niezmiernie szybkie to pojęcie względne. Problem ten nie jest zupełnie
wyeliminowany jak długo mamy odrębne wszystkie poziomy cache dla
poszczególnych jednostek wykonawczych. Mówiąc w skrócie, efekt ten jest przy
AMD byćmoże "mniej dokuczliwy". Znacznie mądrzejszym rozwiązaniem jest
wspólne L2. Wtedy wymiana informacji może odbywać się w zasadzie bez udziału
świata zewnętrznego jeśli tylko L2 pomieści wszystkie potrzebne informacje.
> Ale wspólne są też jednostki obliczeniowe, a tych wcale
> nie jest tak dużo. Zresztą pewnym potwierdzeniem może być
> ignorowanie HT przez AMD (mimo, że podobno mają całą
> technologię i odpowiednie patenty) oraz wycofywanie się
> (przynajmniej na razie) z jego implementowania przez Intela
> na rzecz "pełnych", niezależnych rdzeni ze wspólnym cache.
>
Nie samymi obliczeniami program żyje - wspólna jednostka obliczeniowa nie
powoduje dwukrotnego obniżenia wydajności rdzeni HT. Co do ignorowania HT
przez AMD - pewnie mają swoje, inne pomysły i wizje świata. Zresztą każde
rozwiązanie ma swoje zalety i wady. Nikt przecież nie zrobi procesora
idealnego. Zresztą jest jeszcze bardzo przyziemne kryterium - cena.
Received on Sat Aug 19 13:40:10 2006
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sat 19 Aug 2006 - 13:51:17 MET DST