Zpět na článek

Diskuze: Intel Core - pohled na architekturu I

Nejsi přihlášený(á)

Pro psaní a hodnocení komentářů se prosím přihlas ke svému účtu nebo si jej vytvoř.

Rychlé přihlášení přes:

Google Facebook Seznam Discord

tief

Level

26. 6. 2006 18:12

Komentáře tohoto uživatele máš zablokované.

Prefetch = spekulativní načítání dat ještě před tím, než jsou potřeba.

tief

Level

24. 6. 2006 18:09

Komentáře tohoto uživatele máš zablokované.

160bit je délka prefetch, což nemá s kapacitou moc společného. Například FPU jednotka taky může používat 80bit proměnné, což také není číslo příliš dobře kompatibilní s mocninami dvou.

tief

Level

11. 5. 2006 19:00

Komentáře tohoto uživatele máš zablokované.

Pentium M tuto sběrnici používá taktéž.

wessan

Level

3. 5. 2006 11:10

Komentáře tohoto uživatele máš zablokované.

neco mi rika ze vsechny pixely (na texturovanem trojuhelniku) jsou soucasti textury => pracuje se s texturami
ad nepracuje se ve streamu: vy si vazne myslite, ze si gui posila do pameti zadosti o jednotlive pixely? vite co by to bylo za pocet pametovych operaci? a jake by se nasbiraly latence, nez by se vykreslila 2048x2048 textura? ... ona se vytvori v rasterizatoru maska jejiz logickym soucinem se velmi rychle zjisti adresy potrebnych pixelu a gather se postara, aby dorazili ve streamu s minimalni latenci do shaderu

petr3_331

Level

3. 5. 2006 08:43

Komentáře tohoto uživatele máš zablokované.

část "Změny v jednotkách"
kapitolka "Vsuvka: Jaké jednotky procesor obsahuje?"

> Počet dostupných registrů je v 32bit režimu osm, v 64bit režimu šestnáct.
---
Nemělo by to být spíš v 32bit 16, v 64bit 8 ??
Aspoň teda z pohledu "skládání" registrů, tj že horní polovina 64bit registru slouží jako jeden 32bit registr, a současně dolní polovina 64bit registru jako druhý 32bit registr.
Nebo v tomhle případě neplatí (např) a=lobyte(ax), ax=loword(eax)?

tief

Level

3. 5. 2006 08:57

Komentáře tohoto uživatele máš zablokované.

@petr3_331 Nikoli, je to skutečně tak, že programátor disponuje šestnácti 64bit registry. Více viz https://www.svethardware.cz/art_doc-EC20FC74EB3582DFC1256DAA00294E90.html .

petr3_331

Level

3. 5. 2006 13:38

Komentáře tohoto uživatele máš zablokované.

@tief díky za rychlou odpověď :)

wessan

Level

2. 5. 2006 21:18

Komentáře tohoto uživatele máš zablokované.

technologie fast14 umoznuje jen beh na vysokych frekvencich nemyslim, ze ma vliv na to jak principielne funguji shadery a vubec cely proces, ktery probiha na grafickych kartach

na graficke karty se jde divat mnoha zpusoby, od jednoducheho vysvetleni principu (ktere jsou verejne zname), pres nejaky podrobnejsi popis jednotlivych jednotek (ktery je taky relativne znamy), popis usporadani pameti, ktera je dulezitou soucasti graficke karty (taky zname), optimalizacni techniky (komprese textur, efektivni cliping, komprese z-bufferu), vyuziti gfx pro negraficke ucely ... ale kdyby mel nekdo popsat jak presne tohle ma nvidia nebo ati implementovane, tak bude informace hledat horko tezko, protoze je to obchodni tajemstvi ... pana Jiriho Soucka neznam, ale jestli je to nejaky expert na problematiku, tak to muze byt idealni clovek na takovy clanek

pokud muzu doporucit, tak je lepsi materialy o grafickych kartach hledat spise u nvidie, nez u ati, protoze ati sice dokaze udelat rychle cipy, ale co se tyce nejakych sluzeb pro vyvojare/ovladacu/nastroju byla na tom velmi bidne co si pamatuju (uz delsi dobou v c++ nepracuji)

tief

Level

2. 5. 2006 21:05

Komentáře tohoto uživatele máš zablokované.

