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

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

Jojo, přesně tak. :-)

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.

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.

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.)

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/

Proc by jsme meli drit jak kone a delat v ASM/C? Pocitace tu jsou pro nas a ne my pro ne.

LENIN
POWER

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.

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.

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.

a existuji uz nejake 128 bitove procesory?

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, 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.

Co se vůbec stalo s Transmetou? Kaput?

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.