Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
prosím nepřebírejte tyto PR účelové lži...
Intel to Oracle: That’s Okay, We’ll Have a Great Itanium Party Without You:
http://newenterprise.allthingsd.com/20110323/intel-to-oracle-thats-okay-...
Chip Shot: Intel Reaffirms Commitment to Itanium
http://newsroom.intel.com/community/intel_newsroom/blog/2011/03/23/chip-...
a reakce HP:
http://www.bloomberg.com/news/2011-03-23/hp-calls-oracle-s-itanium-move-...
Uvědomte si, že je to vývoj, který intel za drahé peníze prodává a následně až se to osvědčí implementuje do x86, nehalem už umí mnoho více, jenže jde o OS, prostě Win7 neumí vše využít, proto Unix. Linux od otho utekl, protože než linux komunita něco vyvine, je zde nový CPU, navíc náklady na implementaci Linuxu jsou na BCS moc vysoké a firmy dnes hledí hlavně na TCO.
Ano, Oracle bych chtěl asi prodat nějaké ty Sparcy, které koupil i se Sunem. Bohužel se obávám, že kromě specifických aplikací pro Niagaru nejsou Sparcy v současné době pro Itanium příliš velkou konkurencí. Na druhou stranu bych si tipnul, že je to právě Oracle, jehož software "se prohání" po většině Itaniových serverů prodaných v současné době, takže to pro Intel nebude zpráva, kterou můžou jenom tak přejít, je to celkem drsný konkurenční boj.
Přesně, mimochodem přes 50% instalací Oracle běží právě na Itaniu. Pak hlavně nepřehlédnout kdo z HP byl odejit právě do Oracle:o)).
itanium konci, nebot jej pohrbil RedHat ... to bohate staci ! ... v soucasne dobe enterprise linux No1 ... na Itaniu2 se prohani vyhradne HP-UX a Linux ... sam jsem nekolik linuxu na itaniu2 navrhl a nainstaloval ... a ano, bezi tam vetsinou prave oracle i u zakazniku + rekneme z 20% i neco jineho ...
Co se vykonu tyce, Sparc je na tom historiky velice spatne.
HP-UX je prumer, spise slabsi, IBM Power jsou na tom velice dobre ... ale obavam se ze stara Alpha nataktovana na dnesni moznosti by jim dala naprdel vsem ;-))
... ze se nam ten pisecek s CPU ale svrknul co ;-))
MIPS mrtvy (zaslouzene), PA-RISC migroval na Itanium2, Alpha nejlepsi CPU vsech dob, mrtev, ... looser X86 se tak pozvedl, ze je dnes svetovou jednickou ;-)) ... potencial AMD ne veyuziva ani z 1/10 .... na vysluni se nam cpe slaboucky ARM, ktery zvysuje vykon ;-))
To by mě zajímalo proč je MIPS mrtvý zaslouženě, měl jsem za to, že je to dobrá architektura. A ARM bych už jako slaboučký nehodnotil.
a proc by to jako mel byt itanii?? ze tam nebudou nevejsi windows nebo nebudou cetrifikovany linuxy??
pokud me pamet neklame, tak s itanii nejdriv prislo hp jako nahrada za jejich pa-risc, pak teprve prisli za intelem a zacali spolupracovat, to ze to pozdeji prevzal cely intel na sebe je jinaci pohadka ...
to jsou hlavne cpu do mainframu, kde se za behu a bez restartu os naprosto bezne vymenuji cpu nebo ram, procesor samotny umi elektricky odpojit vadne casti aby se proste nonstop jelo dal ...
jen hp tam ma tri operacni systemy, a to hp-ux . openvms a nonstop os.
a jsou na nej i jinaci os, ktere vetsina lidi ani nezna, a jejich koreny sahaji az do doby kdy nebyli ani na svete :)) treba takovy nec acos4 ...
takze do doby nez v mainframech itania vymeni jina archytektura, treba ibm power, tak se budou stale prodavat, sice ne v tak velkym mnozstvi ale budou ...
kazdopadne skoda, ze se itania neprosadila a nenahradila x86 ... muzeme za to podekovat amd za uvedeni jejich 64bit rozsireni pro x86 :))
prvni veta mela byt "a proc by to mel byt konec itanii"
Videl jsem specifikace architektury IA64 a uprime dekuji AMD ze ten nesmysl potopily. Co se nahrady procesoru x86 tyce, navrhuji vzit AMD64 a odriznout z nej vsechno z predchozich x86, nechat jenom ty rozsireni. Samozrejme doslova to nejde, ale uz 32bitove rozsireni x86 je mnohem kvalitnejsi nez ten legacy bordel pod tim a AMD64 pokracuje v trendu.
(V praxi to samozrejme vyhraje ARM. Otazkou je jen za jak dlouho.)
něco na tom je, vzhledem k tomu ale jak jsou rozšíření doslova vystavěna na legacy základech, tak to docela nejde - z které strany bys například ořezával 64-bit registry (EAX, EBX...) aby už nepodporovaly 32,16-bit, ale aby se do nich stále vlezlo 64-bit? :-D
Zajímavá optimalizace by mohla vzejít od překopání opcodes, těch surových co vylezou z kompilátoru, ne těch interních mikroinstrukcí. Protože ty nejhezčí jedno nebo dvoubajtové jsou zaplácané skalární 8 a 16 bitovou aritmetikou, zatímco 32/64bitové a vektorové mají opcode dlouhý. Přerozdělením opcodes ve prospěch používanějších instrukcí by se zmenšily binárky a do kódové cache by se vešlo více kódu, a máme zrychlení bez námahy.
... a spousta tech "kratkych" opcodes by se mohla vyhodit uplne. Nicmene ja mluvil napr. o tom ze by se se vsemi registry zachazelo stejne a zrusili by se ty zverstva typu ze nemuzete adresovat libovolnou dvojici 16bitovych registru ... (zatimco 32bitovych a 64bitovych ano). Taky by se mohla brutalne zjednodusit segmentace, samozrejme vyhodit realny a V86 mod ...
"kazdopadne skoda, ze se itania neprosadila a nenahradila x86 ... muzeme za to podekovat amd za uvedeni jejich 64bit rozsireni pro x86 :))"
Vinit konkurenci z vlastních neúspěchů a neschopnosti něco prosadit je opravdu hloupé
Ono hlavně Itanium není pro x86 moc konkurence - na jedno jádro je horší v absolutním výkonu i performance-per-watt, má složitější optimalizace kompilátoru a nemá takovou tu x86 běhovou variabilitu "co tam pustím jede rychle" (má vůbec out-of-order execution?), jediný smysl má v lepším škálování platformy jako takové.
No jenže o výkon na jádro zd evůbec nejde, zde se hlavně jedná o I/O. A to Itanium(s ním spojený chipset od HP) je podstatně výkonější, nemluvě o množství linek k I/O jako takovému.
Mne spíše zarazilo licencování HP-UX, na jádro to vychází na nějakých 25k Kč. Nepříde mi to jako drahé.
I/O? Jakože k Itaniu připojené disky nebo síťovky fungují rychleji? :-) Zajímavé...
Trocha ranní osvěty: o co v Itaniu jde a o co ne na modelových situacích. Mějme pro zjednodušení Itanium a x86 procesor se stejným počtem jader a stejným výkonem na čip (což plus mínus odpovídá realitě), mějme databázi, která jde clusterovat, která se celá vejde do paměti (protože Itanium opravdu s diskem rychleji nebude pracovat rychleji, než x86) a pojďme se podívat na nějaké aplikace.
Situace první - máme udělat infrastrukturu pro wikipedia.org, která se dá charakterizovat tím, že je enormní množství procesů, které čtou z databáze a malé množství přispěvatelů. Toto se dá krásně (a levně) řešit clusterem x86 strojů, které mají všechny stejný obraz databáze v paměti, takže je jedno, který server obslouží přistupujícího čtenáře. Zápisy se budou dělat tak, že jeden nod clusteru přijme požadavek a pak jej rozešle po interní síti všem nodům. Protože je zápisů málo, není s tím problém, navíc nemusím celý cluster "zamykat" při zápisu, protože nevadí, když se změna článku projení na ostatních nodech později (myslím v řádu sekund) a asynchronně.
Situace druhá - navrhněme infrastrukturu pro systém vedení klientských účtů v České spořitelně. Protože je jenom málo lidí, kteří se chodí kochat stavem účtu a žádnou transakci neprovedou, můžeme předpokládat, že klientů zapisujících do databáze je většina, navíc operace zápisu musíme provádět synchronně nad celou databází, takže bychom v případě clusteru museli provést zamčení tabulky, počkat, až všechny nody zamčení potvrdí, zapsat na všech nodech, počkat na potvrzení zápisu a odemknout. Nasazení clusteru se zdá být po takové první úvaze dosti problematické, možná by to šlo nějak obejít, ale asi bude jednodušší a v konečném důsledku i levnější (nemusím upravovat software a vymýšlet finty, jak omezit interní komunikaci v clusteru) začít uvažovat nad single-image (jedna sdílená paměť) serverem s větším počtem procesorů - protože čtyři CPU tu databázi (v našem případě prakticky jen práce s pamětí) opravdu neutáhnou. Největší slabinu x86 na tomto poli už máme dnes z krku - tou byl "sběrnicový" přístup do paměti, dnes už jsou procesory NUMA, ale stejně pořád návrh x86 Opteronů i Xeonů nepočítá se stavbou serverů s více procesory, než 8, resp. dnes (tuším) už jenom 4. To se nám pro naše použití nehodí do krámu, sáhneme teda po šestnáctičipovém serveru s Itaniem.
Co dělá platformu Itanium atraktivní není I/O, ale rychlá komunikace (propustnost) mezi jednotlivými CPU, resp. jim příslušných (NUMA) bloků paměti. Problémy se zamykáním při zápisu musíme řešit taky, ale na písečku uvnitř procesoru jsou limity (zejména latence) řádově jinde, než na síti.
Ano i ne.
AMD je na tom lip, jen jaksi nikdo nedela tak nslapane desky ... ano taky jsem stavel servery s 8CPU s kupou jader a 64GB ram na itaniu2.
Ale Itanium2 nema NUMA.
Dale o te sbernici uz to take neni tak docela pravda, pryc je doba, kdy intel s kazdym CPU natvrdo delil sbernici poctem CPU ... a tak kdyz se to nevyuzivalo, tak to slo do kytek, neb ze 100MHz pri 4 CPU jsem mel razem dat. tok 25MHz (x32bit ... ach) ... prvni SWITCH arch. prinesla prave AMD u svych 64bit CPU ... je to modifikaci sbernice Alphy a NUMA z MIPS ... tedy az na ty slavne garantovane instrukce by na AMD sel postavit lepsi server ... jina vec je, ze se nedela ..
Ani nahodou, Itanium2 nema ani na I/O ... treba AMD s jeho HT sbernici je daleko pred (Vsak je to to taky sbernice z 64bit Alphy)
Itanium2 ma ale jednu velkou vyhodu a tou je garance instrukci, ze kdyz se neco ma provest, tak se to taky provede a kdyz ne, tak opakuje ... coz u x86 neplati ... teda pry uz to tam je, nebo se alespon chysta
... ta sance, ze x86 neco neprovede a bude se tvarit jako ze to proved sice neni nikterak casty jev, spise velice ojedinely, ale ta sance tam je ... pravda, riziko je tak male, ze je mozno jej ignorovat ... ale hold nekdo si to dovolit nemuze ...
ale to ja amd z tohoto ani nahodou neobvinuju, sam su aemdeckar, amd mam od dob 486dx4 s jedinym uletem v podobe celeronu 266@533 ...
ale musis uznat, ze jak vysel athlon tak se za par mesicu frekvence zvysila 2x a x86 rychle dobehli vykonem riscovy cpu, to 64bit rozsireni uz byla posledni kapka ...
v prvnich itaniich byla hw emulace x86, sice nevykona ale byla, do doby nez by se aplikace prepsali na ia-64, microsoft pro to udelal win xp a bylo by jen otazkou casu, nez by se opustila x86 s celou jeji kompatibilitou az do praveku ...
A co by to kromě složitého kompilátoru přineslo?
Pokud myslíš, že x86 je jediná zpětně kompatibilní platforma, tak doporučuju podívat se třeba na takový ARM, který je zpětně kompatibilní až do roku 1985, MIPS dokonce do roku 1981 a nikdo si tady nestěžuje, jak by byl svět lepší, kdyby jeho Nexus S konečně odhodil břímě 25 let děděné instrukční sady a fungoval pak mnohem lépe. Pokud se bavíme o pre-32bit režimech u x86, tak si vem, že taková 286 měla cca 134000 tranzistorů, tzn. i kdyby se měla reimplementovat v dnešním procesoru celá, tak je to přibližně 0,0006% jednoho Buldozer modulu - tzn. opravdu hrozné břímě.
No jo, jenze X86 je skutecne zmrsena arch od pocatku ;-))
vetsina RISCu ne jen ze byla navrzena lepe, ale pozdeji bud pribalovali, nebo dkonce vse zahodili a dali pak na jednu desku 2 CPU ... 32bit a 64bit
Lidi, uvědomte si, že RISC je způsob myšlení sedmdesátých a osmdesátých let minulého století. Tehdy lidi přestali spoléhat na assembler a zdálo se být výhodné dostat malou komplexnost ALU a posunout nějakou práci do kompilátoru. Zjednodušit návrh, zmenšit čip, zvýšit frekvence, odvést stejnou práci. Jak tehdy vypadal procesor? Celý křemík zpracovával jednu instrukci a po jejím dokončení si vzal další z paměti (žádná cache!). Toto byl výchozí stav, který se měl optimalizovat. Ale kde jsme skončili? Megabyty cache, pipelining, hyperthreading a jeho variace (Niagara!), out-of-order execution, spekulativní provádění kódu, SIMD jednotky, vektorové procesory (zapojení GPU). Kde je původní motivace, kde je jednoduchost návrhu? Nikde, není, skončila už v osmdesátých a devadesátých letech, kdy se návrh zesložitil výše uvedenými technikami. Větší počet tranzistorů na vyšší frekvenci prostě dává vyšší výkon bez ohledu na instrukční sadu. Proč? Dekódování a provádění instrukce byl problém v osmdesátých letech - tehdy procesor nedělal nic jiného, dnes procesor řadí, vyhodnocuje konflikty, "dozrává" instrukce prováděné mimo pořadí, spekulativně větví, zahazuje špatné větve, kešuje, bla bla, samotné provedení (mikro)instrukce je jenom malá část rutiny.
Pořád lepší než koule na noze x86, která sahá až někdy před 1972, ano vychází z návrhu terminálu CTC a následné realizace v podobě i8008, to byl 8-bit...
Když se tak podívám na architekturu ARM, tak je to obrovský rozdíl oproti x86, čistější návrh a spousta vychytávek jako například podmínečné vykonání téměř pro každou instrukci nebo podstatně více univerzálních registrů atd.
Univerzálních registrů má ARM i x86_64 stejně - tedy 16, aspoň co píše Wiki. Jinak uznávám, že zpětná kompatibilita x86 je rozsáhlejší, než má MIPS nebo ARM, ale stejně to není problém - ty staré režimy jsou prostě vzhledem ke konstrukci celého čipu extrémně jednoduché a kdyby to problém byl, daly by se například trochu složitějším BIOSem prostě emulovat softwarově - stačí kousek DOSBOXu.
Implementace zastaralého CPU je jedna věc, sladění celého systému a jeho zrychlení je úplně něco jiného.
Např.: On average, the 80286 had a speed of about 0.21 instructions per clock. Taky neměl žádnou pipeline...
Ano, 286 a hlavně 386 byly konstrukčně problematické a z tehdejšího i dnešního pohledu neefektivní ve srovnání se soudobým RISCem, taky následovala zlatá doba RISCových řešení, kdy vlastně vznikl názor, že CISC už je na nic. 486 (pipelining) byla dobrý krok, ale přišla příliš pozdě, aby náskok dohnala, Pentia taky s menším odstupem. Mezitím se postupně RISCové procesory zesložitily podobně jako x86 prakticky stejným způsobem (popsaným výše) a někdy nástupem prvních Athlonů se efektivita srovnala, zejména protože Athlon dohnal leadery RISC trhu použitými technologiemi.
Ono hlavne dnesni x86 vubec CISC nejsou. Spis pripominaji prekladac instrukci z x86 na interni instrukcni sadu spojeny s RISC jadrem ktere tu interni sadu provadi ... a takhle je to uz od Pentium Pro, resp. AMD K5.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.