Nebojte, redakce Světa hardware nikomu nebude odpovídat větami typu "Co to tady blabolis?", "No mozna si nekdo stoji na vedeni" nebo "Ja nevim ale mi prijdes trosku mimo spise ty... a)neumis cist; b)nemyslis". Snažíme se mít jistou úroveň, která odpovídá etickým zásadám. Zároveň příspěvky čtenářů, které nějak napadají ostatní či obsahují nevhodná slovní spojení, mažeme. Pokud tito pokračují v činnosti, je jim zablokován přístup. Chceme, aby diskuze na Světe hardware měly úroveň a aby čtenáři poskytly další informace k tématu.

kaizer soze

Level

2. 5. 2006 19:15

Komentáře tohoto uživatele máš zablokované.

akoze u mna ste borci :oP ale uz je to fakt metal, ake debaty sa tu vedu. Na urovni samozrejme, lenze na akej ?! ...

shinigami

Level

2. 5. 2006 16:43

Komentáře tohoto uživatele máš zablokované.

No tomu rikam odpoved:) Ja si nechci kupovat Itanium, pouze rikam, ze me prijde logicke umoznit obejit nektere ne nutne potrebne casti procesoru.

A ziskatelny vykon imho neni jedina vyhoda. Kazda bezici jednotka spotrebovava energii, a takova predkompilace do jeste nativnejsiho kodu by je umoznila vypnout a usetrit.

freemen

Level

2. 5. 2006 15:38

Komentáře tohoto uživatele máš zablokované.

tak existenci asi ne...ale je asi pravde že letos toho amd s am2 moc nepředvede, podle meho to amd opět rozjede s ddr3 pametma nastupem hypertransportu3.0 a 65nm proces někdy příští rok. amd ma pro 65nm pripravene nove technologicke postupy atd. tim se dočkáme vyšší vtěžnosti z 300mm waferů, tím se ještě o malinko zvýší konečná frekvence no a kdyš k tomu vyladěj k dokonalosti stávající k8 architekturu tak takový Athlon FX-70 na 2x3,5GHz 2x2MB L2 + 3MB L3 cache roznese celý intel na kopytech...:)podle meho se amd jen tak nedá.

mkobylan

Level

2. 5. 2006 14:36

Komentáře tohoto uživatele máš zablokované.

Moze mi niekto vysvetlit, preco pouzivame optimalizaciu v kompilacii, ked aj tak musia procesory pri kazdom spusteni kodu robit dalsie optimalizacie znovu a znovu? Jedenkrat naprogramovany a skompilovany kod v OS je takto miliardy-krat opat a opat analyzovany a optimalizovany na spracovanie.
A nehovorte mi, ze ide o kompatibilitu s minulostou.

shinigami

Level

2. 5. 2006 15:32

Komentáře tohoto uživatele máš zablokované.

@mkobylan Proc pri kompilaci?

Prekladac na to ma vic prostredku.
Prekladac muze najednou pracovat s vetsi casti kodu, delat komplikovanou analyzu, atd..
Pro napraveni 'spatneho' kodu by procesor musel byt hoodne dobry.

Proc na CPU?
CPU ma vic informaci o behovych zalezitostech, jako treba pravdepodobnosti skoku na podmince atd.
Prekladac vytvari kod pro nejakou virtualni platformu, ktera ma omezeni (pocet registru, na ruznych CPU trva stejna instrukce jinak dlouho), ale nejde ji porad menit jak kdo potrebuje. Proto treba prejmenovavani registru, prerovnavani instrukci...
Neda se pocitat s tim, ze kod vygeneroval kvalitni prekladac, mozna spis s opakem;)

Asi by se dalo rict, ze pokud budete mit dost informaci o vyslednem CPU(HW), predikovatelny tok programu atd. tak potreba optimalizaci na CPU vyrazne klesne, pripadne budou mit tak maly efekt, ze to nebude mit smysl je delat. Ale to pomalu znamena mit na kazdou konfiguraci HW zvlast zkompilovany software. Ale i to se da, viz treba Sourcemage distribuce Linuxu (bohuzel ne kazdy se o sve zdrojaky rad podeli), pripadne kompilace vysledneho kodu az za behu na zpusob Javy.

shinigami

Level

2. 5. 2006 15:38

Komentáře tohoto uživatele máš zablokované.

