Názory k článku
Techniky zvýšení výpočetního výkonu mikroprocesorů

Skvělý článek, skvělý seriál. Kvůli tomuhle seriálu jsem zase začal chodit na root.cz. Je možno autorovi nějak jednoduše poslat malý honorář?

Diky, ale to snad ani neni potreba :-) Ale jestli jste z Brna a okoli, muzeme zajit na pivo :-)

Hmm, bydlet v Brně má zjevně nezanedbatelné výhody... ;/ ;-)

jj, autobus cislo 42 a pekne zaokrouhlena cena v restauraci (platils tusim rovnych 256 Kc ne?)

Jojo, přesně tak. :-)

No, bohužel. V mém rajonu je Olomoucko a Ostrava. Ale do Brna bych se mohl někdy podívat. Dám vědět.

Jako obvykle skvely clanek.
Ale nebylo by lepsi nez rovnou skocit na vektorove procesory zustat jeste u pipelineingu. Rict si neco hazardech a jak se resi. Popsat co je superpilina a suprskalarni procesor.

Dobre, ja se k tomu klidne jeste vratim. Superskalarnimi CPU se jeste budu zabyvat.

Já bych jen doplnil, že 5V Vcore nebylo až do příchodu Pentií ale už některé verze 486 DX2 a všechny DX4 či DX5(Am586 PR75+) používaly 3.3V Vcore. To jen tak pro přesnost :)

Ono to nesouviselo se změnou CPU architektury jako takové, spíš se změnou příslušných elektrotechnických norem... už jsem nějakou dobu z oboru a tak to nejsem schopen odcitovat přesně, nicméně, v kritické době bylo standardní napětí změněno z 5V na 3,3V.
Proto byly na toto napětí "backportovány" i 486, kterým jinak těch 5V nezpůsobovalo velké problémy.

"Standardní napětí"? Jaké standardní napětí? U pětivoltové TTL je standardní napětí 5 V, u třívoltové 3,3 V. Jaká norma se podle vás měla měnit? Že by někdo normou nařídil, že od nového roku bude standardním napětím pětivoltové TTL 3,3 V se mi nějako nechce věřit :-)

Věřte tomu, že když se skupina výrobců na změně napětí ve svých výrobcích k určitému datu dohodne, tak že se příslušné napětí opravdu změní. A většinou si to i nechají posvětit od nějaké nezávislé organizace, která v tomto duchu vydá příslušný "papír".

Ze stejných důvodů např. implementace PCI 3.0 jede výhradně na 3,3V a byl to i jeden z vedlejších důvodů pro zavedení SATA (byť tam se to tak docela nepovedlo - ovšem to by bylo na zcela samostatnou debatu).

Mám ten pocit, že 486ky na 3,3V opravdu přišly až po těch prvních Pentiích. Zatímco se Intel tlačil na trh Pentia s lepší architekturou, pánové od AMD šli cestou snižování spotřeby a zvyšováním frekvence starších osvědčených 486tek. 486ky od AMD dlouho a úspěšně Pentiím konkurovaly, což také srazilo cenu počítačů. Ve své době šel počítač s 486DX4/133 sehnat o dost levněji než podobně výkoný s Pentiem 66.

Ale ta první Pentia byla 5V. 486 určitě přešly na 3,3V dříve než Pentia.

Podle CPU-collection Pentium bylo uvedeno na trh 22 května 1993. To byla ještě 5V verze (tuším že to byly jen 60-66MHz) ostatní měly už 3,3Vcore kvůli zmenšení výrobního procesu a pro dosažení vyšších frekvencí - kdyby se 5V nesnížilo (jako z 12V na 5V v dobách 8bitů - třeba čs. PMD 85 má ještě v CPU napětí i -12V k 5V ). Doma jedno P66 na 5V mám a byl to v desce opravdu dobrý pekáček :). V té době 99% 486 co Intel dělal bylo 5V. Ovšem 3 května 1993 byla uvedena 486DX2 40MHz verze na 3,3V, takže 3,3 V 486 byla (alespoň teoreticky) dostupná přece jen pár dní před vydáním Pentia.http://www.cpu-collection.de/?tn=0&l0=co&l1=Intel&l2=i486+DX

March je březen. ;-) Mimochodem, to je pěkné, jak tehdy byl 16W procesor za „topení“ a dnes se 45W procesory označují jako Energy Efficient a do 16 W se sotva vejdou ty nejúspornější procesory určené pro notebooky. :-)

Vezměte v potaz, že v té době se nezměnilo "jen" napájení procesorů, ale třeba i napájení PCI (PCI byla původně 5V).

