Optimální minimum? Co to je?

Optimální minimum RAM pro OS - Taková minimální kapacita RAM, při které se dají komfortně provozovat základní činnosti na PC (tj. prohlížení internetu, práce s dokumenty, prohlížení fotografií) zároveň, v rozsahu, které běžně stačí domácímu BFU či sekretářce ... Windows XP se dají rozběhat i s 32MB RAM (funkční minimum), ale užitné minimum je 256MB RAM a optimální minimum je 512MB RAM. ... osobní názor.

Ony ty fíčury, které jsou patrné na K8 a které teď "kopíruje" Intel se týkají spíš frontendu, vnější tváře cpu a spojení s deskou, pamětí atd. Ale AMD teď musí zapracovat na vnitřku, na tom, co počítá, aby dokázalo dostat výkon na jendom vlákně výš... Jádro K8 není o moc změněné proti K7 a to zas, i když v menší míře navazovalo na K6 (čili NexGen 686). Tak uvidíme, s čím přijdou teď. Nemusí to být úplně od podlahy, když můžou dobře posloužit prvky z K7/8/10, tak proč je nevyužít. Ale nějaké novoty tam uvnitř musí přijít.
 
Jsem zvědav, jestli to o "nové architektuře" se u Nehalemu vztahuje jenom na paměťový řadič, změnu IO rozhraní a tak, nebo tam budou nějaké výraznější změny uvnitř... Zatím to vypadá na obdobu K8 - to znamená jádro z předchozího cpu (K7, respektive Core 2) a nové rozhraní.

Hallooo Nevies CITAT!!! Najnovsie OS, aka VISTA. a nehovor tu o XP

A proč by AMD do té doby nemělo dožít? Hlášky typu že Intel má výkonnější procesory mi přijde celkem směšná, když až nyní intel opravil u svých 45nm čtyřjader kritickou chybu, která je posílala rovnou do popelnice. A zkuste ty opravené kousky sehnat, nejen že Vás překvapí dokonalá dostupnost, ale cena ještě více :-)

optimální minimum je konfigurace co skoro nic nestojí a slušně to běhá. Pro XP bych to viděl na PIII 800, 512RAM a neintegrovanou grafiku takřka jakoukoli od 8MB paměti. Sám mám na toulání MIVVY s 1GHz VIA procíkem a je to zcela dostačující na remote desktop, internet a textové srandičky. Video zvládá taky. Myslím, že jsou to funkce pro 60% uživatelů dostačující. Na hry máme PC s Core Quad a 9600 gforcem. Na druhou stranu jsou ceny nových, poměrně výkonných PC posazeny velmi nízko a za cca 10tis lze koupit slušné pracovní pc i se systémem a levným LCD. PC stavím na míru už roky a asi tak to funguje. To minimální PC beru za cenu do 1500,- bez monitoru např pro důchodce. Jinak to není zrovna perspektivní investice :-))

PEACE ... takhle jsem to nemyslel. :) Nenavážel jsem se do Vist. Pouze jsem se snažil přinést odpověď na první příspěvek. Příklad s XP jsem použil, protože s Vistama nemám zkušenosti na slabších PC. Chtěl jsem ukázat rozdíl mezi minimem a optimálním minimem a u XP zrovna asi vím jak to je, protože s nimi zkušenost mám. :)

fotoba: pokud si dobre pamatuju, ... tak AMD pouzilo z Alphy jen sbernici (vic pouzit ani nejde, jde o uplne jinou architekturu). Alpha s technologiemi, patenty, a casti vyvojoveho tymu presla pod Intel (zbytek vyvojovaho tymu (co intel nechtel) preslo k AMD).
 

Jinak Intel je pochopitelne o krok dale, ma pripravenou a odladenou plnohodnotnou 64bit architekturu (IA64), ktera je pochopitelne velmi vhodna i pro desktopy (jadro IA64 (nepocitaje L3cache) ma asi ctvrtinu tranzistoru co x86 procesor). Pokud tedy bude vule vyrobcu SW (predevsim OS) prejit na novou architekturu, tak je cesta pripravena. Osobne myslim ze 25let zastarale x86 architelture uz trochu odzvonilo ...

to nene:
snivaj dalej, nic take v dohladnej dobe nebude - je to takmer nerealizovatelne... Predstavujes si to ako "Hurvinek valku". Nieco to svetlo totiz musi generovat, nieco lomit a to do procaku nevrubes aj keby si co robil...

Proc by nemelo AMD prezit ?

Treba proto, ze je pravidelne v cervenych cislech (tzn celkem slusne prodelava), kdezto Intel ma pomerne velke zisky - on totiz nevyrabi jen pocitacove procesory, ze.

Kdezto pro AMD jsou CPU tim jedinym, co je dokaze udrzet nad vodou - a to v pripade ze nemaji nic cim by mohli vykonove konkurovat Intelu dlouhodobe nejde.

AMD se tak dostalo do takovych cenovych relaci, kdy uz se snad nemuze ani vyplacet ty procesory vyrabet - novy procesor za 500 Kc kvuli tomu, aby byly konkurenceschopne. Kdyz uz nenabizi vykon, musi nabidnout extremne nizkou cenu. A timpadem AMD nema nic, na cem by mohla vydelavat (neco jako jsou Itania)

Ano, ale to je len komunikacia medzi nimi, cize zefektivnenie rozhrani. Ale do vnutra procesora to jednoducho nedas...

fotoba:

Co já vím, tak to, že Athlon = převlečená Alpha, je pouhá urban legend. Je pravda, že AMD má z Alphy nějaké vývojáře a bus u K7, plus třeba návrh celkový jádra je podobný (kombinace a počty fpu, alu). Ale vývoj K7 jde z K6... ovšem minimálně fpu část byla velice posílena. V situaci, kdy technologie vzešlé z Alphy schlamstl Intel to není bůhvíjak překvapivé, ne.

Máš pro to tvrzení nějaké důkazy?

Tak do optiky sa nikto tlacit nebude, minimalne pokial nenarazime na limit kremikovych tranzistorov. Komunikacne rozhranie je totizto relativne rychle, co spomaluje najviac pc su dnes velke rozdiely v rychlosti CPU vs. RAM a RAM vs. HDD.

2 ivan2: Itanium je prakticky mrtve, pretoze pada na spatnej nekompatibilite s 32 bitmi. A koniec x86 v najblizsich rokoch tiez neocakavam, pretoze dnes je tato platforma natolko rozsirena ze prejst zo vsetkymi sucasnymi programami na inu platformu je prakticky nemozne z praktickeho hladiska - clovek by v prechodnom obdobi musel mat v pc CPU kompatibilne s x86 a zaroven nejakou novou architekturou co by so sebou prinieslo viac problemov nez uzitku. Navyse sa pozri akym tempom sa prechadza na obycajne 64 bitove programy a akym tempom su ludia ochotny prejst z windowsu na linux. No a s prechodom na uplne novu architekturu by to bolo 100 krat horsie.

ivan2: No já teda nevím, ale co do úspěšnosti Itania se zatím zdá, že kdyby to byl produkt AMD, tak AMD už dávno zkrachovalo ;) Nepletu-li se, je to ten procesor, o kterém ve 2. polovině 90. let prohlašovali, že ovládne počítače a vytlačí i x86 i RISC procesory. Pak se odhady prodejů snížily na polovinu, pak zase na polovinu, pak ještě na polovinu...

ptc: AMD prodělává hlavně kvůli tomu, že odepisuje peníze za nákup ATi, předtím byli v zisku. Pravda, s tím nákupem si zavařili, víc problémů než čekali a přínosy se neustále oddalovaly... nicméně momentálně se alespoň zdá, že se situace zlepšuje- ATi konečně zas vydělává, tříjádrové procesory by mohly mít alespoň marketingový úspěch, konečně mají i své vlastní pořádné čipsety, apod.
Samozřejmě jedno je jasné: příští generace procesorů AMD nesmí být propadák, jinak mají problém.

Co se týká procesorů za 500Kč, tam je příčina i trochu jinde: pokud před dvěma lety stál procesor 150 dolarů, bylo to kolem 4500Kč, zatímco když dneska stojí procesor 150 dolarů, není to ani 2500Kč.

A jak tak koukám, tak taky tvrdíš, že Itanium je ve skutečnosti Alpha, teda fakt sorry, ale to těžko, Itanium je úplně jiná liga (VLIW), a mimochodem, to, že mu redaktoři The Inquireru říkají Itanic má asi stejnou vypovídající hodnotu jako to, že AMD se u nich jemnuje "Chimpzilla", MS "The Vole" a Apple "Cuppertino" nebo taky Fruit-themed toymaker. Jsou to šprýmaři.

Fotoba:
Takhle plus mínus vypadají všechny cpu (P6, core, Via CN...)! Navíc si všimněte jiných počtů jednotek, jiné je to s L1 cache. Takže, ano, oba procesory mají podobná schémata :)

Mimochodem, tahle podobnost je nejspíše způsobená tím, že oba týmy došly k názoru, že takovéhle uspořádání je výhodné... A hlavně takovéhle schéma o konkrétním technologickém provedení jader neříká takřka nic.

2 fotoba:
Co se tyka AMD tak +/- pravda i kdyz to samozrejme neni Alpha, ale novy CPU postaveny na technlogiich a napadech z Alphy, Mipsu (NUMA) a transmety (emulace x86)

Co se tyka Itania, tam nevim (itanium se nikdy ani nezacal prodavat), ale Itanium 2 je HP PA-RISC .... coz neni zrovna moderni a uz vubec ne vykonny CPU, rozhodne ne, pokud prez nej netece velke mnozstvi dat, jako vypoctovy CPU je to tragedie, louskani sifer je ne nem jeste pomalejsi nez na beznych desktopovych CPU srovnatelnych frekvenci a uz vubec ne cenove srovnatelnych. Mel jsem 600MHz Pa-riscs a na vypocty ve fortranu, co jsme pouzivali nestacil ani na intel PIII 1 GHz, test john the ripper taky projel Pa-risc na plne care.

Mimochodem ne nadarmo na Itanium 2 jede i HP-UX ... a to je tak zastaraly OS, ze by ho fakt uz nikdo neprepisoval a dokonce na nem bezi stare binarni programy z Pa-riscu, OS ale uz musi byt kompatibilni s Itaniem2.

Jo to co jsem rikal o vykonu patrilo PA-RISCum, Itanuim2 je na slaby vyp. vykon pamatovano velkym poctem ALU jednotek ... ale pomer cena/vykon hovori jednoznacne pro AMD64, nebot za cenu jednoho CPU, na kterem DB bezi pomaleji a vypocty o malo rychleji nez na AMD64, dohonim tim, ze dam ty CPU 2 a vykon je uplne nekde jinde a to nehovorim ani otom, ze 4x 4jadro vyjde jeste porad levneji.

