![](/sites/default/files/tmp/carousel-63/images/shutterstock_1879485361.jpg%3Fitok=bi7g6nJk&c=9d83b34607fd25e96ac1940ec301014b "Jak vybavit dětský pokoj%3F "Nechte dětem volnou ruku," radí designérka")
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Tenhle zákon neplatil snad nikdy... Však se podívejte, co se v procesorech zvětšuje. Počet instrukčních jednotek je víceméně stejný, sčítačka je pořád stejně velká (a zvětšit ji nelze počtem tranzistorů, pouze zvýšit frekvenci, čímž stoupne sčítačí výkon, nebo paralelním použitím více sčítaček, což nebude mít vliv na rychlost jednoho součtu, a může sčítat paralelně jen dva různé, neovlivňující se součty), a to co roste, je cache paměť.... Bez ní by to nešlo, ale ona jediná se v poslední době zvětšuje, a dohání tak Moorův blábol. Jestli chápete, jak to myslím.
A nebo platí... On je hodně obecný... Ale je tu jednoduchá metrika, kdy se krok výrobního procesu zmenšuje, čili nutně musí narůstat plocha čipu - a ta, jak víme, je pro nás limitem pro funkčnostxvýtěžnost. Udržet tedy růst není problém, ale jít za 500 mm2 je pouze důkaz, že tak velké to vyrobit lze, ale rentabilní to být nemůže.
Už Mooreovi muselo být jasné, že cena výrobního procesoru bude exponenciální, a že zisk takový nebude, a že to tedy nepůjde... Ale asi nemyslel na vše, když svůj zákon formuloval. To byla chyba. Možná zbytečný předsudek, kterého se výrobci chytili, a ve snaze dodržet jej, sami sebe stavěli do svízelné situace, čipy plnili zbytečnými cachemi, atp...
Platí / neplatí, to co píšeš je pravda. On by (ve tvé první myšlence) platit klidně mohl, kdyby výrobci HW zvětšovali nikoliv frekvence nebo masivně cache, ale počet výpočetních jednotek. SPARC T5 má 16 jader, každý z nich umí 8 "threadů" (hehe, x86 pouze usmrkaných 2), to je 128 "nezávislých" výpočetních jednotek pro OS. To je krása.
Proč tohle není v x86? OS to zvládají několik desetiletí a je to poměrně jednoduchá technika, jak zvýšit výkon. Na low end x86 se pořád plácáme někde v bahně 4 jader. (nebo kolik je teď ten statistický střed).
Jenže to jsme u toho - s větším počtem jednotek nebude sčítačka sčítat rychleji, protože už nemá jak.
Upřímně nemám tušení, jak to je teď, jesli stále používáme sčítačku pro 1 binární řád, nebo kompletní 64bitovou sčítačku, ale očekávám to druhé. A nic jiného, než takt, už tu sčítačku nezrychlí. A více sčítaček nemá 100% škálování právě kvůli závislosti proměnných a vláken.
Jsme vlastně na konci, kdyprocesor už rychlejší být nemůže - i Core i7 9770 bude sčítat stále stejně rychle, respektive rychleji podle toho, jaký bude mít takt - zvýšit takt můžeme díky lepšímu výrobnímu procesu, ale né vyšším počtem jednotek.
128 nezávislých threadů je super - ale k čemu? Vlastně žádnou věc nemohou dvě jednotky dělat současně, protože jedna je závislá na tom, co spočítá druhá.
Bavíme-li se o grafice, tam je paralelizace vcelku jednoduchá - každá jednotka počítá jeden pixel, například, i když jsou tam opět určité faktory, které některé pixely svazují k sobě, a to nemluvím o antialiasingu... Jinde, mimo grafiky a serveru můžeme více jak 8 threadů uživit jen velmi, velmi těžce...
Přesně tohle mi říkali lidé před tím, než jsem si naplánoval a pořídil domů osmijádro ;-)
Ono těch programů, co to umí využít, je opravdu hodně. Vlastně, pokud to vezmu od zadu, tak zatím jsem si všiml pouze microsoftího update bazmeku, který jako jediný běží v pouze jednom pracovním vláknu (a tedy žere 12.5% CPU).
"Skoro" všechno ostatní, pokud potřebuje, umí jít mnohem vejš. Už třeba jen pořizování a vytahování zálohy her ve Steamu. LightRoom (jasně, grafika) co já vím minecraft (i když tam to pořád není nic moc, ale je zde velký potenciál (co já vím thread per chunk nebo něco v tom smyslu) apod.
Ale hlavně, proboha lidi, nemáme DOS. Už vám někdo řekl, že si těch programů můžete pustit víc současně? Já nevím, hraju si něco (třeba zrovna ten MC) a na pozadí mám puštěné co já vím, Handbrake s konverzí nějakého *castu apod.
A to jsem se omezil pouze na Windows. O linuxu snad ani mluvit nemusím (http://www.heronovo.cz/procesor-pro-linux/).
Nejsem programátor, ale jsou věci, které paralelizovat ani není možné, a jsou věci, které lze paralelizovat skvěle. Většinu ale nelze... A nebo nelineárně - tak, že můžeme ukousat pár drobných věcí, ale stále nám zůstane jeden velký, obludný thread, který prostě rozlámat nejde, a ty malé jsme sice oddělili, ale dohromady tvoří tak možná 10% všech výpočtů původního vlákna, a to nám nepomůže.
Třeba taková umělá inteligence by byla super, kdyby běžela naprosto paralelně, samostatně pro každou postavu, ale co já vím, počítá se AI vždy s iterací jádra, a nelze ji oddělit, protože ona by klidně běžet samostatně s nekonečnou rychlostí, a vytížit procesor na 100% - měla by jemnější kroky a přesnější chování. Netroufám si ovšem odhadovat, kolik výpočtů je potřeba pro jednu iteraci AI oproti všem ostatním výpočtům například v takové hře. Nehledě na to, že všechna AI se neustále ovlivňují. Pak je tam, nevím, třeba simulace střelby - opět asi věc, pro kterou může vždy jet samostatný thread, ale ten si stejně vždy musí posbírat stav všech ostatních AI, tudíž ty musí být v nějakém "vypočítaném" stavu, nemůže být výpočet nějakého AI právě v průběhu, což by paralelismus způsobil.
V programech taky.. Běžně používané věci moc náročné nejsou, napadá mě snad jedině excel, kde jsou závislé proměnné, nebo word, kde teda taky, paralelizovat kontrolu pravopisu po slovech asi zde, ale uvědom si, že spuštění každého threadu také stojí nějaký "nutný základ", nějaký prostor a režii procesoru, a to se nemusí vyplatit. Jsou tedy také věci, které paralelizovat jdou, ale nevyplatí se to, a tak zůstanou v jednom náročném a velkém procesu...
Jaký další běžně užívaný a náročný program tě napadá?
Já také nejsem programátor (nějaké pokusy na univerzitě nepočítám), jsem technik, správce serverů (linux). A ano, svoji profesionální deformaci z tohoto povolání se ani nepokouším skrývat.
Ano, některé algoritmy lze paralelizovat snadno, některé vůbec. Kolik je kterých si netroufám odhadnout. Ale. Pokud nějaký problém nelze paralelizovat, tak dva (a více) běžící procesů lze paralelizovat naprosto triviálně.
Naposledy jsem takto převáděl flac na něco, co umí iPad (asi mp3) a sekvence vypadala nějak takto: flac -> wav -> mp3 (flac -d; lame --preset insane). Dva procesy na jeden hudební soubor, na osmijádru se tahle dvojice dá pustit 5x (samozřejmě ještě nad tím byla fronta čekajících souborů). Snažím se dodržovat pravidlo N+1 pro optimální vytížení CPU, ne vždy je to ale nejefektivnější. V tomto případě tedy běželo 10 pracovních procesů. Tohle je ukázka paralizace procesů, které jsou všechny single thread (buď tedy nejdou paralelizovat, nebo to prostě nemá smyl).
Tohle je ale trochu jiný typ paralelizace - málokdo si takto paralelizuje například PC hru...
Navíc zrovna převod zvuku - stačí rozsekat na části, a každá se může převádět v jiném threadu... To dnešní editory ještě neumí, ani ty placené?
"Tohle je ale trochu jiný typ paralelizace"
Souhlasím. Ale je to ukázka, jak lze naložit s problémem, kde daný algoritmus nejde paralelizovat.
"To dnešní editory ještě neumí, ani ty placené?"
Co já vím, proč bych si za tohle měl platit?
Protože zadarmo se s tím patlat asi někdo nebude, a učit to multithreadingu, ale ty placené už to celkem dobře zvládají..
Tvá paralelizace je "zřejmá" :P
Zrovna případ s AI je na pro paralelní výpočty jak dělaný. Když počítáš chování entity, tak ona reaguje vždy na předešlou iteraci, čily na stav, který už zná. Aby hra byla aspoň trochu realistická musí dodržovat princip kauzality.
Od toho MS bazmeku je naopak hezké, že se nesnaží nesmyslně stahovat ve více datových proudech, a že se nesnaží na jeden disk instalovat ve více instalačních proudech.. Takový update operačního systému je zrovna věc, kterou je nejlepší udělat v jednom threadu, pěkně krok za krokem, a bez chyb.
Však to také nebylo hodnocení špatné / dobré.
Jinak za tu dobu, co MS Installer instaloval updaty na systémový SSD, tak měl Steam hotové rozbalení všech her (175GB) na běžný 7200RPM.
"kterou je nejlepší udělat v jednom threadu, pěkně krok za krokem, a bez chyb."
No a nebo třeba taky transakčně (pomocí snapshotů). ;-)
Instalace updatu taky není jen nakopírování dat, ale změna konkrétních dat v konkrétních místech, řešení (ne)přístupu k nim během jejich updatu, aby nedošlo ke ztrátě integrity, atd... Ale pomalé jsou, to je pravda.
Transakčně si to nějak nedovedu představit. Zapisovat na disk ve více proudech je zbytečné, takže jakou výhodu by tady měl jakýkoliv vícevláknový přístup? Možná tak, pokud se na místě ještě něco kompiluje, tak se to v dalších threadech může kompilovat, ale to je tak vše.
A k čemu ti těch 128 jader (nebo klidně i víc jak 4-8 - a i to už je kromě hraní her a encodingu videa hodně overkill) na osobním počítači bude?
Oracle na tom provozuje db s hromadou tabulek kde každé jádro může zpracovávat jeden dodat do db (to je asi tak to nejjednodušší, co si dokážu představit).
Pokud nejsi programátor/tester a neprovádíš doma performance testing nějakých opravdu mohutných systémů, tak ti jsou ty jádra k ničemu. Ještě tak si dokážu představit víc jader pro použití při práci s videem, ale tam bych neřekl, že 128 jader (opět jen předpokládám - se slabou výpočetní silou ve floating point operacích) bude silnějších než 4-8 jader x86 architektury se specializovanýma instrukcema.
Prostě jsou to procesory z naprosto různých světů které se moc neprolínají.
Delas stejnou chybu jako lide, kteri pred par lety stejnymi argumenty dokazovali, ze 4 jadra pro domaci pocitac jsou k nicemu. Ano, pro domaci pocitac je vhodnejsi maly pocet silnejsich jader s vysokym vykonem v jednom vlaknu. To ovsem neznamena, ze se k tomu poctu 128 nikdy nedostaneme - at uz jako 128 silnejsich jader nebo treba jako 16 silnejsich "full" a 112 slabsich ... samozrejme graficke karty budou v te dobe mit jader nejmene 4096.
Už kolem roku 2000 jsem chtěl do PC dva procáky, protože systém na tom prostě behal mnohem líp (osobní zkušenost z práce a win2000).
Nepopírám výhodu dvou až čtyř (spíš těch dvou) jader pro normální domácí využití. Problém je, že to co dělá s PC 99% lidí už dnes zvládají procesory levou zadní podtaktované v úsporných režimech, případně to za ně dělá grafika a její dedikované obvody.
Když někdo potřebuje vyšší výkon, není problém si koupit silnější vícejádrový procesor. Problém je navrhnout úlohy tak, aby úkoly ty jádra využily.
Matematické a logické principy neošulíš, takže na hromadu aplikací víc jader prostě nevyužiješ a je lepší právě to jedno rychlé. Také vycházím z toho, že ten 128 jádrový procesor bude +- stejně velký jako nejlepší x86 procesory, takže logicky vyjde na jádro míň obvodů a pak není tak silné (pro využití ve své sféře je ale silné dostatečně).
Prostě ten kus křemíku můžeš porozdělovat jak chceš, ale o moc vyšší hrubý výkon z toho prostě nedostaneš - můžeš jen optimalizovat pro různé využití.
Proč x86 neumí více než 2 vlákna na jádro? Nejspíš proto, že by to nepřineslo žádné další zvýšení výkonu. Nezapomeň, že ta další vlákna v jádře mohou využít pouze ten výkon, který je k dispozici ve chvíli, kdy jiné vlákno čeká na načtení dat z hlavní paměti. Současné x86 CPU se se snaží o to, aby vlákno mělo vždy k dispozici potřebná data, tzn. pro snížení latencí čtení z RAM mají integrovaný řadič paměti, pak taky mají HW prefetch , velké L1, L2, L3 cache, predickci větvení, OoOE atd.
SPARC T5 používá trochu jiný přístup, jádro se moc nesnaží o to, aby vlákno mělo k dispozici potřebná data, takže se často může stát to, že vlákno bude muset dloho (několik set taktů)čekat na načtení dat z RAM. Těch 8 vláken u SPARCU je tedy taková z nouze cnost, bez nich by jádro skoro furt nemělo co dělat.
Počet výpočetních jednotek taky nelze moc zvětšovat, tak aby to vedlo k nárůstu výkonu, na to dojela architektura Itanium.
Zajímavé je že obě architektury vycházejí z RISC ale vnitřní hierarchie čipů je velmi odlišná. Odlišný je také softwarový ekosystém na kterém tyto procesory běží.
"Proč x86 neumí více než 2 vlákna na jádro?"
V tom případě pro nemá 128 plnohodnotných jader? ;-) Ano, narážíme pořád na stejný problém x86 architektury, která nebyla pořádně stavěna na multiprocesor.
Fakt se těším na nějakou pořádnou nakládačku od ARMu. Před lety se objevil 512 atomový server, teď je nějak ticho po pěšině. No nějakej server postavenej na Cortexech se sice objevil, jen houšť a větší kapky.
64 jader nestačí? A jediný důvod proč Xeon Phi má pouze 64 jader je omezení spotřeby chipu na 300W.
Co to podle vás znamená že je architektura stavěna na multiprocesor?
Taky se podívejte na statistiky architektur CPU v superpočítačích, architektura x86 suveréně drtí všechny ostatní.
Jenže Phi má opravdu jenom velice základní podporu x86 instrukcí, nezná moderní instrukce které používají současná x86 CPU a jeho výkon plyne hlavně z nových 512-bit SIMD, které jsou se současnými x86 CPU nekompatibilní :o)) čili vše se musí překompilovat .
V principu je to stále více blíže původnímu konceptu Larrabee jako GPU než x86 procesoru.
"Each of these cores is a 64-bit x86 core. However, only 2% of the core logic (excluding the L2-cache) is spent on x86 logic. The SIMD unit does not support MMX, SSE or AVX: the Xeon Phi has its own vector format"
http://www.anandtech.com/show/6451/the-xeon-phi-at-work-at-tacc
"Ale asi nemyslel na vše, když svůj zákon formuloval. To byla chyba." Naopak, jeho předpověď vykazuje známky geniality. Musíte si uvědomit zcela zásadní věc. V roce 1965 byl trh s procesory absolutně jiný než teď a Moore mohl jen tušit (nevím jak), že v každé domácnosti bude minimálně jeden počítač a mobily budou mít několikajádrové procesory. Jen brutálně rostoucí trh umožnil jeho platnost až dodnes. Jenže nyní není kde růst, součástky zůstávají na skladech a prodeje klesají. A i kdyby poptávka vzrostla, tak je co prodávat, pochopitelně za svou cenu.
Moorův zákon je geniální, i když jeho tvůrce přišel k věhlasu jako slepý k houslím.
Problém neplatnosti Mooreova zákona není v malých prodejích, nýbrž ve výtěžnosti čipů, kdy velký čip prostě nelze 100% vyrobit, protože šance na chybu je exponenciální vzhledem k velikosti čipu. A také proto, že se blížíme (a on musel vědět, že se někdy přiblížíme) k hranicím fyzikálních možností materiálu - odhaduje se, že konečná bude někde u 10 nm, a čím blíže k této hranici budeme, tím menší kroky můžeme za stejný čas udělat, což také děláme. A s tím kdyby počítal, takový zákon by neformuloval. Vlastně je to jen výrok, a né zákon, ale to nevadí. O limitech materiálu pravděpodobně nevěděl, nebo si je neuvědomoval, protože o atomové struktuře látek se jaksi vědělo už dávno, a že atom má nějakou veikost... A ať najdeme jakýkoliv materiál, bude mít nějakou velikost atomu, kterou to skončí, a ke které se budeme blížit pomaleji a pomaleji, atd...
Ano, je to jen výrok, který, kdyby přestal po pátém cyklu platit, tak se na něj zapomene a nikomu by nechyběl. Materiálová omezení tady jsou, ale to z jeho hlediska není podstatné, protože to se pak u naprosto všech technologií můžeme bavit o omezeních fazikou. Platnost zajistil tomuto výroku pouze trh. Čili Moore musel tušit něco, co v roce 1965 moc lidí netušilo. Ta omezení, která zmiňujete, mohla být klidně vyčerpána až v roce 2080, jenže to byl pouze trh, který zaručil to Moorem předpovězené tempo. Možná v tom samém roce nějaký Franta řekl, že se počet zdvojnásobí co dva roky. To bychom zde měli začínající Pentium (hrubým odhadem). Jde o to, že Moore pravdu měl a Franta ji neměl. :-)
Dobře dobře.. Ale říkáš také, že je to trh, kdo právě platnost tohoto zákona ukončuje, resp. nedovoluje mu pokračovat. Ale je to fyzika, která za to může :) Trh je v tom teď nevinně.
To ano. Ale i tak může být Moore na sebe hodně pyšný, zvlášť když se toho dožil. A na hrobě může mít napsáno "Porazila mě jen fyzika" :-)
moment, tejto logike nechapem:
"krok výrobního procesu zmenšuje, čili nutně musí narůstat plocha čipu"
to je odkial toto ?
to sa priamo vylucuje s tym uz len ked poorovnam plochu 28nm cipu GTX680, ktory ma viac tranzistorov ale je mensi ako 40nm GTX580 ktory ma menej tranzistorov ale je väcsi...
plocha cipu moze ostat uplne rovnaka roky rokuce
jedine co sa mni zmensovanim vyrobneho procesu je hustota/mnozstvo tranzistorov na tej ploche
a dalsia veta:
"Tenhle zákon neplatil snad nikdy... Však se podívejte, co se v procesorech zvětšuje."
ty si tomu vyroku asi absolutne nepochopil...
v tomto vseobecnom a konkretnom pripade vobec nezalezi na tom co sa v procesoroch zväcsuje...
ide o pocet tranzistorov na cipe ako takych a je uplne jedno na co su urcene
ten zakon resp. vyrok nie je technickeho rázu, vobec nehovori o tom ci maju byt tie tranzistory urcene na cache alebo ALU, hovori len o tranzistoroch procesora.
"Jsme vlastně na konci, kdyprocesor už rychlejší být nemůže - i Core i7 9770 bude sčítat stále stejně rychle, respektive rychleji podle toho, jaký bude mít takt"
- ano ? postavme si vedla seba poslednych 5 generacii procesorov na ROVNAKOM TAKTE, preco sa aj v zakladnych operaciach od seba vykonom tak lisia ?
- rychlost spracovania instrukcii je urcovana aj inak ako len jednoduchym taktom
"krok výrobního procesu zmenšuje, čili nutně musí narůstat plocha čipu"
To jest odtial, pokud se počet tranzistorů zdvojnásobí.... Samožejmě pokud zůtane stejný, čip se s menším procesem zmenší, ale Mooreův zákon neplatí.
Ano, nepochopil, proto jsem se doplnil. Otázka je, jestli zvětšující cache je samovolná, nebo je to důsledek snahy "dohnat" tento zákon, aby platil..
Může, třeba se vymyslí jiná, lepší jednotka, která to zvládne v méně operacích, což je zrovna například u sčítání nepravděpodobné, ale to se bavíme o opravdu základní operaci, ty už mluvíš o výkonu v operacích násobně komplexnějších..
Hele ty "predikátore", co kdyby ses naučil konečně česky a nepsat kraviny?
Mohl by mi to někdo vysvětlit polopatě?:)
Je to zajímavá diskuze, ale něco mi uniká.
Obecně tedy více jader nemá smysl, protože jádra (a jakoby podkaterie - vlákna jader) mohou zpracovávat jen jeden dotaz najednou? 4 jádra jsou optimální z toho důvodu, že na PC děláme třeba více věcí najednou (nezávisle), proto se výpočetní výkon může rozložit do více jader zvlášť?
Druhá část - cache - tam jde jen o to, jak velký zásobník informací, které potřebujeme zpracovat procesor má, takže může s větší pamětí i více odbavovat a "netahat to po kouscích"?
Třetí část - takt jader(snad píšu správně) - jak rychle dokáží jednotlivé jádra (obecně celý procesor) informace zpracovávat - něco jako auto - jedu rychleji - dostanu se do cíle dříve.
Čtvrtá část - počet tranzistorů, kde to vlastně celé začíná - "jednotky", které zpracovávají informace (v jednotlivých jádrech) a jejich efektivnost je ovlivněna a) množstvím b) taktem procesoru obecně - rychlostí zpracování dat?
Pokud se v některých částech a nebo porozumění procesoru jako takového pletu, budu vděčný za nějaké vysvětlení na úrovni toho, jak jsem to popsal.
Děkuji.
Kazde dalsi jadro je mene uzitecne, protoze ho vyuzije mene aplikaci. Optimalni cislo nicmene neexistuje.
Cache je hlavne rychlejsi nez systemova pamet. Idealni by bylo, kdyby byla systemova pamet rychlejsi, ale to je moc drahe, takze se udela rychlejsi ale mensi cache.
Pokud delas v jednom taktu dve veci, tak je vlastne delas paralelne, nemuze jedna zaviset na druhe. Takze takt je o tom, kolik ZAVISLYCH veci dokaze procesor stihnout behem daneho casu.
Pocet transistoru je pocet jader krat velikost jader plus velikost cache. Takt nema s poctem transistoru nic spolecneho.
Jsem z toho trochu jelen, ale i tak díky za čas a odpověď.
Zkusím to trochu jinak:
- více jader má smysl jen pokud každé bude mít co dělat. Pokud tedy budeš spouštět dva různé výpočty, každý může běžet na jiném jádře. Pokud ale budeš počítat jednu dlouhou řadu operací kdy ta další závisí na té předchozí, tak ti těžko druhý procesor pomůže, protože to matematicky nejde - další operaci počítá první jádro a operaci která bude následovat počítat nemůžeš dokud neznáš výsledek té předchozí.
- cache je opravdu jen brutálně rychlá pamět pro krmení CPU. Někdy jí potřebuješ víc, jindy ti stačí míň. Obecně může zrychlovat výpočty jen do určité velikosti - když bude už moc velká a procesor to nevyužije, bude ti k ničemu a výpočet se nezrychlí. A v podstatě "zrychluje" výpočet jen o dobu, kterou by zabralo získávání dat z normální paměti oproti cache CPU.
- takt je doba, za kterou cpu zpracuje instrukci. Některé instrukce zvládá v jednom taktu, některé ve více taktech, a některé CPU zvládají víc instrukcí za takt v rámci jednoho jádra. A když těch taktů budeš mít za vteřinu víc, víc toho také spočítáš ;) Dnešní procesory jsou ale tak rychlé, že běžnou prácí zvládají bez problémů a je zbytečné aby běžely pořád na 100%, takže se při idlování (nicnedělání) podtaktovávají.
- počet tranzistorů je dán architekturou, počtem jader, velikostí cache, přidanýma obvodama (paměťové řadiče, USB, ...). Když zůstaneme jen u samotného výpočetního jádra CPU (velmi jednoduše řečeno), tak se dá obecně říct, že čím víc tranzistorů, tím je jádro rychlejší, protože jsou využity k tomu, aby zvládalo víc instrukcí za takt (oni ty všechny MMX, SSE se někde prostě projevit musí), nebo třeba aby CPU dokázal líp predikovat co se bude dít.
Z toho plyne, že výkon CPU je (zhruba) dán efektivitou architektury násobenou taktem násobeno počtem jader (ty ale musíš dokázat využít).
Jestli jsem někde vedle, tak mě opravte.
Trochu bych si dovolil upravit ten takt - v podstatě je to správně, ale záleží také na architektuře - některé zvládají víc operací v jednom taktu a nemyslím tím víc jader ale právě to jedno. Z toho plyne efektivita architektury, kdy intel je momentálně na stejné frekvenci (taktech) výkonnější než amd (bývalo to ale i obráceně).
Trochu upravím hkmalého...
Programy pro domácí použití netřeba řešit, ty jsou celkem nenáročné. Ale třeba ve hrách je pár věcí, které jsou celkem náročné, a jelikož se neovlivňují, je možné je paralelizovat.. Zatím to ale hry umí jen na 4 jádra, a ono toho ani moc víc nejde. V nějakých stříhacích programech je paralelizace zase taková, že každý thread si bere "svůj" úsek dat, nad kterými chroustá.. 4 jádra jsou tedy něco, co v dnešní době nabízí dostatek výkonu na hry, nadbytečný výkon pro běžné aplikace, a přijatelný výkon pro náročné výpočetní aplikace.
Cache funguje různými způsoby, zejména ale těží z opakovaného využití stejných dat - jejich načtení z cache je ve zlomkovém čase oproti načtení z paměti, ale cache je drahá, vlastně nejdražší část procesoru, proto je jí málo, a proto máme paměťi odstupňované: registr>cache>OP>SSD/HDD>vnější paměťi>síťové paměti, kdy doprava klesá rychlost i cena, a roste typicky kapacita, kterou mají/máme.
Druhé, z čeho těží, je princip linearity - program je bez cyklení a lineárně se vykonává, řádek za řádkem, takže pokud načteme do cache celý program (kéž by to bylo možné), postupně využijeme všechna data, která v cache máme, přičemž víme, že následující budou data, vyžádaná dalším řádkem - a už víme, která to jsou, a můžeme je předpřipravit. To jest zřetězené zpracování instrukcí, které zavedlo tuším Pentium, a pro které je průser skok programu - všechna "předhotová" data se mohou zahodit.. Naštěstí například zřetězené zpracování instrukcí je jenom bonus, který nic navíc nestojí, a jeho zahozením neztratíme.
Takt.. Ukažmě to na zmíněn sčítačce pro jeden binární řád - té přijde na vstup A číslo a na vstup B také číslo. A ona v jednom taktu provede součet těchto čísel (jedničky a nuly), výstupem je výsledné číslo daného řádu, a hodnota "přetečení" do dalšího řádu, která se v dalším taktu bere jako třetí vstup součtu dvou vstupních čísel. Funguje to asi stejně, jako desítkové sčítání pod sebou. Pokud tedy sčítáš 32bitová čísla, potřebuješ 32 taktů (plus načtení čísel) pro jejich sečtení (plus takt pro přečtení výsledku). A teď je na tobě, jak dlouho ty takty budeš dělat - při 32 Hz sečteš tato čísla za 1 sekundu. Při taktu 128 Hz sečteš tato čísla za 0,25 sekundy.. Nebo můžeš použít 32 sčítaček, jenže problém je v tom, že každá sčítačka dalšího řádu musí čekat na výsledek onoho přetečení z minulého řádu, aby mohla správně provést řádový součet. Takže ve výsledku stejně potřebuješ 32 taktů. Jsou tam nějaké ušetření, která ale nevyváží ten prostor, který taková sčítačka zabere v procesoru. Jednoduše to tak ale funguje. A sčítačka nikdy nesečte dvě čísla rychleji, než za 1 takt, ani kdyby měla milion výpočetních jednotek... Ale můžeš sčítat dvě dvojice čísel najednou, na dvou sčítačkách... Ovšem v praxi se moc nestává, že by bylo potřeba sčítat více čísel najednou - v praxi jsou totiž na sobě furt nějak závislá, a počítání je kaskádovité, lineární..
c)operací, kterou je potřeba provést - ne všechno (skoro nic) lze paralelizovat.. Jinak ano, třeba při zpracování obrazu, které lze paralelizovat po pixelech, je výkon přímo úměrný počtu jednodek krát jejich takt lomeno počtem taktů pro vykonání dané operace (stejné pro všechny pixely) na daných jednotkách. Třeba načervenání celého obrazu o 20% červené (255 0 0) barvy - tehdá pixelshader tohle udělal v řekněme 10 taktech (načetl barvu pixelu, spočetl barvu přidání, sečetl barvy, vrátil), takže při 800 jednotkách na 800 MHz lze zpracovat 64 000 pixelů za sekundu touto operací. Zbytek světa, a zejména co dělá procesor, už tak hezky lineární není... :(
Bez urážky, ale připadá mi, že tomu vůbec nerozumíte, plácání nesmyslů o nutnosti implementace x-bitové čítačky ve více hodinových cyklech je buď ignorace nebo záměrná dezinformace. Než začněte pouštět do světa bludy, kteří by snad ostatní mohly i považovat za pravdivé výroky, tak doporučuji nastudovat něco teorie. BTW paralelní sčítačka/odčítačka je učivo snad každé technicky zaměřené VŠ. Všechny další úvahy jsou jen bláboly. PS: pokud jde o teorie nad potřebou taktů pro úkony doporučuji si něco přečíst o superskalárních mikroprocesorech a pipeline. ...první x86 supeskalár byl P5.
Na implementaci sčítačky pro jeden binární řád jsem to ukázal proto, že je to na ní dobře vidět pro laika - kde jsou problémy, proč nejde paralelizovat, násobit počty jednotek... Jsou věci, které jsou na sobě závislé..
A co já vím, tak ani paralelní sčítačka nedokáže sčítat v čase 1 taktu, ale v čase logaritmickém k počtu bitů, protože nelze "kouknout a vidět", zda přenos bitu bude, nebo nebude.
Stejně tak potřeba taktů - ano, každá operace skutečně trvá nějaký pevně daný počet taktů, a pokaždé, když stejnou operaci budeš opakovat, bude trvat na stejném procesoru stejné množství taktů.
Nebo kde jsme se konkrétně nepochopili? Co jsou bludy?
Pokud jde o doporučení, doporučuji nastudovat pravidla českého pravopisu.
V minulém příspěvku mluvíte o lineární závislosti, teď zase logaritmická. Ano paralelní sčítačka zde byla již třeba v dobách jednoduchých ttl obvodů, např. 74ls83. Následné teorie o cyklech a časové náročnosti jsou bláboly už jen proto, že jde maximálně s přimhouřením oka o latenci. Superskalár ale dokončuje v jednom taktu v drtivé většině více než jednu instrukci. Doporučuji skripta VŠB Logické obvody od Diviše a Chmelíkové, popř. Architekturu počítačů II od Ličeva.
"Internetové diskuze jsou jako speciální olympiáda, i když vyhraješ, jsi retardovaný."
To, co jsem jako příklad uvedl, mělo také závislost lineární, nebyla to paralelní sčítačka, jen primitivní vícebitová sčítačka pro ilustraci.
Počet taktů instrukce byl také jako příklad, pro zjednodušené vypočítání té "rychlosti". Superskalár... On nepracuje v jednom taktu vícekrát, on má ve skutečnosti vyšší taktovací frekvenci - takt systémových hodin je pro něj jistá základní reference, vůči které se něco vztahuje, a vůči které ty hovoříš. Ale ta superskalární jednotka má ve skutečnosti vyšší interní takt, a hraje si "na svém písečku" se vstupem, který dostala v taktu systému. Při dalším taktu vyplivne svůj výsledek, obvykle. Záleží na úhlu pohledu, ale já nechtěl zabíhat do detailů.
To trollujete záměrně nebo je to ignorace. Ty fakta co tu střílíte máte z vlastní hlavy, nebo vám je nějaký podobný chytrák nakukal. Když Vám člověk 2x napíše že to co píšete jsou prostě blbosti, tak si stejně budete mlít svou a ještě naložíte něco o vyšším interním taktu než je základní frekvence hodin :) Prosím, zaběhněte do detailů :)
Vše má svůj důvod. Pokud střílím fakta, pak to nemohou být blbosti, to se poněkud vylučuje...
Záleží jen na úhlu pohledu. Můžete říct, že v jednom taktu vykoná více instrukcí, a nebo že pracuje na vyšší frekvenci.
Tedy co já vím, tak jsou v procesorech intel jisté jednotky, které pracují na dvojnásobním taktu - reagují na nástupnou, i sestupnou hranu hodinového signálu, přičemž zbytek systému reaguje na hranu nástupnou. Efekt je takový, že počítač je synchronní stroj, kde se vždy s hodinovým signálem odehraje nějaká změna stavu, impulzy procestují od hradla k hradlu.
Ale my si nerozumíme, protože toto je, jak jsi zmínil, olympiáda retardů, a mezi ně (vás) já nepatřím..
Fakt si radsej nieco precitajte o CPU a mikroarchitekturach. Jednak bezna superskalarna architektura ma v jednom takte rozpracovanych viac instrukcii v roznych fazach (vid neslavne znamy NetBurst) a to zasadne ovplinvuje vykon, hlavne ak predikcna jednotka to nezvladla spravne a cela pipline sa musi vyprazdnit a znovu naicitat. No a cim je dlhsia tym je to pomalsie a vznikne onsekorenie. Preto takyto druh jadra je velmi zavysly od predikcnej jednotky (mimochodom velmi zaujimavo to malo, aspon v prvych modeloch vyriesene Itanium. Ak sa dobre pametam tak tam predikcna jednotka prakticky nebola a vsetko bolo zverene kompileru, aky kod vyprodukoval. Takze tam mohol s novym kompilerom a prekompilovanim aplikacie kludne rapidne stupnut vykon). Dalej vsetky dnesne x86 cpu pouzivaju mikroinstrukcie, cize to neznamena ze vykon jadra sa da zvysit iba frekvenciou. Je dost dolezity aj navrh a implementacia tych mikroinstrukcii. Do vykonu tak isto dost keca cache a jej radic. Ani nie tak z hladiska jej rychlosit ale prave toho co a kedy ma nacitat. Dalsia moznost zvysenia vykonu su prave SMID instrukcie a vobec vektorove jednotky. To je vlastne uz paralelizacia na urovni jadra, kde v jednom registri mam viac spracovanych udajov ktore sa spracuvaju jednou instrukciou (MMX,SSE,AVX a vobec vektorove jednotky).
A co sa tyka paralelizacie samotnych aplikacii na viac jadrove cpu, tak to je fakt problem hlavne v pripade ak pri danom procese spracovania udajov existuje datova zavyslost. Dalsim problemom su deadlocky a celkovo bezpecnost a koherentnost pamete, kedze ta je medzi threadmi vo vecsine dnesnych os zdielana. Ono prave sa moze pri zlom navrhu stat ze vdaka lockovaniu pamete a koli tomu cakaniu medzi threadmi na pristup sa strati viac vykonu ako aplikacia ziskala pristupm na viac jadier.
Ale pri hrach je prave paralelizacia vcelku v pohode mozna akurat tazko sa zabespecuje linearne rozlozenie vykonu na vsetky jardra a ich stabilne 100% vytaznie. Bezne sa to robi tak ze sa engine rozdeli na jednotlive, viac menej nezavysle subsystemi a tie bezia na vlastnych jadrach - audio engine,sietovy kod, io filesystem, rendering, scriptovaci engine, ai napriklad. Problem neni ani tak v tom ze by sa jednotlive ulohy, problemy nedali paralelizovat ale skor sa taka aplikacia velmi zle debuguje a ladi, tak netrepte kraviny.
dotaz pro znalce - jak hodnotíte počet jader a HT z pohledu virtualizace ?
např. má HT vliv na virtualizaci ? jinými slovy je pro to vhodnější i7, nebo stačí i5, protože HT se stejně nevyužije ?
Chystám upgrade pracovní stanice a využívání virtuálních stanic je pro mě denní chleba (VirtualBox), tak pokud by byl ochoten někdo poradit, budu rád.
Nad tím ani neuvažujte. Win7 bylo od začátku děláno s tím, že bude využívat HT, a využívá ho naplno, např. http://superuser.com/questions/300260/how-to-query-intel-hyper-threading...
Virtualizovaný systém má přístup k HT úplně stejně jako nativní. Pokud máte software, který jej využije, není důvod cpu osekávat, je to jen Vaše volba. Hlavně dostatek RAM a rozumné SSD, to je pro odezvu a plynulý chod IMHO důležitější.
Díky, mi nejde ani tak o to přidělit jednomu virtuálu více CPU, ale spíše potřebuji provozovat několik virtuálů současně a CPU jim nějak rozdělit. Takže když jednomu virtuálu přidělím 1 CPU, uvidí systém v něm 1 CPU nebo 2 (cpu plus HT) ? Některé serverové aplikace totiž vyžadují určitý počet jader.
Omlouvám se, jestli to píšu nějak blbě, moc se v tý virtualizaci nevyznám, pro mě je to jen nástroj, jak toho pustit víc současně a zas bych nerad koupil celkem drahej procák, aby nebyl pořádně využitej.
RAM a SSD jsou jasné, tam to chápu.
Ok, to uz je konretneji mirena otazka. Obecne jde vse. OS v zakladu nerozlisuje mezi HT jadrem a plnym. Pokud ale zna jejich rozlozeni, muze s tim planovac pocitat. Ted si nejsem jisty, jestli to opravdu tak dela, ale rekneme, ze muze. Ted jde jen o to, jaky hypervizor pouzijes. Na workstation pouzivam player, protoze staci, nicmene je tupy a zadne kouzla s resource se nekonaji. Na serveru mam zkusenosti s esxi a tam je mozne natvrdo pridelit konkretni jadro virtualnimu systemu, muzete mit treba VM1 bezici na vsech 8-mi jadrech s nizkou prioritou a VM2 bezici na dvou plnych jadrech s vysokou prioritou. Dale rozdelovat resource na urovni Mhz. Priznam se, ale ze jestli to umi i Fusion nebo VirtualBox netusim.
Ahoj,
viac core viac adidas :o nie vzdy to plati (napr. vypoctovo narocne matematicke operacie v multiparalel. kode alebo len tak spomeniem LinXpack, ktory so zapnutym HT podava nizsi "vykon")
no aj ked su to virtualne (HT) a samotny VT software by ich vyuzit nevedel tak da sa povedat ze aspon zvysok rezie potrebnej k behu toho ktoreho VT softu -tj jadro OS, drivery, services atd budu reagovat "rychlejsie" tj odozva OS smerom k uzivatelovi OS bude "castejsia". Osobne by som bol zvedavy a zameral by som sa na nastavenie v BIOS a skusil co to spravi s odozvou OS a VT software ked je zap/vyp:
HW prefetcher / DCU prefetcher / IP prefetcher / Adjacent cache line prefetcher
standardne su vsetky 4 volby prefetcherov podla intel specifikacii = "enabled" ale okrem narocnych databaz su aj ine pripady kedy sa "vytunit" si CPU prefetch podla vlastnych poziadaviek vyplati...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.