Ono to především souviselo s tehdejší vlnou "zeleného šílenství" a se snahou postavit úsporný počítač (a mít na to zároveň nějakou pokud možno jednotnou normu).
Ve světle pozdějších událostí to sice působí až lehce komicky, ale přesně taková nálada tehdy před 15-ti lety panovala.

No, nevím, ale řekl bych, že za snižováním napětí jsou trošku pragmatičtější důvody - je to prostě z technologického hlediska výhodnější (možnost zmenšit průřezy vodivých drah na chipech a pod.)

Pro tuto změnu prostě nazrál čas. Vždy jde o synergii několika různých vlivů najednou...

Rekl bych, ze PCI s napetim 3.3 V se rozsirila az trochu pozdeji, pocitace z teto doby (Pentia/ Pentia 2) maji vetsinou 5 V.

Neexistuji nejake? Zvetseni poctu neuronu a zmenseni tloustky nervovych vybezku? Zvyseni poctu mozkovych zavitu?

Dnesni programatori spatlaji nejaky moloch v .NET nebo Jave nebo C# nebo PHP a pak ani gigahertzove procesory nepomahaji.

ano, napr. nektere drogy to docasne vyvolavaji(i kdyz je to subjektivni nazor), ale je lepsi kodovat zhulenej nez ozralej

s tymm zhulenim som si neni isty...
raz som nakodoval nieco zhuleny a pekne to fungovalo, len v normalnom stave som nebol schopny pochopit ako to funguje a preco

Ballmer peak: http://xkcd.com/323/

To je velmi častý, rozšířený omyl. Programátor "pán" něco zbastlí a myslí si, že "sluha" počítač to skousne. Neskousne... Je potřeba synergie.

To je rozsireny nazor typickeho softwaroveho s prominutim prizdisrace.
Podle toho pak ten software vypada.

No, Clock zrovna jak kůň v ASM/C dře a vydělává o dost víc než .NET, JAVA, PHP kodér (sám jsi tvrdil, že kodér je u vás ve firmě až na posledním místě).

Od určitého počtu prodaných zařízení se vyplatí najmout si drahé ASM programátory a díky nim to zařízení udělat o pár euro levnější.

No bez programatoru v ASM a C by nejely ani ty slavne desktopove pocitace ;-), takze ty kecy o tom, ze dnes pouze Java ci .NET muze rikat jen naprosty neznalec dnesniho stavu veci. Staci se na sve "nadupane" PCcko podivat a je to jasne.

A co je na tom divneho? Bud chci vyvijet rychle za cenu pomalejsiho programu (tzn. volim managed jazyky) a nebo optimalizuji , vyvoj je 10x drazsi, ale program rychlejsi:) Vzdycky to zalezi pouze na tom, co chci delat a co se mi vyplati. A vzhledem k tomu, ze je vypocetni vykon pomerne dost levna zalezitost, tak jazyky ala Java ci C# pochopitelne slavi uspech :)


Nicmene zpraseny program neni ani tak otazka jazyka, jako programatora, udelat nepouzitelne pomaly program se da v jakemkoliv jazyce...

Teda chlape, jestli taky děláte data mining, statistiku, lingvistický algoritmy a vyhledávání, a přitom je pro Váa "výpočetní výkon poměrně levná záležitost", tak Vám teda docela závidím. :-) S tou druhou částí souhlas. ;-)

Nevim co resite, optimalizuje se (a mozna mnohem vic, lip a snadneji :-) ) i pokud clovek pouziva jazyky nad kteryma se ne-prizdisraci ofrnujou.

vzyt je uplne jedno, v cem je program napsany. dnesni hw je tak levny, ze je uplne jedno, jestli se programuje v asm nebo c#.

