Vlákno názorů k článku
Čína přichází s procesorem Godson 3
od Michal Smrž - To jsem zvědav, ale jestli se jim to...
-
Mard (neregistrovaný)Souhlasím. Je málo pravděpodobné že Čína udělá díru do světa s nějakým procesorem. To už zkoušela RVHP se šváby z CCCP a NDR a k čemu to vedlo. Pochybuji že by ten jejich čip byl opravdu dobrý vnitřně a pokud náhodou ano, asiati jsou inteligentní lidé, tak to nedovedou vyrobit v dostatečné kvalitě. Pochybuji že by uměli měď nebo Silion on Isolant.
-
jard (neregistrovaný)Ano, aziati su inteligentni, podla jednej americkej statistiky vraj priemerny aziat predbieha priemerneho belocha o 15%. Co povedala statistika o afr(oamer)icanoch neprezradim, aby ste ma neobvinovali z rasizmu. Technicky pokrok ale nastava najma vdaka jedincom mimo priemeru, preto by nas skor mala zaujimat disperzia rasy nez stredna hodnota:)
Pokial ide o kvalitu - cele je to otazka toho, aku kvalifikovanu silu chcete zamestnat. Neviem ci sledujete ekonomicke dianie v Cine, ale v chudobnejsich provinciach mladi miesto chodenia do skoly chodia do fabrik pracovat, aby mali na jedlo. Su schopni vyrabat aj kvalitne, ak nasadia spravny proces a spravnych ludi...
Spominany procak ale skonci v dakych uzavretych rieseniach, od prichodu x86 vacsina architektur takto skoncila :-/
PS: Mark Twain: “There are three kinds of lies: lies, damned lies, and statistics.” -
petr (neregistrovaný)Nazdarek, od Deda Kenedyho to byla jiste trochu nadsazka, nicmene projdi si par "žurnálů" treba na Elsevier a pod... Za ruzne vedecko-vyzkumne instituce USA tam velmi casto publikuji panove se jmenem Lee, Soni, Zhao, Ghattas, Jaramaz, ... a spousta dalsich, jejihz jmena cosi napovi... :). Ovsem, obcas se najde i nejaky ten Thompson a podobe :).
-
qwert (neregistrovaný)Co vim, tak CCCP delalo kopie Z80 a to doslova fotokopie, kdyz odbrusovali vrstvy z Z80 porizene na zapade a fotografovali. Neni to zas tak silene, postup sem si overil u telefonich karet, kdyz sem badal jak asi funguji a na jednom integraci, staci detsky mikroskop. Neda se to povazovat za vlastni vyvoj. Ikdyz jentak z principu nepochybuju, ze by Cina nejake kopie Intel nebo AMD procesoru nemela.
-
ABC (neregistrovaný)Proč tolik rasismu? Čína je technologicky vyspělejší než ČR a představa, že tam sází rýži a teď se najednou vrhnou na procesory, je absurdní. Bylo by to vtipné, kdyby to nebylo tak rasistické.
Mimochodem, NAND hradla se od cca 70. let nepájí, ale osvěcují, leptají, napařují, atp. (přesný postup neznám) na integrovaném obvodě. -
anonymníZastaralou x86 máme také díky programátorům co dělají programy pro MS Windows. Šířili binárky, které prostě na IA64 neběžely. Takže kdo koupí počítač s procesorem na kterém nepoběží jeho oblíbené programy. AMD to udělalo chytře. Vytvořili 64 bit procesor, na kterém běžel zastaralý 32bit MS Windows i 32 bit aplikace. Mimochodem dodnes spousta programu pro MS windows stéle běží v 32bit emulaci. Tvůrci software pro MS Windows často dokáží utopit výkon procesoru i kapacitu paměti, ale na 64 bit ještě většinou nepřišli.
Třeba MIPS procesory jsou ve spoustě zařízeních. Pod stolem se mi válí WiFi router právě s MIPS procesorem. A používám ho jako malý server. Dale tady mám zařízení s procesorem od Freescale (drive Motorola). Používám Linux a je mi jedno na jakém procesoru zrovna běží. Důležitá je pro mě spotřeba, výkon, cena.
A představte si jak by se prodával desktop s MIPS procesorem. Windows na tom nepoběží, ... už to je argument aby to většina prodejců neprodávala. Bohužel, ale je to tak. Dokud na tom nepoběží Windows a aplikace pro něj tak v desktopovém nasazení Intel a Amd nepřeválcuje. Leda že by konečně Windows přešel na druhou kolej. -
LENIN POWER! (neregistrovaný)Dlouho se jiz suska ze budto SUN SPARC nebo POWER/POWERPC procesory se budou pry montovat do patic pro AMD procesory aby se tak daly pouzit stavajici komodity desky. Predpokladam ze ale bude potreba tam dat jiny BIOS a bude tam behat jen linux.
U SUNu bych to snad i cekal, ale od IBM? Ti jsou prilis opatrni na to aby si nezkazili svuj System p byznys. -
JaR (neregistrovaný)Panbuh zaplat ze IA64 nemame. Nejhorsi CPU soucasnosti, a to bez prehaneni, s vykonem plne zavisle na prekladaci bez toho, aby nabizelo cokoli lepsiho, nez konkurenti, kteri takovou zavislost nemaji. Od pocatku se potyka s potizemi a bezproblemova verze (a prvni operacni system ktery ho plne vyuziva) je snad jeste vetsi vaporware nez SUNovsky Rock. Prvni soft s kompletni optimalizaci pro IA64 bude asi az Hurd 1.0.
Me osobni zkusenosti jsou neslane, nemastne. Ano, v HP Integrity to bezi docela stabilne, problemy zadne zvlastni, ale to je u tehle kategorie celkem norma. Kde je ale ten ohromujici vykon? Slaby prumer, delej co delej, za stejne penize da vetsi ranu i SUN/Fujitsu nebo dokonce X86_64, o Power6 vubec nemluve. Ne nadarmo pouzivaji vsichni konkurenti do jednoho pokazde srovnani vykonu s IA64, kdyz chteji vypadat co nejlepe. -
Suchý čert (neregistrovaný)No to právě že moc efektivní není, tohle rozbíjení instrukcí, out-of-order zpracování instrukcí a další optimalizace zabírají na čipu spoustu místa na úkor samotných výkonných jednotek. Vývoj většiny ostatních procesorů se ubírá opačným směrem, optimalizace se přesouvají z procesorů do překladačů, např. IBM přešlo u Power6 na in-order zpracování, stejně tak i Sun u Niagary a Intel u Itania.
U x86 tohle bohužel dost dobře nejde, jednak na to samotná instrukční sada není příliš vhodná (vhodná je RISC sada se spoustou registrů, tedy pravý opak x86) a druhým problémem jsou existující (neoptimálně) zkompilované aplikace, které by na takovém procesoru běžely pomalu. Viz Intel Atom… -
BLEK. (neregistrovaný)U optimalizace kompilátorem nevíš, která data budou v cache a která ne --- takže ty instrukce nijak inteligentně přeházet nemůžeš.
Na X86 máš třeba instrukci "prefetch", která nahraje data do cache --- má to problém, pokud data už v cachi jsou, tak tato instrukce nezrychluje, ale zpomaluje. Takže ji kompilátory stejně negenerují, protože neví, kdy ji mají vygenerovat, aby to nezpomalovalo. -
BLEK. (neregistrovaný)BTW. to rozbíjení instrukcí na mikroinstrukce je efektivní. Vzpomeň si na Pentium-4 --- to ukládalo už dekódované mikroinstrukce rovnou v L1 trace cachi. Mělo to podstatný problém, ta trace cache zabírala několikrát víc místa než by zabírala běžná L1 cache s X86 bytekódem, jako mají ostatní procesory. Pak na tom čipu neměli místo na datovou cache, trace cache na mikroinstrukce zabírala asi 80kB. Na datovou cache zbylo pouze 16kB (u prvních verzí dokonce jen 8kB).
Takže se toto opustilo a Core2 už zase ukládá do L1 cache bytekód. A instrukční i datová cache mají 32kB. -
Suchý čert (neregistrovaný)Tak z toho mi nějak nevyplývá, že rozbíjení instrukcí je efektivní. Ono asi samotný koncept trace cache se moc neosvědčil (proč nemá Core 2 trace cache na x86 instrukce?), nehledě na to, že ty mikroinstrukce byly obrovské (pokud vím, tak jedna mohla zabírat až 16 bajtů), to se vůbec nedá s RISC instrukcemi srovnávat.
-
BLEK. (neregistrovaný)Pointa je v tom, že kdybys zahodil X86 instrukční sadu a začal to programovat rovnou v těch mikroinstrukcích, tak ti velikost kódu několikrát naroste. Pentium 4 před prescottem mělo 36 bitů na mikroinstrukci (16 - konstanta, 20 - kód), přičemž u mikroinstrukcí s konstantami >= 32768 nebo < -32768 si umělo půjčit slot od vedlejší. Prescott má 32-bitové konstanty a nevím jak velký kód (za předpokladu, že taky 20 bitů, tak ta trace cache o 12280 položkách sežere 80kB).
X86 instrukce, která třeba něco nahraje ze zásobníku a udělá nějakou opraci (třeba ADD EAX,[ESP + 8]) zabírá 4 byty a po dekódování ti zabere dva mikroinstrukční sloty. Instrukce dělající operaci mezi dvěma registry normálně sežere 2 byty a po dekódování 1 slot o velikosti 36 nebo 52 bitů. -
Suchý čert (neregistrovaný)Ale na Prescottu tedy jedna mikroinstrukce zabírala vždy právě jeden záznam a instrukce s 64bitovými konstantami to rozbíjelo do více mikroinstrukcí. Takže s těmi 16 bajty jsem to trochu přehnal, no, maximálně jedna mikroinstrukce mohla zabrat 106 bitů (74, když nepočítám address tagy). :-)
ČLÁNKY DO MAILU