@mkobylan Abych pravdu rekl, tak me docela udivuje, ze tu jeste nemame moznost obejit dekoder a dalsi casti a krmit CPU primo v jeho vnitrnim kodu. Pravda je, ze by byly komplikace s ruznymi verzemi jader, ale pokud nekdo chce vyzdimat z CPU maximum, tak by si s tim urcite rad dal praci. Nebo mit aspon pristup k vysledku dekodovani a moct ho nacacheovat/ulozit na disk.

tief

Level

2. 5. 2006 15:44

Komentáře tohoto uživatele máš zablokované.

@shinigami Pánové, nepřeceňujte programátory. Spoustě her chybí dokonce i optimalizace prováděné kompilátorem! Ano, programátoři se často neobtěžují ani za ony tři minuty zapnout pár přepínačů.

mkobylan

Level

2. 5. 2006 19:41

Komentáře tohoto uživatele máš zablokované.

@shinigami To nebolo az tak o optimalizacii ako o instrukcnej sade. 64bit je uz tu a dalsia sanca na prechod k rychlejsej instrukcnej sade sa nekona?

dodoCC

Level

2. 5. 2006 14:31

Komentáře tohoto uživatele máš zablokované.

dajte ten graf pri hodnotení článku opačne, nech ide tiež z ľava do prava, tak ako stupnica.

PetFish

Level

2. 5. 2006 14:04

Komentáře tohoto uživatele máš zablokované.

V otazce vyrobniho procesu nejsem odobornik, ale nedvano jsem cet, ze SOI (AMD) je lepsi nez strained silicon (Intel) ... tudiz si nejsem tak jisty s tou prevahou Intelu na tomto poli (?).

wessan

Level

2. 5. 2006 14:01

Komentáře tohoto uživatele máš zablokované.

MIMD - ano je uvnitr shaderu (sekvence jednoduchych instrukci), ale kde jinde byste ji chtel mit?
ano ... pixely pro pixel shader vznikaji v rasterizatoru (dojde textura ve streamu, vypadne stream pixelu ktere se predaji pixel shaderum), dulezite je ze vsechny tyhle operace jedou streamovane za sebou
ale porad za vas gpu krmi pixel shader streamem pixelu a predava vypadla data dal
uprimne: nevim jestli si nerozumime, ale opravdu jsem nepochopil, na co jste narazel, jestli na to ze jsem do detailu nepopsal cely proces (snazil jsem se to maximalne zjednodusit), nebo jestli je tam nejaka chyba

wessan

Level

2. 5. 2006 13:34

Komentáře tohoto uživatele máš zablokované.

jj souhlasim ... je to jen o tom, jak se procesor jevi navenek ... cela "mimd" operace se provede jako sekvence prikazu vertex/fragment programu ... je otazka co je skutecna mimd operace, protoze i CISC instukce se ve finale rozlozi na jednotlive RISC instrukce, ktere se vykonaji sekvencne (jinak to lide zatim neumi) a pokud se CISC provede najednou, tak je to zase jen jedna instrukce ... takze z tohoto hlediska MIMD neexistuje ... za MIMD se tedy obecne povazuje, kdyz sekvence vypocetnich jednotek provede postupne nejake operace na streamu dat ... tak to chapu ja, kdyztak me opravte

wessan

Level

2. 5. 2006 13:21

Komentáře tohoto uživatele máš zablokované.

je to i problem architektury, za kazdy hodinovy cyklus musite spocitat jednu stupen pipeline - cim kratsi tyto stupne mate, tim vice muzete procesor taktovat ... amd uz ma celkem dlouho 12 stupnu, netburst zacinal tusim na 25 a koncil kolem 35 ... to znamena ze vypocet operace byl rozdelen na extremne male kroky (kratke stupne pipeline) diky tomu jsou teoreticky uzasne taktovatelne (az na 7-8GHz mozna vic), ale narazi na teplotni barieru ... amd diky dlouhym stupnum pipeline moc taktovat nemuzete, protoze i sebelepsim vhlazenim budou v procesoru nastavat pocetni chyby, protoze nekde se nestihne neco vcas spocitat, tak se dal pracuje se straou hodnotou a chyba se siri ... kolik a jake stupne ma core nevim

tief

Level

2. 5. 2006 13:28

Komentáře tohoto uživatele máš zablokované.

@wessan Core má 14 stupňů pipeline. Kde to oproti Pentiu M natáhli, to zatím nebylo zveřejněno.

wessan

Level

2. 5. 2006 13:37