Jinak propadakem vsech CPU, ktere nesazi na UNIX nebo Linux, je zkostanetly OS od M$, kde se tahne balast z x86 napsanych v assembleru, beztak tam jsou jeste porad 16bit rutiny z i386, takze na Itanium2 de fakto windows ani uspokojive nebehaji, je to uplne jiny OS, kupa veci se tam SW emuluje a h;lavne nejsou proto aplikace ani podpora HW (problem s drivery)
Prihlizel jsem 6x nasazeni Itania2 na windows a vzdy to zkoncilo fiasekm, ackoliv vsichni deklarovali, jak natom jejich SW bezi, tak nakonec z nich vypadlo ze to nemaji rozbehane nikde a vse tam funguje jako alfa release .... takze bud to ani nerozbehali, nebo rozbehali a padalo to a v nejlepsim pripade to fungovalo v omezene mire (nemelo to vsechny funkce) a jeste k tomu to bylo pomalejsi .... nez na x86.

Jo a abych jenom nehanil, HP-UX na Itanium2 bezi dobre ... ale tento OS bych nechtel ani zadarmo.

Jen pro upřesnění, ta emulace x86 není u AMD inspirovaná Transmetou (Crusoe přišel až později), ale když už tak Intelem - P6 architektura, používající pseudoriscové výpočetní jednotky a dekodéry, které pro toto jádro x86kód přeloží a zoptimalizují (out-of-order). Toto řešení je pak i u K6, K7, K8...

Jo, abych nezapomněl, tak už K5 používal x86 dekodér a uvnitř risc jádro - dokonce přímo architekturu AM29000, kteoru samo vyvinulo AMD (byla docela úspěšná, ale AMD ji muselo opustit, aby mělo dost kapacit pro vývoj výrobu x86 čipů).

>fotoba: Ze se nic nedeje, to bych s takovou jistotou netvrdil. Nezapominej, ze AMD je zadluzena az po usi a jsem si jisty, ze splaceni uroku jim slusne pousti zilou. Kdyby firma nemela par vlivnych mecenasu (napr. IBM) a vyrobcum pocitacu by se to nehodilo do kramu (kdyby tady byl jen Intel, jejich zisky by byly totiz urcite nizsi), tak uz by ji banky davno roztrhaly na kusy.

->ljelinek: dál co ? dál by AMD prodali výrobcům pečiva ?

2 ivan2: IA64 vhodná pro desktop? A nějakou další srandistickou hlášku tam nemáš? Požadavek na obrovské cache, nízké frekvence, absolutně nevyužitelný paralelismus (max. IPC 6 vs typicky desktopové IPC 1) a hlavně spoléhání na optimalizace kompilátoru, to jsou všechno věci, které dělají z Itania pro desktop úplně nepoužitelnou věc. Software se pro procesory optimalizoval naposledy v dobách assembleru, od té doby to jen upadá. Tak, jak vývojáři dlabou na 64bit, SSE, vícjádra, tak naprosto stejně by dlabali na Itanium.

->Eagle_not_registered Ano, proto se budou v budoucnu optimalizovat už jen procesory na software. Proč to dělat jednoduše když to jde složitě ;-)

Kdepak optimalizační uvažování je nesmysl z jakékoliv strany, je to jen berlička pro získání krátkodobého náskoku před konkurencí do doby než se objeví nová architektura nebo jen železo. Pro nové úlohy je třeba celé nové komplexy software+hardware.
Když nebudou programátoři optimalizovat o to dřív se objeví nové železo a nová architektura, což programátorům přidělá práce ještě víc. Viz výrobci her.
Pletu se ?

2 focivibi: Optimalizovat software ručně je ekonomicky strašlivě nevýhodné a odskáče to kdo jiný než zákazník. Je mnohem levnější zaplatit hodně dobře pár tisíc vývojářů a nasadit do hardware nové technologie (např. optiku), než platit miliony programátorů. Při dnešním trendu "hlavně to mít levně" není na softwarové optimalizace čas a komplexnost programů i přes použití OOP je děsivá - vnášení dalších potíží jako assemblerová optimalizace, multithreading, thread-safe funkce, exception handling a podobných věcí vede pouze k tomu, že už tak dost chybový SW se stane ještě chybovějším. Můj názor je ten, že o veškerou optimalizaci by se měl postarat programovací jazyk zaměřený na kvalitní programátorské techniky (např. C++) a kompilátor. Teď je to především na výrobcích CPU, aby vydali dobré optimalizující kompilátory, protože jinak jejich nové výrobky nebudou o nic rychlejší než ty současné a nikdo si je nekoupí.
A co se týče optimalizací a nových architektur - obecně dobrá optimalizace funguje na všechny procesory, protože všechny procesory jsou si velice podobné. Primárně by mělo být ale železo stavěno na "průměrný" kód, což je dnes neoptimalizovaný a, pokud s tím výrobci CPU něco neudělají prostřednictvím nových kompilátorů, i v budoucnu to bude neoptimalizovaný.

