Aktualność
Adrian Kotowski, Piątek, 1 lutego 2019, 16:28

Kończy się pewna era. Intel opublikował dokument dotyczący wprowadzenia zmian w swojej ofercie, a konkretnie usunięcia z niej jednostek Kittson. W skład tej rodziny wchodzą procesory Itanium serii 9700, wprowadzone na rynek w 2017 roku. Już wtedy było wiadomo, że będą to ostatnie chipy korzystające z architektury IA-64, które Intel będzie dostarczał do swojego partnera.

Procesory Itanium 9700 są obecnie wykorzystywane właściwie tylko w maszynach Integrity Superdome 2 firmy Hewlett Packard Enterprise. Z tego powodu wpływ decyzji niebieskich na rynek będzie minimalny. Według opublikowanego dokumentu HPE może składać zamówienia na chipy do 30 stycznia 2020 roku. Ostatnie dostawy układów mają zostać zrealizowane do 29 lipca 2021 roku.

Sprawdź ranking najpopularniejszych procesorów dostępnych w Polsce

Na liście produktów, których produkcja zostanie wstrzymana, znalazły się modele Itanium 9760, Itanium 9750, Itanium 9740 i Itanium 9720. Pierwszy z nich jest jednostką ośmiordzeniową i szesnastowątkową, a resztą oferuje cztery rdzenie i osiem wątków. Jednostki wykonano w procesie technologicznym 32 nm i przeznaczono do współpracy z podstawką LGA1248. Po zakończeniu dostaw HPE jeszcze przez 4 lata zamierza oferować wsparcie techniczne dla swoich serwerów HP-UX 11i v3 z procesorami Kittson.

Intel Itanium

Źródło: Anandtech
Ocena aktualności:
Brak ocen
Zaloguj się, by móc oceniać
cichy45 (2019.02.01, 16:45)
Ocena: 16

0%
Wydaje mi się że x86_64 to tylko rozszerzenie x86 więc jako tako bez niech chyba działać nie będzie. Ktoś może napisać czy jest to możliwe?
Namonaki (2019.02.01, 17:13)
Ocena: 19

0%
x86_64 bez x86 to absurd
@up dobrze Ci się wydaje
przecież nawet rejestry 32 bitowe są nisza częścią rejestrów 64 bitowych tak jak to jest z eax i rax
do tej pory nie zrezygnowano z 16 bitowych instrukcji i rejestrów (są częścią 32 bitowych); ax jest częścią eax
a instrukcje operujące na tych rejestrach są nadal 16 i 32 bit
mov rax, 0 //to instrukcja x86_64 (64bit)
mov r8, 0 //również x86_64
mov eax, 0 // instrukcja x86 (32bit)
mov ax, 0 // 16 bitowa (286)
mov ah, 0
[każda z tych instrukcji ustawia dany rejestr na 0]

dodatkówo rejestry SSE są niższa częścią rejestrów AVX

nawet ARM64 jest rozszerzeniem ARM w analogiczny sposób

wracając do IA-64 ostatnimi laty linia Itanium 9700 dogorywała
intel wydał w niej procki o 100 MHz szybsze w nie zmienionej litografi
Itanium przegrało z AMD64 przez kompletną zmianę architektury.
Promilus1984 (2019.02.01, 18:57)
Ocena: 3

0%
Itanium przegrało bo było drogie i niewygodne (jeszcze mocniej zależne od optymalizacji kompilatora niż x86). Gdyby intel mógł się skupić nad dopracowaniem tej architektury to jakaś szansa była, ale okazało się, że do starego dobrego x86 wystarczyło dodać szersze rejestry i nagle tanim kosztem uzyskać to co w pocie czoła osiągnęła ekipa od IA64. A niemożliwe było jednocześnie wspierać rozwój IA64 oraz z zadowalającą prędkością (czyt. przynajmniej porównywalną do konkurencji z x86-64) wykonywać kod x86. Innymi słowy to musiało w końcu umrzeć, szczególnie gdy Intel zaczął znów pompować x86, bo samo AMD tego wózka by nie uciągnęło, nie z Phenomami i Bulldozerami.
Wibowit (2019.02.01, 19:00)
Ocena: 4

0%
nawet ARM64 jest rozszerzeniem ARM w analogiczny sposób

Akurat w ARM przy przejściu na 64-bit coś pozmieniali. ARM wyrzuciło z opkodów bity odpowiedzialne za conditional/ predicated execution. Jest to bardzo znacząca zmiana.