ale asi spis mas na mysli rozdily ve volbe algoritmu. malo kvalitni programator zprodukuje zpraseny a pomaly kod klidne i v tom asm. pricemz typickym prikladem je velka cas oss, na kterem se tenhle typ lidi uci programovat. :-((

No ne vzdy je HW tak levny, ze nezalezi na optimalizacich, dokonce ve vetsine pripadu je tomu prave naopak. Nekdy ani nejde tak o cenovou laci jako o to, ze proste silne procesory jsou velke a strasne zerou (=vyzaruji teplo, ktere je nutne nekam odvest), to se pro mnoho zarizeni zrovna moc nehodi.

S druhym odstavcem souhlas.

To jsou kecy, staci se podivat na vistu. Nebo treba srovnat mplayer s wmplayerem a podobne. Proc myslis, ze moderni aktualni verze linuxu bezi na ASUS EEE a windows nikoli?

Souhlas. Ono pomalost software je mnohem vice dana dobou jeho vzniku nez tim, jestli je opensource nebo ne.

Navic, podle me, jestli jste dobry nebo spatny programator vam v tomto smeru dnes pomuze jen malo. Vetsina software se pise rychle za pomoci knihoven a frameworku, ktere jsou velice obecne (a pro dany problem zbytecne) a jejich chovani malokdy muzete odhadnout, dokud tu celou aplikaci neslozite. Driv se kazdy program psal od piky, a programator si to tedy mohl sam zoptimalizovat.

Chci tim rict, pomalost dnesnich aplikaci neni trivialni problem, a je dany tim, ze pozadujeme stale slozitejsi aplikace a knihovny, a nechceme pokazde znova vsechno stavet. Take k tomu prispiva fakt, ze u slozite aplikace si nemuzete udelat teoretickou analyzu, jak co dlouho bude trvat. Takze to proste vyzkousite a pokud to na vasem pocitaci rozumne chodi, je to v pohode. Ale pokud je to funkce v nejake knihovne, ktera je volana z jine knihovny, muze se vam bez problemu stat, ze se ta funkce vola 100x vic nez by mela, a pak uz to samozrejme poznat bude.

Zkratka - dnesni aplikace jsou slozite, tedy mate na vyber - bud to napsat odspodu optimalne (coz chce hlavne cas, dobre SW inzenyry a davku odvahy resit uz davno vyresene problemy), a nebo pouzit knihovny, cimz se zbavite porozumeni toho, jak vase aplikace vlastne funguje, a pak velice snadno dojdete do neoptimalniho stavu. Inteligence lidi je omezena a ani ti nejlepsi nejsou schopni se s timto problemem vyporadat.

Třetí přístup to je napsat co nejjednodušeji a nejpřehledněji (knihovny, GC, ...), profilovat a pak optimalizovat pomalá místa.

Ona stejně v naprosté většině případů (co jsem viděl) není pomalost až tak v jazyce jako v použitém algoritmu.

Naprosta pravda, optimalizovat bez profileru v mnoha pripadech nevede k cili. Mnohdy se az clovek divi, protoze ceka, ze tady a tady se program bude sekat (vnorene smycky atd.) a az profiler odhali, ze ve skutecnosti je to uplne nekde jinde. A kvuli pravidlu 90/10 (90% casu se stravi v 10% kodu) je opravdu lepsi se zamerit na problemova mista, nez ztracet cas optimalizaci neceho dalsiho. Druh

To neni treti pristup, mame na mysli ruzne urovne. Ja mluvim spis o navrhu, o uroven vys. To mate napriklad moznost pouzit obecne databaze nad SQL nebo si napsat vlastni. Pokud si napisete vlastni, mozna usetrite, protoze muzete jeji datove struktury a algoritmy prizpusobit na miru vasemu problemu. Obecna databaze je radove mene prace, ale o rad pomalejsi. V obou pripadech muzete samozrejme profilovat a optimalizovat, ale radovy rozdil vam uz zustane, protoze vychazi z toho rozhodnuti.

Druha vec je, ze i s profilerem je malokdy citelne, co vlastne zpusobuje tu pomalost. Muze se vam snadno stat, ze nejsou zadna zjevne pomala mista, jenom ohromna hromada mist, ktera jsou trosku pomala (coz tezko poznate, jak moc ktere je, kdyz nemate srovnani), a tato hromada se vam nascita do jednoho velkeho bloatu. Tento typ pomalosti mi prijde nejbeznejsi v modernich aplikacich, a je velice tezke oznacit konkretni algoritmus jako vinika (protoze obvykle jsou v opravdu kritickych mistech pouzity rozumne algoritmy).

Ja myslim, ze to jde i na tehle urovni. Pokud nejprve pouziju databazi a zjistim, ze jsem pomaly, tak minimalne uz vim, jakou funkcionalitu tohoto typu potrebuji a bude se mi lepe psat nahrada (to ze to budu vedet na zacatku podle designu je skoro vzdy iluze). Podobne u knihoven - pokud je prilis obecne napsana, muzu funkcnost prepsat potom, kdyz uz vim ze to je problem. Nebo se muze ukazat jako lepsi pouzit cachovani/memoizaci, nebo partial evaluation techniky (vcetne treba predkompilace, to jde i u te DB).

S tim druhym bodem v zasade i souhlasim, zvlaste kdyz do hry vstoupi vypadky z kesi nebo dokonce swapovani. I kdyz si myslim, ze vetsinou je to "jen" otazka zkusenosti a dostatecneho usili.

a existuji uz nejake 128 bitove procesory?

mozna tak nejaka stara vykopavka ala IBM system/370 :-D

Prozatim pravdepodobne neni dostatecne silna poptavka a dual core 64 bit je tak lepsi nez single core 128 bit.

Asi vsem zatim staci SSE, kde tech 128 bitu je :-)

Jako zajímalo by mě, kde by našlo uplatnění pracovat se 128 bitovými integery. SSE je v tomto případě mnohem efektivnější řešení.

IBM System/370 je 32-bitovy, nikoli 128-bitovy. Itanium by slo nazvat castecne 128-bitovym, protoze jeho instrukce maji 128 bitu. A floating-point registry take.

V tom nejdůležitějším aspektu, což je adresový prostor, nebyl IBM System/370 32bitový, ale 31bitový (a nepíše se tam spojovník). A to až pozdější XA řada, původně měl dokonce jen 24bitové adresy.

To ja samozrejme moc dobre vim, kdyz programuji mainframy. :) Ale to neni to podstatne - i System/360 byl 32-bitovy procesor, ackoli mel 24-bitove adresovani. "Bitovost" procesoru delaji sirky sbernic (externich a internich) a tedy obvykle sirky registru.