fotoba> rikas nesmysly,
IA64 znamena Intel Architecture 64, je soucasne zastoupen radou procesoru Intel Itanium 2.
Jedna se bezpochyby momentalne nejlepsi procesorovou architekturu, a je tez spolu s IBM Power to nejvykonejsi co existuje.
IA64 je kompletne nova architektura posavena na zkusenostech s PA-RISC, x86-CISC, a VLIW (v tu dobu zastoupena transmentou), prebrala pochopitelne to dobre i z EV7 a EV8, ale jde o neco jineho (je zalozeno na moderni architekture VLIW a technologii EPIC (EV7 je RISC).
K7 nikdy nemala mikroarchitekturu 21164, pouze FSB
AMD ma trvalu licenciu na FSB 21164, ale nikoliv na celou 21164
 

Eagle_not_registered : IA64 je co se tyce pomeru vykonu/poctu tranzistoru/spotreby/cistoty reseni je momentalne nejoptimalnejsi architektura, je pochopitelne vhodna i do dektopoveho ci dokonce mobilniho pouziti (viz podobna architektura transmenty).
Potreba vetsi cache neni nutna (resp jen ve smyslu obecne objemnejsiho 64bit kodu, tj. mozna o 30%), pochopitelne vetsi cache prinasi vetsi vykon, ale to plati i u x86, jenze IA64 ja na to lepe optimalizovana a dokaze ji lepe vyuzit (paralelismus). Navic cache je vyrobne jednodusii a energeticky mene narocna, je tedy vhodnejsi mit mene tranzistoru v jednoduchem a vykonne jadru, a vice v cache.
Ano sila IA64 je v paralelismu (resp v jednoduchem a vykonem jadru (jako RISC), komletnejsi instrukcni sade s mensi narocnisti na propustnost (VLIW, podobne jako CISC) a paralelismu (EPIC)), jenze ona to je prakticky jedina cesta jak nadale zvysovat vykon procesoru, a x86 je v paralelnim zpracovani silne nepouzitelna.
Ano IA64 hodne zalezi na optimalizaci kompilatoru pro danny typ procesoru (zatim jsou dva Itanium1 a Itanium2), jenze se jedna o optimalizaci kompilatoru, nikoliv programatoru v assebleru. To ze by nejaky programator neco optimalizoval primo v VLIW kodu je pochopitelne nesmysl, neuhodil jsi se do hlavicky?

2 ivan2: Čím víc se programový kód přibližuje samotnému vykonávání, tím je objemnější (v x86 se jedna instrukce dekóduje do několika (i desítek) microOPs). Ve VLIW jsi v kódu na ekvivalentu microOPs, a proto je kód větší. Větší kód vyžaduje větší cache, větší RAM, rychlejší cache, rychlejší RAM. Cache a RAM dneš už i na x86 značně limitují výkon svojí pomalostí. Další zpomalení by vedlo k ještě horším výsledkům.
Přestože by VLIW mělo zlepšovat IPC díky své znalosti hardwarové implementace a přímého schedulování na jednotlivé jednotky, v praxi naráží na problémy latence cache a hlavně RAM, které se dají velmi špatně předpovídat (procesor nemůže odhadnout, kdy bude v RAMce refresh, a blbě odhadne, jak se přesně řadič RAM vypořádá s naběhlými požadavky). Tyto problémy se běžně musí řešit i v x86 světě, kde ale scheduling může probíhat se zohledněním latence RAM.
VLIW má nevýhodu v tom, že je striktně cílená na jednu konkrétní hardwarovou implementaci - Itanium 2 se nezměnilo už asi šest let (od svého vydání), pouze zvyšují frekvenci a přidávají další jádra. Jakákoli změna čipu vede okamžitě k rapidnímu poklesu výkonu nebo dokonce nekompatibilitě kódu. To v masovém měřítku není přijatelné, protože to by procesory všech výrobců musely být úplně stejné a vyššího výkonu by se dosahovalo jen nárůstem frekvence. Jakákoli invence by zanikla.
Pomocí VLIW sice ušetříš na komplexnosti jádra, ale za to musíš mít perfektní kompilátor. Drtivá většina programovacích jazyků (rozuměj vše vyjma C++) dnes nemá optimalizující kompilátory. Ono často je i problém, aby kompilátor vůbec správně fungoval (viz např. Delphi).
Itanium je navrženo pro paralelismus, který se v desktopových úlohách nekoná. Typická desktopová aplikace dosahuje průměrného IPC = 1, tj. i dnešní IPC 3 (Athlon) a IPC 4 (Core 2) procesory jsou pro ně značně naddimenzované. Masivní paralelismus omezuje frekvenci, která je pro výkon silně sekvenčních desktopových aplikací klíčová. Výsledky testů dokazují, že dokonce i v serverových aplikacích Xeony prakticky dosahují výkonu Itanií 2, přestože nemají k dispozici tak velkou cache a jsou výrobně mnohem levnější a mají menší spotřebu. Využití tak masivního instrukčního paralelismu by znamenalo preferenci algoritmů, které jsou co možná nejvíce nezávislé - to už ale opět zavání přesunem odpovědnosti za výkon programu na programátora a to nemůže vyjma specifických úloh uspět.
Transmeta dojela právě na to, že se pokusila protlačit VLIW do běžného života - její výkon vzhledem ke spotřebě byl natolik špatný, že vyhrála klasická řešení Intelu a AMD.
Ćili ve výsledku je Itanium 2 dobré pro masivně paralelní výpočty, kde se dá kód přímo přizpůsobit hardware. Taková situace není ani v desktopu, ani v mobilní sféře. Dokonce i v klasickém serverovém prostředí je to jen omezeně. Pozor ale, aby se výkon Itania nezbortil s tím, jak masivně paralelní úlohy můžou zpracovávat grafické karty ;-).

Mě z toho vychází jediná možnost. Vícejádrovému (masivně paralelnímu) procesoru bude kvůli zachování univerzality předcházet obousměrný n úrovňový HW překladač z/do vyššího multiplikárě-interpretálního dynamicky kompilovaného jazyka.

Nejde si nevšimnou přesouvání smyslu jednotlivých softwarových předmětů do hardware už od osmibitů. (Třeba jednoduchý blitter) Pokaždé když vykrystalyzoval nějaký objekt (osvědčil se) byl po čase začleněn do HW. Zbývá tento evoluční proces uchopit, vytvořit metodu a pak nástroj.