ARMv8 Instruction Set Overview:
The A64 instruction set does not include the concept of predicated or conditional execution. Benchmarking shows that modern branch predictors work well enough that predicated execution of instructions does not offer sufficient benefit to justify its significant use of opcode space, and its implementation cost in advanced implementations.
Promilus1984 (2019.02.01, 19:40)
Ocena: 6

0%
ARM wyrzuciło z opkodów bity odpowiedzialne za conditional/ predicated execution. Jest to bardzo znacząca zmiana

Zupełnie nieznacząca. Aplikacja nie może naraz korzystać z instrukcji 32 i 64bit. Czyli wersja 64bitowa musi być skompilowana na nowo. Zmiana ta w żaden sposób więc nie dotyka developerów, kompilator sam zadba by pojawiła się odpowiadająca temu sekwencja rozkazów maszynowych.
Wibowit (2019.02.01, 20:11)
Ocena: 3

0%
Promilus1984 @ 2019.02.01 19:40  Post: 1187176
ARM wyrzuciło z opkodów bity odpowiedzialne za conditional/ predicated execution. Jest to bardzo znacząca zmiana

Zupełnie nieznacząca. Aplikacja nie może naraz korzystać z instrukcji 32 i 64bit. Czyli wersja 64bitowa musi być skompilowana na nowo. Zmiana ta w żaden sposób więc nie dotyka developerów, kompilator sam zadba by pojawiła się odpowiadająca temu sekwencja rozkazów maszynowych.

Przecież w żadnym wypadku aplikacja nie może być w trybie 32-bitowym i 64-bitowym jednocześnie, obojętnie czy to na ARMie czy x86, MIPSie czy czymkolwiek innym. Stąd z twojego stwierdzenia wynika iż każda zmiana przy przechodzeniu z 32 bitów na 64 bity jest nieznacząca.

Mi chodziło o znaczną zmianę w konstrukcji procesora i kompilatora. Conditional execution w praktyce stoi w opozycji do speculative execution. Łączenie ich utrudnia ich optymalne wykorzystanie w kompilatorze, który musi zdecydować się którego rodzaju mechanizmu użyć. Podobnie procesor musi sobie zdecydować czy napotykając warunkową instrukcję wykonać ją spekulatywnie czy nie. Wszelakie procki x86 nie używają spekulatywnego wykonywania przy wykonywaniu warunkowym czegokolwiek innego niż skoku. Tzn jak mamy np `movbe eax, ebx` to procek zaczeka, aż najpierw flagi zostaną policzone, ale przy skoku, np `jbe cel` procek już wykorzystuje wykonywanie spekulatywne i nie czeka na liczenie flag. Wykorzystywałem ten fakt nieraz, np jak programowałem w czystym asemblerze x86.
Edytowane przez autora (2019.02.01, 20:14)
Promilus1984 (2019.02.01, 20:20)
Ocena: 0

0%
Przecież w żadnym wypadku aplikacja nie może być w trybie 32-bitowym i 64-bitowym jednocześnie, obojętnie czy to na ARMie czy x86, MIPSie czy czymkolwiek innym

Tak, ale gdybyś spojrzał szerzej na ARM to zauważyłbyś, że jest taki zestaw instrukcji Thumb2, który pozwala mieszać instrukcje 16 i 32bit. I nie ma żadnego przeciwwskazania by tak samo nie mogło to działać z 32 + 64bit, po prostu nie jest to potrzebne. Thumb2 służy zbalansowaniu gęstości kodu i jego wydajności (i jest z tego powodu głównie wykorzystywany w mikrokontrolerach gdzie jest dość ograniczona ilość pamięci). Na komputerach kod nie musi być wcale kompaktowy. Od bardzo dawna nie jest.
A co do Aarch64 to jakoś mam wrażenie, że (pewnie ze względu na już większą dojrzałość aplikacji dostosowanych do 64bit) wniosło to więcej wydajności do ARM niż ARM64 dla x86.
Wibowit (2019.02.01, 20:39)
Ocena: 0

0%
W x86 pojedyncza instrukcja może mieć od jednego bajta do kilkunastu bajtów. Nie bardzo widzę jak różna długość instrukcji ma wpływać na konstrukcję kompilatora bądź spekulatywne wykonywanie instrukcji.
Zaloguj się, by móc komentować
Aktualności
Artykuły spokrewnione
Facebook
Ostatnio komentowane