No, jestli se počítají i herní konzole, tak v PS2 by měl být 128 bitový procesor Emotion Engine s taktem 300MHz. I Nintendo se může od roku 1999 pochlubit 128-bitovým procesorem na 400MHz s označením Gekko.

A v grafických kartách se používají i 256 bitové procesory, třeba NVidia s ním přišla už v roce 1999 - NVIDIA GeForce 256. A dnes už "mrtvá" Matrox Parhelia měla dokonce 512 bitový procesor.

No, tak pokud bychom to počítali jako u těch grafických karet, tak Core 2 Duo bude minimálně 768bitový procesor. :-) A ten Emotion Engine je 128bitový asi tak jako každý dnešní x86 procesor se SSE. :-)

Hmmm, core 2 ma 240* vic tranzistoru nez 486? To by me docela zajimalo, jak rychle by bezela ta 486, kdyby se vyrobila soucasnou technologii. A kdyby jeste clovek mohl mit na tom chipu 240 jader :-) .

Ty pocty tranzistoru budou zavadejici, vetsina z toho bude L2 cache.

Nektere levnejsi x86-kompatibilni SoC (System-on-a-chip) zhruba opovidaji i486 (resp. i386+cache). Bohuzel jsou vetsinou zamerene na maximalne usporny provoz, takze i kdyz jsou vyrabene modernimy technologiemy (kvuli spotrebe), nejsou vetsinou taktovane moc vysoko.

IMHO by 486 na dnešních technologiích a frekvencích nebyla žádná sláva, protože by to většinu času strávilo čekáním na RAM, protože má moc malou cache. Pokud by to mělo dnešní množství cache, tak už by to nebylo tak malé a výkon by stále byl horší než VIA C3. Přeci jen, 486 byl z dnešního pohledu moc jednoduchý procesor.

No jo, 486 uměla jen 1 instrukci na takt a její FPU je takové vylepšené 387 na steroidech :) O multimediálních instrukcích dnes hojně využívaných ani nemluvě. Však i Pentiu, které má na takt instrukce 2 stačí poloviční frekvence na stejný výkon...

Co se vůbec stalo s Transmetou? Kaput?

Podle http://en.wikipedia.org/wiki/Transmeta (tabulka vpravo nahore) to moc ruzove nevypada, i kdyz tady (http://investor.transmeta.com/releasedetail.cfm?ReleaseID=309136) jsou jiz trosku zajimavejsi cisla. V kazdem pripade je jich skoda...

Bezva článek, těším se na pokračování ;)

Na uvedene poradi fazi zpracovani instrukce jsem narazil jen v tomto clanku. Vsude jinde (napr. http://en.wikipedia.org/wiki/Classic_RISC_pipeline) je uvedeno toto poradi:
1. Fetch
2. Decode
3. Execute
4. Memory Access
5. Writeback
Rozdil spociva v prohozeni kroku 3. a 4. Muzete mi to prosim nekdo vysvetlit?
Dekuji

Obrazek je hezky, ale popis, co ktera barva znamena, jsem nikde nenasel, takove zvyrazneni je potom na nic. Byl by nekdo ochoten barvy popsat? Dekuji.

Zdravim, podle interniho schematu 6502 jsem si to odvodil takto:

- zelena: ROM pamet se sirokym formatem mikroinstrukci a organizaci 21x130 bitu
- hnedy mismas: dekoder a radic instrukci
- modro-zluty mismas: ALU
- napravo od ALU: akumulator a index registry
- cervena: interni datova a instrukcni sbernice