Ale to lidem z oboru dojde až po vytvoření nezvládnutelného kopce Stanford "wizard" kódů pro paralely. Lidi v oboru takto iterují už od dob 4bit procesorů ;-)) nebo jim to stále nedojde a než dojde k vytvoření výše uvedeného, sluce vyhasne. hihi.

Sběrnice K8 a K10 je hypertransport, a u Nehalemu něco, co si Intel vyvinul sám. Takže mluvit leze tak maximálně o inspitraci nebo podobném řešení (podobné požadavky většinou rezultují v podobnou technologii...)

Ale tvrdit, že kvůli tomu jsou ty procesory valstně Aplhy... no, no... Teda spíš ne, ne.

Mimochodem to vašw 21264PC (nebo jak je to číslo) je pouze trošku ořezaná verze 21264 pro "levnější" stroje. To neznamená, že by to bylo nějak předělané, aby to fungovalo v PC, a s Athlony a spol to nemá nic společného. Jsem si přečetl /když tu s tím pořád házíte:)/

fotoba: moc me zajima co je v nejakych prednaskach na jakesi hornicke skole ... evidentne to jsou nesmysly .... ;)
EPIC neni podmnozinou RISC, je to nezavisla technologie, ano vznikla v dobe RISCu, to ale neznamena ze je jeho podmnozinou ...
k 21264PC, pises nesmysly, je to upravena verze 21264 urcena pro pracovni stanice (tedy levnejsi), dokonce pro ni byla portace Windows NT, ale s AMD a vubec s architekturou x86 to nema nic spolecneho ... a uz vubec ne ze by snad z toho neco vlastnila
ano, sbernice v K7 vychazela z EV5/EV6 (pochopitelne nemohlo jit o totoznou sbernici), AMD muze tuto sbernici dozivotne uzivat ale ani tak ji nevlastni (tj. nemuze ji dale prodavat, atp, momentalne ji vlastni intel), nic jineho netvrdim ... v K8 je pouzit HT...

Eagle> ve VLIW v podani IA64 rozhodne nejsou instrukce na urovni microOPs jako je tomu u RISC, na druhou stranu ano, nejsou natolik koplexni jako u CISC-x86. Lze rici ze jde o rozumne zvoleny kompromis (z tohohle pohledu se vice blizi dokonce CISC, bez opravdu hodne slozitych komplexnich zadratovanych instrukci). Navic jsou tyto instrukce sektupovany instukcnich slov. Celkova velikost IA64 kodu neni vyrazne vetsi nez u CISC (max procenta, na rozdil od RISC kde jsou to spise nasobky).
Co se tyce vykonu, ano x86 architektura ma problemy pomalosti pameti a cache.... IA64 ne, mozna prave proto IA64 hrave prekonavaji x86 procesory na vyssich frekvencich ...
Ano architektura itania2 se uz par nezmenila, to jen svedci o jeji kvalite ...
Vetsina kompilatoru ma optimalizaci ... Promin pokud chces psat aplikace typu "hello world" v deplhi (ono v tom strasnem a mrtvem jazyku ani nic o moc lepsi napsat nejde), tak ver ze se v tomto pripade obejdes i bez otimazace, tyhle kraviny bezi dostatecne rychle i v emulovanem rezimu ...
Paralelismus je cestou k vykonu i na desktopu, a je to i soucasny trend (procesor CELL, graficke karty a ruzne GPU, atd.), to ze se u x86 paralelismu nevyuziva neni tim ze neni potreba, ale tim ze to proste na x86 nejde, nebo je vyrazne neefektivni ...

focivibi : ano, tim smerem to nejak jde, prekladac je ale sw (coz je v konecnem dusledku efektivnejsi). Proste se vezme kod, ted se pri spusteni na dane platforme pretransormuje (codemorphing) a zoptimalizuje pro dany procesor a nasledne spusti ... Timhle zpusobem se napr spusteji PA-RISC aplikace na procesorech Itanium2, a to prakticky bez jake vykonostni ztraty. Stejne tak se na Itaniich emuluje x86 aplikace, bouzel x86 instrukcni sada je natolik zmrsena vec (ono se ani za tech 25let nedive), ze efektivita bohuzel neni 100% (mozna 70%???), existuje i HW emulace x86 na IA64 ta je ale jeste mene efektivni ...

ivan2:
"ze se u x86 paralelismu nevyuziva neni tim ze neni potreba, ale tim ze to proste na x86 nejde, nebo je vyrazne neefektivni"

Nemůžu tak docela souhlasit. Je to mnohem spíš o typu úloh, které se počítají - na Cellech, GPU a podobně se právě že počítají ty úlohy, které by se krásně paralelizovaly i pro jakékoliv CPU, i x86. To znamená, že ta nemožnost nebo neefektivnost není v architektuře, ale v těch programech (nebo algoritmech).

Netřeba kydat na x86 bahno, kdo má nejrychlejší výpočetní jádro? x86 - byl to Opteron, teď je to Core2 (zvlášť když si vezmeme, že Intel by nejspíš mohl vydat quad na 3,5-4 GHz, kdyby navýšil spotřebu). Občas se urve nějaký IBM POWER, ale x86 jinak hladce dominují. TAkže jako architektura to asi nebue tak tragické, ne? Škaredé a uncool, možná. Ale pracanti :)