Komentáře tohoto uživatele máš zablokované.

@tief uvidime jak se intelu povedli udelat kratke ... s prihlednutim k postupu technologii by to mohlo ji tak do 4,5GHz

Jiří Mrázek

Level

2. 5. 2006 13:11

Komentáře tohoto uživatele máš zablokované.

Ja nevim jak ty, ale hlavni zisky jdou z mainstreamu nebo snad ne? Kazdej si nemuze dovolit CPU 30000Kc, ale uz cpu za cca 3000-7000Kc cili tak v prumeru dejme tomu A643000+ nebo adekvatni Intel....

tief

Level

2. 5. 2006 13:27

Komentáře tohoto uživatele máš zablokované.

@Jiří Mrázek Pokud se naplní předpovědi, pak by nejlevnější Conroe měl stát kolem pěti tisíc s DPH - https://www.svethardware.cz/art_doc-17AA16C0BBCD473FC1257144003C97D5.html . To by pro AMD byl značný problém, protože by na ně zbyl jenom low-end. Zbytek by okupoval Intel.

tief

Level

2. 5. 2006 13:11

Komentáře tohoto uživatele máš zablokované.

Podle nejnovějších zpráv by měl být Conroe uveden již v červenci 2006. Prý to prohlásil sám CEO Intelu.

tief

Level

2. 5. 2006 12:18

Komentáře tohoto uživatele máš zablokované.

Domnívám se, že poměrně jednoduché bude:

1) přidat další instrukční dekodér (tj. mít čtyři) -> zvýší počet microOPs, dopad bez dalších změn je ale diskutabilní

2) upravit SSE jednotky na 128bit -> zvýší výkon v SSE na úroveň, kde by procesor mohl být konkurenceschopný (podle testu Sandra Multimedia Benchmark dosahuje Conroe na stejné frekvenci cca. trojnásobného (!) výkonu v celočíselném SSE oproti stejně taktovanému Athlonu 64 X2)

3) Optimalizovat trasování tak, aby nebylo 64bit, ale 128, tj. aby ony 128bit SSE jednotky byly k něčemu.

Co už vidím jako větší problém, je předělání out-of-order na více záznamů a na práci s více microOPs za takt. Stejně tak implementace Memory Disambiguation a fúzování určitě nebude tak jednoduchá (zejména microOPs fusion). A konečně úprava pipeline z hlediska počtu Issue Portů a počtu jednotek je dost komplikovaná.

Počet nutných změn mi přijde příliš velký na to, aby to AMD za půl roku stihlo. Nehledě na to, že i v současné části by bylo nutné upravit termální management, protože bez něj by se "naboostovaný" procesor asi upekl. Také by museli upravit pipeline z hlediska počtu stupňů, něco teď evidentně A64 brzdí, když se Conroe se čtrnácti má dostat na 3.33 GHz, zatímco AMD horko těžko dosahuje 3 GHz a teplem to není. Prostě AMD teď naráží na to, že od roku 1999 (K7) neproběhly na jejich architektuře žádné razantní změny v oblasti out-of-order zpracování, a tak jim nově vytvořený procesor s mnoha inovacemi a širokým paralelismem může pořádně "zatopit".

pleva

Level

2. 5. 2006 12:17

Komentáře tohoto uživatele máš zablokované.

článek jak jinak než bez chybky a snadno čtivý.

