Slo-Tech - Intel je prodajo procesorjev družine Itanium končal leta 2021, kar bi lahko šteli kot prvo smrt te generacije. Še ena pomembna prelomnica za arhitekturo IA-64 pa se je zgodila v najnovejši verziji Linuxovega jedra 6.7, ki je izšla ta teden. Linux je uradno ukinil podporo za IA-64, s čimer je tudi ta skupnost jasno pokazala, da je arhitektura zares pristala na smetišču zgodovine.
Lastniki procesorjev Itanium seveda še vedno lahko uporabljajo starejše verzije. Ker je Linux 6.6 verzija z daljšo podporo (LTS), bo to možno še več let. V najnovejši verziji so podporo upokojili preprosto zato, ker ni več vzdrževana in ni najti razvijalcev, ki bi to počeli. To je razumljivo, saj je zadnji procesor Itanium 9700 Kitson izšel leta 2017, ko je bila prevladujoča litografija še 32-nm.
Da so Itaniumu šteti dnevi, je bilo jasno že pred desetletjem. Intel je leta 2013 sporočil, da se razvoj novih funkcionalnosti za arhitekturo ukinja. Zadnji procesor je nato prispel leta 2017. Leta 2020 je Microsoft prenehal posodabljati Windows Server zanje. Resnični vzrok za neuspeh platforme pa je AMD, ki je izdal 64-bitno arhitekturo, ki je ohranila združljivost z 32-bitnimi programi, česar Itanium ni omogočal. Danes je arhitektura, znana kot amd64, prevladujoča in jo seveda podpirajo tudi Intelovi procesorji.
Itanium je torej spet umrl in verjetno bo še kdaj. Navsezadnje ga Hewlett-Packard Enterprise še podpira in bo tako tudi ostalo vsaj do leta 2025. Prihodnosti pa gotovo nima več.
To je razumljivo, saj je zadnji procesor Itanium 9700 Kitson izšel leta 2017, ko je bila prevladujoča litografija še 32-nm.
To da bi bila leta 2017 prevladujoca litografija 32 nm seveda ni res. Kittson (ja, z dvema t-jema) je samo malenkost hitrejsi Poulson (iz leta 2012, kamor 32 nm proces dejansko sodi), ob katerem prakticno vse generacije Skylake rehashev izgledajo kot prava tehnoloska cudesa.
32 nm litografija Kittsona pac zato, da ni bilo treba zapraviti dodatnega denarja, clock bump pa da je nominalno "boljsi" od prejsnje generacije in je bilo s tem zadosceno zavezi HPju da bo sledila se ena generacija.
Resnični vzrok za neuspeh platforme pa je AMD, ki je izdal 64-bitno arhitekturo, ki je ohranila združljivost z 32-bitnimi programi, česar Itanium ni omogočal.
Jim Keller in sodelavci so takrat dejansko postavil mogočen mejnik. Z Itaniumom pa so se pri Intelu itak predolgo ukvarjali.
Zanimivo dejstvo je, da je MS razvijal windowse za x64 na suho in ko je AMD dostavil prvi HW se je stvar dejansko zbootala v prvo. To je bilo še takrat ko so v MSju med sabo tekmovali različni codebase-i Windowsov...
Zanimivo dejstvo je, da je MS razvijal windowse za x64 na suho in ko je AMD dostavil prvi HW se je stvar dejansko zbootala v prvo. To je bilo še takrat ko so v MSju med sabo tekmovali različni codebase-i Windowsov...
Malo sem poguglal. Internet pravi, da se paralelizem na nivoju instrukcij ni izkazal za dobro idejo.
Itanium failed because VLIW for today's workloads is simply an awful idea. Donald Knuth, a widely respected computer scientist, said in a 2008 interview that "the "Itanium" approach [was] supposed to be so terrific--until it turned out that the wished-for compilers were basically impossible to write."
VLIW: Very long instruction word refers to instruction set architectures designed to exploit instruction level parallelism.
Zanimivo dejstvo je, da je MS razvijal windowse za x64 na suho in ko je AMD dostavil prvi HW se je stvar dejansko zbootala v prvo. To je bilo še takrat ko so v MSju med sabo tekmovali različni codebase-i Windowsov...
Zakaj se ne bi zbootala, če je združljiv z x86?
In to je razlog, da se je prehod na x64 vlekel desetletje.
Itanium je bil zanimiv znanstveni poskus. To so bili še časi, ko so se pri intelu pravi znanstveniki še ukvarjali tudi s čisto teoretičnimi stvarmi, in potem dali ven tudi nek hw. Danes vprašanje kolk je še tega. Pač je failal, nič zato, poskusili so. Sigurno je bilo neko obdobje ko je zgledalo kot da bo to prihodnost.
Itanium je bil zanimiv znanstveni poskus. Pač je failal, nič zato, poskusili so. Sigurno je bilo neko obdobje ko je zgledalo kot da bo to prihodnost.
Nekaj let nazaj sem bral neke mailing liste, da se je že zelo zgodaj vedelo da je Itanium fail in da VLIW ni praktičen. S projektom se je šlo naprej samo zaradi politike.
Intel je nategnil HP, da so le ti ukinili lastno arhitekturo PARISC pa še DEC Alpha, ki so ga dobili z nakupom Compaqa.
Sigurno bi na nekih mailing listah našel isto tudi o x64.
Tudi o x64 je že takrat razmišljal intel, pa ni bil zaželjen ker bi zaradi x86 pogodb le tega morali licencirati tudi AMD-ju in drugim takratnim izdelovalcem x86 čipom. Torej še ena politična točka za Itanium, njegovega ISA ni treba deliti s konkurenco.
Malo sem poguglal. Internet pravi, da se paralelizem na nivoju instrukcij ni izkazal za dobro idejo.
Itanium failed because VLIW for today's workloads is simply an awful idea. Donald Knuth, a widely respected computer scientist, said in a 2008 interview that "the "Itanium" approach [was] supposed to be so terrific--until it turned out that the wished-for compilers were basically impossible to write."
VLIW: Very long instruction word refers to instruction set architectures designed to exploit instruction level parallelism.
Paralelizem na nivoju instrukcij obstaja in jo CPU tudi izkoriščajo na polno, da pohitrijo svoje delovanje. Se pa principa, gledano IA-64 vs x86/x64, kako to pohitritev doseči vseeno razlikujeta do neke mere. Iskanje paralelizma in posledično pohitritev se lahko postavi na različne nivoje. Od programerja, pa do neke enote na CPU, ki stalno pregleduje, če lahko izvede še kakšno instrukcijo, ki je neodvisna trenutnim in ne potrebuje čakati na rezultat instrukcije, ki se trenutno izvaja. Tudi izkoriščenost računskih enot na CPU z večnitnostjo. To imata oba, pa tudi nekatere druge arhitekture. Večino programerjev načeloma ne zanima kako se ta paralelizem izkorišča, bolj kot se ne rabi s tem ukvarjati, bolje je za njega. Če lahko vročo žerjavico potisne drugemu, nekemu arhitektu na CPU nivo, super. Pa da je čim bolj transparentno in čim bolj hitro za njega, tem bolje. Prestavljanje kompleksnosti izkoriščanja instrukcijske paralelnosti na arhitekturni nivo CPU je super, s stališča programerja, za načrtovalce CPU malo manj. Njim to pomeni večjo porabo tranzistorjev za te namene in večjo porabo energije, da odnašajo rit programerjem. Nek fused multiply add (FMA) imata oba, ampak to je najnižje jabolko, ki se ga da obrati in ne stane veliko. Prevaliti precej kompleksnosti iskanja instrukcijske paralelnosti na en del v verigi, v tem primeru na pisce prevajalnikov, se ponavadi izkaže za precej dvorezen meč. Tako kot je ugotovil zgoraj. Se je vseeno potrebno naučiti nekatere stvari na novo, sploh če se hoče stvari izpeljati čim bolje. To je povezano s financami, kadri in na koncu koncev z uporabniki. Če je končen uporabnik nek HP, ki ima interes, da z vloženim denarjem prihodi kakšno konkurenčno prednost, se bo investiralo. Če te konkurenčne prednosti ni in jo tudi ni na vidiku, se slej kot prej zgodi, da se neha investirati. Ne tako dobri prevajalniki so tu verjetno še majmanjši problem.
Malo sem poguglal. Internet pravi, da se paralelizem na nivoju instrukcij ni izkazal za dobro idejo.
Itanium failed because VLIW for today's workloads is simply an awful idea. Donald Knuth, a widely respected computer scientist, said in a 2008 interview that "the "Itanium" approach [was] supposed to be so terrific--until it turned out that the wished-for compilers were basically impossible to write."
VLIW: Very long instruction word refers to instruction set architectures designed to exploit instruction level parallelism.
Paralelizem na nivoju instrukcij obstaja in jo CPU tudi izkoriščajo na polno, da pohitrijo svoje delovanje. Se pa principa, gledano IA-64 vs x86/x64, kako to pohitritev doseči vseeno razlikujeta do neke mere. Iskanje paralelizma in posledično pohitritev se lahko postavi na različne nivoje. Od programerja, pa do neke enote na CPU, ki stalno pregleduje, če lahko izvede še kakšno instrukcijo, ki je neodvisna trenutnim in ne potrebuje čakati na rezultat instrukcije, ki se trenutno izvaja. Tudi izkoriščenost računskih enot na CPU z večnitnostjo. To imata oba, pa tudi nekatere druge arhitekture. Večino programerjev načeloma ne zanima kako se ta paralelizem izkorišča, bolj kot se ne rabi s tem ukvarjati, bolje je za njega. Če lahko vročo žerjavico potisne drugemu, nekemu arhitektu na CPU nivo, super. Pa da je čim bolj transparentno in čim bolj hitro za njega, tem bolje. Prestavljanje kompleksnosti izkoriščanja instrukcijske paralelnosti na arhitekturni nivo CPU je super, s stališča programerja, za načrtovalce CPU malo manj. Njim to pomeni večjo porabo tranzistorjev za te namene in večjo porabo energije, da odnašajo rit programerjem. Nek fused multiply add (FMA) imata oba, ampak to je najnižje jabolko, ki se ga da obrati in ne stane veliko. Prevaliti precej kompleksnosti iskanja instrukcijske paralelnosti na en del v verigi, v tem primeru na pisce prevajalnikov, se ponavadi izkaže za precej dvorezen meč. Tako kot je ugotovil zgoraj. Se je vseeno potrebno naučiti nekatere stvari na novo, sploh če se hoče stvari izpeljati čim bolje. To je povezano s financami, kadri in na koncu koncev z uporabniki. Če je končen uporabnik nek HP, ki ima interes, da z vloženim denarjem prihodi kakšno konkurenčno prednost, se bo investiralo. Če te konkurenčne prednosti ni in jo tudi ni na vidiku, se slej kot prej zgodi, da se neha investirati. Ne tako dobri prevajalniki so tu verjetno še majmanjši problem.
Problem z paralelizmom je v tem, da je sodoben workload, razen v redkih primerih, preveč nepredvidljiv, da bi lahko zadevo izkoriščal na tako visokem nivoju. Če imaš dobro optimizacijo na procesorju, da potegne paralelno čim več inštrukcij, potem laufa, ker procesor še vedno deluje na nivoju inštrukcije. Problem VLIV koncepta je, ker je celotna arhitektura zasnovana za dolge nize inštrukcij in škripne, če prevajalnik ne more sestaviti takega niza in pač šopa procesorju individualne ukaze. Pri nepredvidljivih zaporedjih pa tako ali tako ne moreš sestavit konkretnega VLIVa.
Največji problem Itanium arhitekture ni v EPIC arhitekturi ali VLIV konceptu ampak v tem, da je praktično fental vse RISC arhitekture na nivoju osebnega (in poslovnega) računalništva. Itanium je ubil PA-RISC, DEC Alpha, SPARC in efketivno SGI MIPS arhitekture. Dejansko sta preživela samo ARM in RISC-V.
Ostali pa smo na dveh variacijah x86 in x86-64 arhitekture.