Mandarinka: To ze je x86 architektura pro paralelni zpracovani naprosto nevhodna je znamy fakt. Ale souhlas s tim ze pro plnohonotne vyuziti paralelismu bude zalezet na typu aplikace (ale myslim ze techto aplikaci je i na desktopech dobudoucna dostatek (jakakoliv multimedialni aplikace, hry, rozpoznavani reci a obrazu, AI, ...)). A souhlas s tim ze ta aplikace musi byt vhodne napsana aby vyuzila paralelismu, ale zase to neni o nejake optilalizaci pro konkretni procesor (to je ukol pro kompilator, ne pro prgramatora). Proste chci rici ze cesta k dalsimu zvysovani vykonu procesoru rozhodne neni ve zvysovani frekvence, ani v pridavani jader (ktere desktopova aplikace nedokaze vyuzit), ale prave v masivnejsim paralelismu a efektivnejsim vyuzivani prostredku. Pro to je ale potreba jednak technickych prostredku (a zde x86 asi neni to nejlepsi reseni, naopak IA64 je z jednim z nejvhodnejsich), a jednak zmeny v programovani aplikaci, to je ale na programatorech ...
Co se tyce vykonu jadra, tak nesouhlas, x86 je popularnejsi (diky cene a dostupnosti reseni), to ano, ale ne vykonejsi. Pokud chces merit vykon jadra mer ho bud na jednotku spotreby energie (tedy nakladnosti provozu), nebo na jednotku tranzistoru (tedy nakladnosti vyroby). Zde v obou dvou pripadech vytezi IA64, a pak asi IBM Power. x86 je hodne vzadu, proste takovy tranzistorovy moloch a zrout energie ... Nechci hazet na x86 spinu, je to k prihlednutim k dobe vzniku skvela architektura, a dokazala to co zadna jina, drzet krok 25let, a jeste tu mozna dalsich 10tel bude, ale je tez svou historii hodne zatizena (zastarala architektura, z duvodu kompatibility sest ruznych rezimu prace, velke a prekomplikovane jadro, desitky ruznych ne vyzdy efektivnich rozsireni, ...), proste sva nejlepsi leta ma jiz zasebou ...

2 ivan2: Právě že velikost kódu je výrazně větší než u x86, rozhodně ne v jednotkách procent:
"Bigger caches are what the EPIC CPU needs. One of the biggest disadvantages of the EPIC CPU is code inflation. When we compiled some source (64 bit) code on the Itanium back in 2001, the code was about 2.5 to 3 times bigger than (32 bit) x86 code. That is not really surprising: an IA-64 128 bit bundle contains 3 instructions. An x86 instruction can be from 1 to 17 bytes long, but is on average a little less than 3 bytes or 24 bits long. That means that x86 instructions are on average about 2 times more compact. There are many other reasons why EPIC code is more bloated than x86. Because of restrictions on the types of instructions that can be placed in each slot of an IA-64 bundle and the fact that a bundle must be of the same length, IA-64 requires NOPs in unfillable slots. This leads to the insertion of NOPs or useless instructions that take up space." - z http://www.anandtech.com/printarticle.aspx?i=2598
Problém s cache není dán architekturou CPU. Rychlost cache závisí na možném množství paralelních přístupů, latenci a v menší míře na datové šířce (datové šířce hlavně u refill do L1, u samotné L1 to zas tak hrozné není). Čím větší cache, tím zabírá více plochy, tím má větší zpoždění na vodičích a tím má také horší latenci. Přirozeně čím nižší frekvence, tím může být latence v hodinových cyklech menší. Itanium nemá o nic lepší cache než x86 procesory, protože má nízkou frekvenci, takže její menší latence jde s delším cyklem. Naopak to, že je Itanium hladové po instrukční cache mnohem víc než x86, vede k potřebě větších a tudíž pomalejších cache a k potřebě větších datových toků a to i do RAM. Troufám si tvrdit, že vzhledem k tak obrovským cache (a gigantickým výrobním nákladům) není práce Itania s pamětí nijak zázračná.
Architektura Itania se pár let nezměnila nikoli kvůli kvalitách, ale právě proto, že by bylo potřeba upravovat už tak dost složitý kompilátor a překompilovávat programy. U speciálních výpočtů (věda, armáda...) to ještě jednou za pár let jde, ale v desktopech by bylo něco takového absolutně nemyslitelného.
Většina kompilátorů možná má "nějakou" optimalizaci, ale tady se bavíme o špičkovém kompilátoru. Takových je extrémně málo, daly by se sem zařadit tak možná Visual C++ od MS a Intel C++ Compiler, ale zbytek? Průměrný kompilátor degraduje výkon EPIC o desítky procent. A BTW, vyvinout takový kompilátor nebude žádná legrace (viz "úspěchy" Intelu při tvorbě automatickém multithreadingu).
Paralelismus se v desktopech nevyužívá především z toho důvodu, že většina kódu je čistě sekvenční. Přemýšlet paralelně vyžaduje od programátora velmi dobré znalosti architektury CPU (ideálně assemblerové + optimalizační příručka) a schopnost vymyslet paralelizovatelné algoritmy. Není tajemstvím, že v desktopech často takové algoritmy ani neexistují a i kdyby existovaly, tak je obvykle rychlejší (= levnější = jediné pro zákazníka přijatelné) použít sekvenční algoritmy. Souhlasím s tím, že x86 je přebujelá a že by to chtělo změnu, ale dle mého tou změnou určitě není Itanium - jeho roli vidím u zmíněných vědeckých výpočtů, ale nikam jinam se dle mého nehodí. Do desktopu by se spíš hodilo středně složité OoO jádro (2-issue) s velkým instruction window, velmi dobrou podporou SIMD, multithreadingem se sdílením jednotek (kvůli synchronizaci výpočtů - teď není možné paralelizovat malé úholy, protože synchronizace žere moc času), velmi vysokou frekvencí a asistencí kompilátoru při určování prioritizace threadů, ILP, prefetch (bylo by součástí kódu - jakási nápověda pro CPU).