Myslím, že by bylo zajímavé nahlédnout pod pokličku 64bit. Někdo to prostě brzdí a AMD už asi rezignovalo :-(
Intel dopiloval novou řadu a teď nemusejí mít manažeři Intelu stažený(ou) ....., kdy že MS masivně podpoří 64bit.
Na spiknutí nevěřím, ale tady ho vidím. A přitom 64bit může být ta správná cesta.
Ostatně, kdo má 64bit XP? A k čemu že nám jsou?

shinigami

Level

2. 5. 2006 14:21

Komentáře tohoto uživatele máš zablokované.

@pleva Spis nez na spiknuti bych to videl spis na neochotu/lenost lidi ke zmene. Da se argumentovat treba tim, ze M$ cilene nevytahlo 64bit system driv a nedivil bych se, kdyby to byla pravda, na druhou stranu velkou cast uzivatelu u M$ nic nedrzi a kdo chce, tak uz si 64 bitu davno uziva.

pleva

Level

2. 5. 2006 18:32

Komentáře tohoto uživatele máš zablokované.

@shinigami Kolem uvedení 64bit woken, bylo jasné, že MS čeká na uvedení Intel processoru s EMT64. Nedivil bych se, kdyby bylo v nejvyšších kancelářích zamčené něco, co se my nikdy nedozvíme. Firmy musí spolupracovat a oslabení konkurence je sice nefér, ale normální.
Viz třeba NVidia a ULI. Teď je jasné, že NV koupila ULI aby ztížila život ATI (a samozřejmě i proto, aby si vylepšila NForce4)

tief

Level

2. 5. 2006 10:34

Komentáře tohoto uživatele máš zablokované.

Nechtěl by někdo z vás, kdo tomu rozumíte, napsat článek na téma jak funguje moderní GPU? Ale detailně, aby bylo řečeno, jak do čipu přichází kód a data, jaké jednotky provádí které operace, jaké jsou tam výhody/nevýhody, možné problémy atd. Něco takového bychom určitě ocenili a bylo by to velmi zajímavé.

wessan

Level

2. 5. 2006 10:43

Komentáře tohoto uživatele máš zablokované.

@tief muzu ... mam za sebou predmet architektury pocitacovych systemu a tam se to detailne probira ... bohuzel casu neni mnoho, takze snad ma kolega zajem

tief

Level

2. 5. 2006 10:49

Komentáře tohoto uživatele máš zablokované.

@wessan Zmíním se šéfredaktorovi, aby vás kontaktoval na vašich emailových adresách.

wessan

Level

2. 5. 2006 10:03

Komentáře tohoto uživatele máš zablokované.

ano programator se o nacteni pixelu nestara, ale gpu ano ... ten to udela presne jak jsem psal (nacte ohromne mnozstvi pixelu/vertexu/textelu a posle ho do shaderu) ... funkce pricteni svetla uz je dnes realizovatelna prave diky pixel shaderum (dokonce se tak pocitaji stiny - jeste s pomoci cube map a podobne) ... jinak prave vlastnost nacitani pixelu v rade s nulovou latenci (po prvnim pixelu) je nejpodstatnejsi vlastnosti gpu

wessan

Level

2. 5. 2006 10:15

Komentáře tohoto uživatele máš zablokované.

@wessan jeste dodam, ze se jedna o MIMD architecturu - Multiple Instruction Multiple Data - tj vice instrukci na vice datech ... znamena to ze na kazdem jednom v pixelu z te rady nactenych (multiple data) se spusti prave programatorem napsany shader (multiple instruction)

Rafan

Level

2. 5. 2006 07:54

Komentáře tohoto uživatele máš zablokované.

Nejsem si stopro jistý ale někde jsem četl že hlavní autory Itánia přetáhlo AMD k sobě.

wessan

Level

2. 5. 2006 01:36

Komentáře tohoto uživatele máš zablokované.

vypada to pro ni blede ... coz je celkem skoda, protoze je daleko lepsi nez x86, halvne po architektonicke strance ... inzenyri intelu na ni odvedli spickovou praci ... takze skoda chybejiciho sw

tief

Level

2. 5. 2006 08:46

Komentáře tohoto uživatele máš zablokované.

@wessan To bohužel není až tak docela pravda. Itanium je jistě zajímavý produkt, má ale jednu vadu, která mu zcela brání v tom, aby byl použit na desktopech. Tou vadou je, že nemá dekódování - instrukce jsou přímo posílány do výpočetních jednotek. O konkrétní naplnění jednotek se stará kompilátor při vytváření programu. Pro dosažení optimálního výkonu je tak zapotřebí pokaždé pro nové jádro program překompilovat (proto Intel od dob původního 1 GHz Itania II skoro nic nezměnil, jen přidal cache). To v desktopech nelze realizovat, neboť většina kódu není (z pochopitelných důvodů) distribuována formou zdrojáků a navíc co by na to řekli typičtí uživatelé, kteří jen chtějí něco zapnout a jinak se o to nestarat? Itanium by bylo možná dobré pro Linuxovou komunitu, ale pro Windows určitě ne. Navíc by znemožňovalo konkurenci, protože oba výrobci by museli dělat totéž.

Mimochodem, tak jak Itanium stojí a běží dnes, je vhodné pro náročné vědecké či serverové aplikace s velkým paralelismem. Typický desktopový program ale chce úplně něco jiného - rychlé sekvenční vykonávání. Paralelismus je u desktopu jakousi formou luxusu, která zvyšuje výkon.

wessan

Level

2. 5. 2006 10:11

Komentáře tohoto uživatele máš zablokované.

@tief mluvil jsem o tom, ze ma dobry navrh, ne o tom, ze je dobre zpetne kompatibilni ... nebylo by potreba psal kompilator znovu pro kazde Itanium, protoze v ramci IA64 by byly procesory kompatibilni ... zde bych rad pripomenul, ze prave jazyky, ktere jsou distribuovany formou byte-code tento problem resi (napr. Java, protoze se vzdy kompiluji az na cilove plaforme a daji se dokonce optimalizovat pro velikost bloku cache apod)

add nema dekodovani instrukce: jedna se o RISC procesor takze je logicke, ze ji nema (pokud tim myslite prevod komplexni instrukce na microOPs, coz je fakticky CISC na RISC)

dalsi co procesoru chybi a je to dobre, protoze to zkracuje pipeline, snizuje spotrebu a zjednodusuje jadro, je out-of-order execution a pozastavovani pipeline pri datovych zavislostech (pocita se s tim, ze tohle by mel udelat kompilator a strojovy kod by mel byt uz takto osetreny) ... je logictejsi instrukce preusporadat jednou pri kompilaci, nez to delat pokazde na tomtez miste v kodu primo v procesoru

dalsi skvele vlastnosti - VLIW (paralelismus) a podminene instrukce (brutalne zrychluje kratke if statementy)

tief

Level

2. 5. 2006 10:23

Komentáře tohoto uživatele máš zablokované.

@tief Nevím, jestli jsem se dobře vyjádřil. Intel vyvíjí Itanium II už od jeho uvedení tuším v roce 2000 pouze tak, že mu přidává cache. Tím totiž brání potřebě kód překompilovat. Mezi Itaniem I a Itaniem II je velký rozdíl v počtu výpočetních jednotek. Pokud dáte Itaniu II kód vytvořený pro Itanium I, výkon nebude optimální. Samotné překompilování na nový model pomocí nového Intel Compileru přineslo tehdy nějakých 5 až 10 % výkonu navíc "zdarma". Z tohoto důvodu je zcela nezbytné pro každé Itanium mít vlastní kompilátor, který zohlední jeho výpočetní možnosti. Pokud kód nebude překompilován, spousta jednotek zůstane ležet ladem. Z tohoto pohledu se jeví x86 jako vhodnější architektura pro desktop, neboť ono sypání příkazů do výpočetních jednotek je čistě věcí hardware, který je pochopitelně optimalizován pro každou architekturu jinak, a tak dochází k vyššímu využití. I kdyby všechny programy byly dodávány se zdrojákem, ona kompilace pro Itanium je dost časově náročná, protože musí zohlednit závislosti, prefetch atd., tedy všechno to, co v x86 dělá (byť potenciálně s nižší efektivností) specializovaný hardware.

Itanium je VLIW (very long instruction word) procesor. Nazývat ho RISC je IMHO poměrně nešťastné, protože typické RISCové procesory fungují trochu jinak.

wessan

Level

2. 5. 2006 10:41

Komentáře tohoto uživatele máš zablokované.

@tief souhlas ... ono by bylo optimalni mit i u 386 na kazdy procesor zvlast kompilator (napr. na amd64 urcite aby se vyuzilo) ... prave proto je zde dobre reseni distribude byte-code (jen pripomenu ze posledni JavaVM uz jednou zkompilovane class uklada ve zkompilovane podobe a nemusi je pri kazdem spusteni kompilovat znovu - coz diky tomu, ze si muzete v Jave napsat vlastni ClassLoader bylo mozne uz davno, ale ted je to primo v dodavce) ... ano kompilace pro itanium je pomerne narocna, protoze dela vse co by procesor delal v realnem case, coz je ale z hlediska architektury dobre
add zlepsovani: ono na itaniu neni moc co zlepsovat, protoze novejsi design zatim neni znamy a cache (resp. jeji latence) byla tim co itanium brutalbe brzdila
add VLIW: ok beru ... ale VLIW je jen v podstate nekolik RISC instrukci velde sebe, takze se jen rozdeli napr. po 64bitech, ale dekodovat se stejne nemusi

btw: hodne zajimavy je i posledni UltraSPARC od Sunu, ktery je open source, ma podobne technologie a ma pri osmi jadrech spotrebu 72Watt a pritom kazde jadro dokaze plnohodnotne zpracovavat 4 vlakna - coz je 32 vlaken na procesor

tief

Level

2. 5. 2006 10:47

Komentáře tohoto uživatele máš zablokované.

@tief UltraSPARC a Itanium jsou procesory, které jsou optimalizovány pro multithreaded silně paralelizované použití. Troufám si tvrdit, že kdyby se typický program pro PCčka překompiloval pro Itanium, jeho výkon bude ve srovnání s Conroe ubohý - většina programů by prostě nedokázala šest ALU využít. A s multithreaded programy to nevypadá o nic lépe. Sice teď dual-core získávají na popularitě, z hlediska software se ale stále nic moc nezměnilo, a přínos dual-core je tak stále spíše u specializovaných programů a multitaskingu než v obecném zvýšení výkonu. Snad na tom něco změní Speculative precomputation.

wessan

Level

2. 5. 2006 10:58

Komentáře tohoto uživatele máš zablokované.

@tief mate pravdu vetsina her multithread nedokaze vubec vyuzit, tam by to bylo hodne slabe (na druhou stranu bych se nebal vyuziti vsech alu) ... nicmene uz jsou nove hry, ktere budou schopny vlakna vyuzivat a spustenych aplikaci je na jednom pocitaci samozrejme vice (kazda minimalne 1) ... server je samozrejme uplne jina zalezitost, kde treba pro kazde prichozi spojeni udrzujete jedno vlakno ... v takovych situacich je narust vykonu vice nez citelny a podpora vice vlaken je dokonce velka vyhoda, protoze je nemusite tak casto prepinat
do budoucna je multitread urcite dobra volba, ja jako programator v jave vyuzivam mnoho vlaken uz davno a to o tom ani nemusim vedet - garbage collector, gui se renderuje ve zvlastnich vlaknech, udalosti se zpracovavaji ve zvlastnich vlaknech, ...

speedsnail

Level

2. 5. 2006 00:55

Komentáře tohoto uživatele máš zablokované.

V hodnocení článku jsem omylem označil za 5 tedy jako nejhorší. Mělo být pochopitelně za 1 jenže vlevé části je to seřazeno od 5 do 1 a v pravé části kde se značí hodnocení je to obráceně a to mě zmátlo. Možná by to stálo za unifikaci.

tief

Level

2. 5. 2006 08:49

Komentáře tohoto uživatele máš zablokované.

@speedsnail V poslední době se to stává extrémně často :-(. Průběžně sleduji hodnocení článků a jasně z toho vychází, že třeba jeden dva lidé dají pětku, zatímco všichni ostatní jedničku. Nevím, zda jsou to omyly nebo chce někdo škodit, každopádně navrhnu nějaké zlepšení hodnotícího systému (například barevné odlišení).

tief

Level

2. 5. 2006 12:23

Komentáře tohoto uživatele máš zablokované.

@tief Tak už přibyla další pětka :-( . Aktuální skóre je (27x 1 + 2x 5) / (27 + 2) = 1,28. Škoda, zbytečně to snižuje hodnocení.

starmen

Level

13. 5. 2006 10:57

Komentáře tohoto uživatele máš zablokované.

@tief Tak zaveďte (teď nevím jak se této technice říká) to, že do výpočtu celkového hodnocení nezahrnete X nejlepších a X nejhorších výsledků.
Např. 1% nejelpších a 1% nejhorších výsledků dává, že při 100 hodnoceních by se do výpočtu nedostala jedna nejlepěí a jedna nejhorší známka.
Pokud by to byly např. 4%, pak se na každých 25 hlasů smaže jedna nejlepší a jedna nejhorší známka a vyšlo by Vám hodnocení ((27-1)x1 + (2-1)x5)/((27-1) + (2-1)) tj 1,15 .
Naopak pokud by někdo dostával horší známky, tak by mu to průměr zhoršilo.
Taková hranice 4% nebo 5% (na každých 20 hodnocení jedna nejlepší a jedna nejhorší pryč) je myslím ideální.
Myslím, že toto je celkem elegantní a hojně využívaný způsob.

Diskuze: Intel Core - pohled na architekturu I

Nejnovější komentáře

Nejčtenější obsah

Nejaktivnější čtenáři

Pokračujte ve čtení