Eagle: ten kousek clanku srovnava hodne teoreticky 32bit x86 a 64bit IA64 a pouze intrukcni cast kodu. Pokud srovnas 64bit x86 vs IA64, cely kod, a spise nez teoreticky se na to podivas vice prakticky, tak se dostanes asi na 30% vetsi kod, coz jsem jiz uvadel. Coz je pomerne mala dan za vyhody co IA64 prinasi. Navic tranzistor v cache je vyrazne levnejsi a energeticky mene narocny. Jinak zajimavy clanek, v podstate rika to co, IA64 je architektura budoucnosti...
Jinak prace s pameni Itania pochopitelne zazracna neni, je zcela z realne lepsi nez u x86 :)
Ano bavime se o spickovych kompilatorech jako je MS nebo Intel C++, a ono snad realne nekdo pouziva neco jineho? Prosim uz zapomen na to Deplhi je to skoro deset let mrtvy jazyk ...
Ano velka cast desktopoveho sw bezi ciste sekvencne (calc.exe, notepad.exe, ...) na druhou stranu tyto aplikace nepotrebuji vykon procesoru, a pobezi stejne dobre i starem dobre 80486 tak i v emulatoru ... ano trochu prehanim, ale vis ka mirim ... Potencionalne velmi vykonove narocne dektopove aplikace, jsou aplikace ktere dokazi velmi dobre vyuzit paralelniho zpracovani (multimedia, realtime rozeznavani hlasu a obrazu, AI, directX, ...), a vez ze tyhle aplikace nebude vytvaret nejaky jouda z hornidolni na svem ukradem deplhi, a ze to bude domenou spickovych teamu, kteri vi co delaji ...
Ano druhou cestou (po ktere se momentalne jde) je mit stale neefektivni CISC procesor s 200mil trazistory, a to co nezvlada sverit dalsim nekolika proprietarnimi GPU kolem neho s dalsimi stovkami milionu tranzistoru ... a pak uz se nelze divit ze k tomu "domacimu" budeme potrebovat taky takovou malou domaci elektrarnu ...
To co rikas ty, nevim, jestli je potreba mit dalsi architekturu ... nebo dost mozna dalsi mod v x86 molochu. Kdyz uz, tak mozna udelat light verzi x86 v ciste 64bit verzi, tedy oklestenou o ruzne prehistoricke mody, opravdu komlikovane instrukce, ruzne nepotrebne rozsireni (3dnow), a dalsi historicke komplikace... proste udelat moderni rychle cisc jadro a s vykonou simd jednotku ... a zpetnou kompatibilitu resit sw (ale ono by nebyla ani moc potreba, stacilo by kdyby jeden nejmenovany sw vyrobce portoval dva sve nejprodavanejsi produkty ...) ... jenze prave tohle se nikdo neodvazi ...

"If we ignore Intel's poor execution during the past months and the economic realities, and focus on the architecture, it is clear, however, that the Itanium has time on its side and is most likely the architecture with the highest potential."

Srovnávat celý kód včetně dat je přece nesmysl. To by pak stačilo natáhnout jednu gigantickou bitmapu a na ní provést primitivní změnu a skutečně bude celek větší jen o 0,001 %. Srovnávat kód je hodně důležité, protože to ovlivňuje efektivitu cache a celkový výkon - a evidentně u Itania platí, že kód bude malý, pokud bude silně paralelní (minimum NOPů).
Transistor v cache je sice levnější a nemá moc velkou spotřebu, na druhou stranu, jak už jsem říkal, čím větší cache, tím je nutně pomalejší a to má velký vliv na výkon (u in-order procesorů dokonce kritický). Proto je kompaktní instrukční sada dobrá i v situaci, kdy nejde o výrobní cenu ani spotřebu. Schopnost Itania pracovat s cache bych nepřeceňoval, v podstatě je to in-order procesor (out-of-order scheduling je na úrovni kompilátoru) a to znamená, že jakékoli zpoždění přístupu k datům pro něj znamená katastrofický propad výkonu. Proto taky Intel u generace Itanium 2 neustále zvětšoval cache - aby zajistil lepší hit-rate a tím zlepšil výkon. x86 jakožto OoO koncept je schopen schedulovat instrukce i podle toho, v jakém stavu jsou data - pokud jsou daleko, tak se prostě vykoná jiná instrukce. Limitem je zde akorát instruction window, které je relativně malé (Athlon 72 microOPs, Core 2 96 microOPs + fúzované, Nehalem 128 microOPs + fúzované). Pokroky v hardware prefetch u x86 v posledních letech jsou také značné (hlavně u Core 2), u Itania by takové změny znamenaly nutnost upravit kompilátor a překompilovat kód.
Kvalita kompilace a čas na ní vynaložený jsou nepřímo úměrné. A pokud kvalitní kompilátor převádí některé rozsáhlejší projekty (např. eMule) i třeba půl hodiny až hodinu, pak při EPIC kompilátoru s ještě mnohem větší náročností by převod trval i několik hodin. S nástupem "polokompilovaných" věcí a lá .NET není možné očekávat, že uživatel bude při instalaci každého software čekat třeba několik hodin, než se to celé převede. Navíc - z běžně používaných jazyků je programově efektivní pouze C++ (je nejblíže assembleru), zbytek má vždycky nějaký balast usnadňující programátorovi život (např. automatická inicializace proměnných na nulu ve Visual Basicu, absence pointerů ve většině jazyků...). Už jen převedením aplikace do C++ se dosáhne mnohem lepších výkonů. Kolik lidí to ale dělá? Hrozně málo. V dnešním světě jde primárně o cenu a ta určuje směr vývoje. A nejde jen o amatéry - existuje spousta zakázkového i profesionálního software, který má vůbec potíže korektně fungovat. Např. takový Excel s rozsáhlejšími makry rád padá a i samotná jeho implementace VBA je v takovém stavu, že samotný MS prohlásil, že pro podporu x64 bude nutné celý VBA předělat (v Office 2008 pro MAC dokonce radši VBA kvůli tomuto kompletně zrušili). Stejně tak třeba Photoshop je těžce neoptimalizovaný - z performance monitoringu vyplývá, že při přáci s většími fotkami procesor většinu času jen čeká na data. Profesionální CAD systémy mají také tendenci sem tam spadnout. A to se bavíme o C++ programech. Je ještě spousta softu, který je napsaný v jazycích jako VB. Že by se najednou dělal pěkný kód, ze kterého by mohlo Itanium profitovat, to považuju za scifi. Spíš je potřeba se smířit s tím, že běžný program běží s IPC = 1 a nic se s tím do budoucna neudělá.
Jinak ty úlohy, které uvádíš (např. multimédia), jsou často paralelizovatelné velmi špatně (např. video kompresní kodeky mají s rostoucí kompresí obecně tendenci vytvářet víc výpočetních závislostí) nebo jsou naopak tak extrémně datově a výpočetně náročné a zároveň nepodmínkové, že se na ně skvěle hodí grafické karty (např. šifry nebo i Photoshop - věřím tomu, že na grafické kartě by úpravy běžely o řád rychleji než na jakémkoli CPU).

Eagle: nesrovnanam nejaky kod s obrovskou bitmapou, ale bezny prumerny kod. Navic data proste zanedbavat nemuzes, protoze jsou v cache at se ti to libi nebo ne. Proste k cemu ti je architektura ktera dokaze byt cite pro instrukcni kod v cache 50% uspornesi, kdyz v cache bude mit stejne z 90% data (pak bude realna uspora zanedbatelnych 5%). Proste rikam ze realny rozdil (u 64bit aplikaci, u 32bit je pochopitelne vetsi) je mensi nez 30%...
Ad rychlost cache, je docela smesne se bavit o vetsich latencich diky vetsi velikosti a vzdalenosti cache, totiz to pak muzu rici ze u x86 architektury diky obrovskemu molochu tranzistoru v jadru, a tedy taktez pozadvku na velikost, mas uplne stejny problem. Ostatne praxe to dokazuje, porovnejsi si propustnosti systemu... Nicmene tak ci tak to je asi nepodstatny problem (v jednotkach procent), ve srovnani treba s asi ctyrnasobne velkou pipeline u x86 oproti IA64 ...
No pokud rikas ze IA64 je inorder procesor (s outoforder na urovni kompilatoru), tak ja rikam ze x86 je taktez inorder procesor (s outoforder na urovni zadratovaneho prediktoru). Zde nezbyva dodat ze pochopitelne sheduling na urovni compilatoru je nesrovnatelne kvalitnejsi a presnejsi nez neco zadratovaneho v procesoru (no a kdyz k tomu pripocteme jeste neefektivne dlouhou pipeline x86 ...) ...
Ad kompilace, no myslim ze dnes tak dlouho kompilace trvat nebude, ale to je koncovemu uzivatelu stejne fuk. Souvislost s .NET uplne nechapu ... to jako ze by si to kazdy kompiloval sam ... neblazni ...
BTW s nastupem technologii jako silverlight, ktere do budocna v podstate nahradi bezne deskopove aplikace, to pozbyva smyslu, proste bude stacit kdyz bude nainstalovana a dobre optimalizovana technologie silverlight, a u samotnych aplikaci bude jedno pro jakou platformu jsou urceny ... Proste okruh aplikaci ktere budou primo psany v nejakem kodu ktery bude kompilovan primo na procesoru se bude zuzovat ... coz prave nahrava IA64. BTW v podstate to jde smerem tak jak psal focivibi.
Co se tyce Photoshop (ano je to bes) ci CAD aplikaci, je mi v podstate fuk jestli vykreslovani tlacitek menu bude nebo nebude optimalizovane, bude zalezet jak budou napsane jednotlive fitry (nazavisle na photoshopu), ci jak bude napsane OpenGL (open nezavisle na CAD aplikaci), a je jasne ze veci jako OpenGL nebude psat nejaky jouda v deplhi, neblazni. Co se tyce ostatnich aplikacich ve VB, tak je to asi fuk, u techto aplikaci nejsou vetsinou kladeny buhvijake naroky na vykon, pobezi dobre jak neoptimalizovane ci i v emulaci ... stejne v budoucnu budou nahrazeny aplikaci v silverlight.
Multimedialni funkce jsou vetsinou velmi dobre paralelizovatelne, ne ovsem do nezavislich threadu (proto jsem taky rikal ze cesta k vykonu nevede zvysovanim frekvence ani slepemu pridavani jader). Paralerismus na urovni kodu (jako je EPIC) je v podstate jedinou dlouhodobou cestou k dalsimu zvysovani vykonu.
Ano filtry v photoshopu by bezpochyby bezeli rychleji na graficke karte, nebo lepe nejake specialnim proprietalnim SIMD procesoru ... ale myslim ze cesta tim ze si koupis nejaky sw, a budes si muset do PC pridat nejakou specialni kartu se specialnim procesrorem asi cesta nevede ...