Hlavní navigace

Qualcomm se naváží do MediaTeku: Osm jader? K ničemu!

30. 8. 2013

Sdílet

Tento podzim se na trhu má objevit řada mobilních zařízení s novými procesory. Očekává se zejména souboj Snapdragonu 800 od Qualcommu a blíže neupřesněného procesoru od MediaTeku (známe označení MT6592). První nabídne čtyři jádra, druhý jader osm. Právě na této skutečnosti založil Qualcomm video, ve kterém se naváží do MediaTeku.

Počet jader prý není všechno a ukazuje to na různých příkladech. Své produkty porovnává se SvýmKonkurentem, přičemž nápis je jasně stylizován do podoby loga MediaTek. Video najdete níže, názor si udělejte sami.

Pro čínského výrobce, který se dosud objevoval spíše ve smartphonech a tabletech druhé třídy, to lze považovat za dílčí vítězství. Zdá se, že Qualcomm začíná MediaTek považovat za vážnou konkurenci. Kvalita jeho čipů se totiž zlepšuje a cenově se stále pohybují v jiných dimenzích.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 1. 9. 2013 16:27

    Avanti (neregistrovaný)

    Nebo spíše ta nacionalistická. Nacionalistický režim nebyl o nic více demokratický než ten komunistický. Nacionalistická strana byla původně taktéž členem Komunistické internacionály, posledních pár let jsou ovšem v IDU strýčka Ronieho.

  • 1. 9. 2013 21:28

    Bert (neregistrovaný)

    Ano, nacionalistický Tchajwan nebyl od svého vzniku mnoho desítek let demokratickou zemí. Ale v 80. letech se to změnilo a od začátku 90. let (tedy přes 20 let) už je Tchajwan regulérní demokracie.
    Black Rider má pravdu, že Tchajwan (nyní) je demokratický.

  • 31. 8. 2013 11:46

    petík (neregistrovaný)

    Je to hlavně o tom, aby se programátoři naučili využívat více jader. Růst počtu jader je přirozený vývoj v situaci, kdy už se jedno jádro zrychluje jen velmi draze. Čím více se to programátoři naučí používat, tím více to využijí na masivně multijádrových procesorech (128?), které jistě brzy přijdou.

    Navíc pokud nasadí takový mnohojádrový procesor na serveru, tak to může být zajímavé pro nízkonákladové VPS.

    Myslím, že zatím má smysl dělat asymetrické procesory - tj. 1 jádro udělat nadupané (vyšší frekvence, cache, více tranzistorů) pro jednovláknové aplikace a zbytek mnoho jader optimalizovaných na výkon/watt - pro vícevláknové aplikace, které to umí využít.

  • 31. 8. 2013 14:35

    Kolemjdoucí (neregistrovaný)

    Promluvil znalec :-)
    Růst počtu jader je znouzectnost, protože nemáme technologii na zvyšování frekvencí. Proto se v poslední době prakticky jenom přidávají jádra, frekvence moc neroste. Běžnému člověk ovšem dokáže vytížit jenom dvojjádrový procesor, osmijádrový využije opravdu jenom málokdo.
    Rozdělení obyčejných programů do více jader jednoduše není možné, 8 lidí nevykope jednu díru rychleji než 1 nebo 2, naopak je to použitelné jenom pro určité úlohy.
    Nadupané jedno jádro už se dělá dávno, viz Intel Turbo Boost.

  • 31. 8. 2013 14:57

    Kolemjdouci (neregistrovaný)

    Kouknete na posledni Carmackovo video. Uz je cas na funkcionalni programovani a s nim Vas argument uplne pada..

  • 31. 8. 2013 17:48

    Kolemjdoucí (neregistrovaný)

    Funkcionální programování je Lochneská příšera o které se dlouze mluví, občas se na čas vynoří a zanoří zase zpátky pod hladinu. To proto, že funkcionální programování nereflekfuje náš hardware, který je bezvýhradně imperativní.
    Na programování s více jádry není funkcionální programování nutně potřeba.

  • 31. 8. 2013 15:06

    BoneFlute

    Se obávám, že jste si nepřečetl příspěvek na který reagujete. (Nemluvě o tom, že co píšete není tak docela pravda, že.)

  • 1. 9. 2013 1:07

    petík (neregistrovaný)

    znouzectnost = ano - vždyť to říkám, zvyšování frekvencí je moc drahé (nemyslím jen $, ale plochu křemíku nebo spotřebu); je to ale realita - počet jader prostě roste a dál poroste.

    Běžný člověk jen spustí program - a je mu +- jedno, jestli využije jedno nebo 15 jader. Pokud je ale program napsán na využití N jader (ne 2 nebo 3, ale obecný počet), tak prostě může běžet rychleji s každým přidaným jádrem.

    Normální přístup teď třeba ve hrách je vyhradit jádro na zvuk, jádro na fyziku, jádro na vykreslování ... ale takto lze využít jen omezený počet jader(to, co má std zákazník) - ne všechny.

    Většina programů obsahuje cyklus, a pokud vykonávání jedné iterace obsahuje činnost, která je trochu delší, tak už se může vyplatit cyklus rozhodit do více vláken - tak, aby se využilo N jader. Trochu naroste režije v souvislosti se zamykáním a spouštěním vláken, ale může se to vyplatit - pokud jsou další vlákna "zadarmo" - tj. jinak by byla jádra vypnuta a uživatel by musel čekat.

    Turbo boost (podle toho co jsem si teď vygoogloval) je jen na půl cesty. Tj. jedno jádro se přetaktuje, ale fyzicky je shodné s ostatními a tak se ta "vyvolená" jádra střídají - aby se procesor zahříval rovnoměrně. Dá se to ale udělat lépe - tj. to jedno jádro udělat jinak, navrhnout jej pro maximální výkon a ty zbývající udělat víc úsporně (méně tranzistorů) - aby byl maximalizován výkon celého procesoru (např. 20 úspornějších jader místo 16 plně výkonných může být celkově výkonnější). Pokud prostě mohu počítat s tím, že mi aplikace využije všechny procesory, tak tak optimální návrh bude jiný.

    Pokud se 8 lidí do té díry vejde a nebudou si překážet, tak ji vykopou rychleji - to znamená ne vždy se to vyplatí, ale může se to vyplatit a dá se počítat, že brzy těch lidí bude 32 :-)

    Nemá smysl zrychlovat činnosti, které trvají pro uživatele 1ms - ale pokud má 15s čekat (a uživatelů jsou tisíce a miliony), tak už má smysl se nad tím zamyslet.

  • 1. 9. 2013 8:23

    Kolemjdoucí (neregistrovaný)

    Většina her využije nanejvýš 4 jádra a to jsou hry extrémně výpočetně náročné.
    Drtivá většina obyčejných aplikací nemá šanci se dostat přes dvě jádra. Režie rozhodit obyčejný cyklus mezi 8 jader je obrovská a než se to vůbec rozběhne a doběhne a různě sesynchronizuje, tak se vyplatí právě Turbo Boost. Souvisí to s pomalostí pamětí, současné paměti jsou 50x pomalejší, než by bylo potřeba.

    Všechny jádra v jednom procesoru používají stejnou technologii a ještě dlouho to tak bude, šance na to že by jedno jádro bylo extra jiné moc není.

  • 1. 9. 2013 12:23

    petík (neregistrovaný)

    Hry: jak jsou napsány je určeno aktuální architekturou konzolí a tedy tím, kolik jader mají konzole. Určitě si dovedu představit oblasti, kde lze utopit spoustu výkonu - např. viditelnost, destrukce objektů na mapě a využití nové situace v AI. Tyto oblasti jsou vždy kompromisem mezi realitou a výrazně zjednodušujícím podvodem, a další možný výpočetní výkon umožní posunout kompromis blíže k realitě.

    Konzole Xbox 720 a PS 4 budou mít osmijádra, takže se můžete spolehnout, že je hry(PC) budou umět využít. Hry pro Android jsou většinou o několik řádů jednodušší a proto pro ně zatím asi více jader nemá smysl; pokud ale mají problém s výkonem, tak je to cesta ke zrychlení.

    Režie na rozhození cyklu nemusí být extrémní. Stačí na začátku běhu programu alokovat thready - v počtu jader nebo počtu jader - 1 a postavit je do fronty na semafor, kde jim bude přidělována práce - tj. budu mít frontu úkolů a cyklus se změní v nasypání izolovaných úkolů do fronty úkolů a počkání na výsledek.

    Neříkám, že má smysl mít úkol typu X := X + 1, ale něco, co trvá např. 100ms už ano. Pokud se vyskytnou problémy multithreadového prostředí - deadlocky, tak lze snadno přejít do nouzového režimu a alokovat na práci jen jeden thread.

    Samotná režie čekání na semafor je celkem minimální - tj. např. v řádu 1000x/1s by neměla být významná.

    Když se v cyklu přistupuje ke sdílenému prostředku, tak může být efekt paralelizace minimalizován - ale s tím je potřeba počítat.

    Turbo boost vám zrychlí jádro maximálně 2x, rozepsáním na thready můžete zrychlit 2-X - závisí už jen na hardwaru a X časem poroste rychleji, než výkon jednoho jádra.

    Pomalost pamětí: mohu vám věřit, ale narazil jsem (asi před 1/2 rokem) spíše na informace v opačném smyslu - že procesor není schopen využít rychlosti paměti DDR3 1866 a že teprve s APU se nějaké využití pro tuto rychlost najde (tj. přistupuje tam i grafická část). Samozřejmě to souvisí i s velikostí cache na procesoru, která většinu požadavků odbaví rychle.

  • 1. 9. 2013 14:09

    Kolemjdoucí (neregistrovaný)

    Představuješ si to jako Hurvínek válku.
    Jednak spousta algoritmů vůbec nejde rozepsat do vláken a dále sice si správně popsal vícevláknovou techniku, akorát netušíš kolik je s tím režie, kolik transakcí v cache-coherency, kolik zamykání cache-line a to si piš že režie probuzení vlákna v OS při čekání na semafor je přímo obrovská. Ve výsledku právě tyto režie zabijí jinak přínosnou myšlenku a to od počtu asi čtyři vlákna.
    Pomalost pamětí je jasná jako facka, průměrná paměť má lacenci 5 ns, procesor by potřeboval řádově menší hodnotu, proto se tam cpe tolik cache.

  • 2. 9. 2013 13:37

    Karel (neregistrovaný)

    Opatrně, technologická režie na vícevláknovost není nijak zásadní. Problém je spíše v tom, že se musí generovat úlohy pro jednotlivá vlákna. Dobrým příkladem je procházení stromu metodou do hloubky. Když si někdo řekne o práci, tak mu musíte říci, kde má začít a předat mu stavové informace. Najít a "odseknout" dostatečný stavový prostor (=dostatečně velkou úlohu) je velmi nákladné a vůbec vás to nepřibližuje k výsledku. Můžete si to zjednodušit tím, že mu dáte náhodně vybranou část prostoru (nebo se rovnou podělit a dát mu půlku své práce), ale pak musíte řešit fakt, že i on se bude muset umět o práci podělit, takže zadavatelem může být kterékoliv vlákno, ne jen to hlavní. A to už je docela solidní mezivláknová komunikace a polling.

    Pokud hledáte nejkratší cestu, pak stavová informace je dosud nalezená nejkratší cesta, což je jedno číslo. Ale v řadě úloh to bude již složitější a "zadání práce" může být o kopírování kilobajtů nebo i megabajtů dat mezi vlákny.

    Takže opravdu prosím opatrně. Režie probuzení vlákna a čekání na semafor sice nejsou malé, ale v porovnání s náklady na "dělbu práce" bývají zanedbatelné. Riskujete, že budete zatažen do diskuse o lepší komunikaci mezi jádry, sdílení paměti, HW semaforech atd. Přestože to jsou pro běžné úlohy témata zcela podružná.

  • 2. 9. 2013 16:39

    Kolemjdoucí (neregistrovaný)

    Opak je pravdou, technologická náročnost vícevlákna je tak zásadní, že to zabíjí i triviální úlohy jako je Quicksort, které si přímo říkají o vícevlákno.

  • 2. 9. 2013 17:31

    Karel (neregistrovaný)

    Nikoliv. Quicksort nefunguje právě kvůli komplikované dělbě práce. Dokud neprovedete první roztřídění, tak jedete v jednom vláknu. Teprve pak dostanete dvě úlohy, z nichž každou může dostat jiné vlákno. Teprve až ta dvě vlákna dokončí svou práci, tak se to opět bude dělit. Je to krásný příklad problému, u kterého nejvíce výkonu ztratíte organizací práce a nikoliv tím, jak dobře HW komunikuje mezi vlákny.

    Oproti tomu mergesort je paralelizovatelný dobře. Můžete už na samém počátku rozdělit vstupní data na N segmentů a pak je zpracovávat jeden po druhém. Pokud si někdo řekne o práci, tak mu řeknete rozmezí od-do a necháte ho to setřídit. Nakonec budete mít N setříděných fragmentů, které musíte spojit. Pak se dělá, že když máte setříděný fragment X a X+1, tak to dáte někomu jako jiný typ zadanání (merge místo sort). Prostě v každé chvíli budete mít snadno dostupný seznam balíků práce a předání úlohy spočívá v zadání typu (sort vs merge) a rozmezí od - do (případně pro úlohu merge i začátek druhého fragmentu). Samotný sort na fragmentu X pak může probíhat libovolnou metodu, klidně quicksortem - protože se tahle úloha se už dále nedělí. Pokud bych ji chtěl dále dělit, tak se buď musí zkomlikovat komunikace (slave se ptá mastera, zda má práci, a ten mu buď práci dá, nebo mu řekne jiný slave, který dostal nedávno nějakou práci, ať se s ním domluví na rozdělení), nebo se spíše použije stromová struktura - jeden master a pod ním X slave vláken. Vybraná slave vlákna jsou masterem pro svoje další slave vlákna atd.

    Rekapitulace: u quicksortu ztratíte plno času a úsilí ve snaze generovat úlohy pro slave vlákna, případně snahou uřídit síť peer-to-peer. Úzkým místem je pak vaše řízení paralelní úlohy, nikoliv HW. U mergesortu existuje snadný a nenáročný systém řízení slave vláken, takže zde bude úzkým místem HW, respektive OS a jeho mezivláknová komunikace, případně sdílení paměti. Quicksort si neříká o vícevlákno, ale o Chocholouška.

  • 2. 9. 2013 9:47

    nemo (neregistrovaný)

    Bez urazky ale neni to pravda. Zrovna 3d herne enginy su docela blby priklad na pararelizaciu. Jednak bezia realtime, cize mutexy,semafory a celkovo zamky su to najhorsie riesnie, pretoze onsekoroenie aj iba 1ms moze nakoniec spravit dropnuty frame alebo zalagovat celkovy vystup,a porom velky problem je ze ovladace 3d kariet niesu schopne pracovat s viacerymi threadmi. Takze renderer musi byt cely v jednom vlakne. Ano daju sa jednotlive subsystemy rozdelit do viacerych trheadov ale zasa vznika problem zo synchronizaciu. Dalej pamet je naopak neskutocne pomala na x86, v mobiloch na ARMe to bude este horsie, takze udrziavat jednak lokalne kopie dat, koli vyhnutiu sa zamkou, a ich synchronizovat ma obrovsky dopad na vykon.

    Ano funkcionalne programovanie sa tomtu uspesne vyhyba kedze volane funkcie su z tohto pohladu atomicke a neudrzuju si stav a nehrozi ze si medzi sebou nejak prepisu data, na druhu stranu nie vsetko sa da popisat pomocu funckionalneho programovania. Nehovoriac o tom ze to moze neumerne predlzit vyvoj, prepisat kod pomocou funkcii.

    No a posledna vec, na mobilnych zariadeniach je prave na opak idealne pouzivat co najmenej jadier. Respektive je dobre ked aplikacia vyuziva co najmenej zdrojov a tym ma mobil aj nizsiu spotrebu a dlhsiu vydrz. Ked mobilna hra berie cely vykon cpu na mobile tak to asi az tak nevadi, ale ak by nejaky blby widget alebo jednoducha aplikacia potrebovala povedzme vsetky 4 jadar (8 jadier, x jadier) na plny vykon asi by z toho uzivatel nebol nadseny. Uz tak su baterie na mobiloch totalne pozadu vo vydrzi.

  • 2. 9. 2013 13:18

    j (neregistrovaný)

    Ehhm ... ovladace jsou jen SW, kery je treba stejne jako spoustu jinyho SW upravit. Nehlede na to, ze hra ani zdaleka neni jen grafika a obsluha grafiky jednim jadrem porad dava hromady prostoru pocitat vedle spoustu jinych veci.

    Prave ze cim vic jader, tim vetsi uspornost systemu. Ty resis problemy spojeny se synchronizaci ... prepisem dat ... jenze ty problemy v mnoha ohledech neexistuji. Tohle musis resit v pripade, ze se vice jader podili na vypoctu jedine ulohy, ale v okamziku, kdy si kazde jadro resi svoji ulohu, ktera jen nejak interaguje s okolim ...

    Podivej se do libovolnyho soucasnyho OS a spust si ps nebo spravce uloh ... minimalne desitky threadu, nekdy stovky ... ale i tisice ... Uvedom si, ze po vetsinu casu NIC nedelaji. Ale v "prumeru" neco delaji stale. Tudiz CPU realne nemuze nikdy usnout. Kdybys pro kazdou tu ulohu mel CPU, tak jich spousta bude vetsinu casu odpojena => muzes snizit spotrebu, protoze na jednotlivou ulohu ti staci jadro trebas 100x pomalejsi => min zerouci.

    BTW: Taky nechapu, proc skalovani CPU neni navrzeno v daleko vetsich mezich (predevsim frekvencne). Snizit frekvenci na jednotky MHz (defakto i radove min) v situaci, kdy se nic nedeje neni zadnej technickej problem.

  • 2. 9. 2013 14:22

    JSH (neregistrovaný)

    > Ehhm ... ovladace jsou jen SW ...

    Jedna grafická karta má jednu frontu příkazů. Krmit GPU z více front principielně nic moc nepřináší.

    > Prave ze cim vic jader, tim vetsi uspornost systemu.

    A to proč? Čím víc jader, tím složitěji se musí dostávat k paměti, kterou mají společnou. Ta má jedinou sběrnici. Stačí se podívat na tu šílenou neuniformní hierarchii cache, kterou mají nové procesory. Čím víc jader, tím horší práci má plánovač OS.

    > ... ktera jen nejak interaguje s okolim ...

    Jenže právě ty interakce s okolím je to, co je třeba serializovat.

    > Taky nechapu, proc skalovani CPU neni navrzeno v daleko vetsich mezich (predevsim frekvencne).

    Nechápeš toho evidentně daleko víc. Spotřeba CPU stoupá zhruba s druhou mocninou pracovní frekvence. Takže nějaké snížení frekvence dokáže přinést zajímavé úspory, ale další snižování už nic moc zajímavého nepřinese.

    > ... neni zadnej technickej problem.

    Tohle je hodně odvážné tvrzení. Já teda nemám koule na to, říct co je a co není technický problém u moderních procesorů. Kolik jsi jich už navrhl? :)

  • 2. 9. 2013 16:34

    j (neregistrovaný)

    GPU je nejspis jako Buh ... vecne stejny ... Az nekdo dojde k tomu, ze by bylo fajn aby GPU melo 150 front, tak je mit bude. A mimochodem, prave GPU jsou zarnym prikladem masivniho vyuzivani paralelizace. Ve vhodnych ulohach (a zdaleka nejen grafickych) jsou radove rychlejsi nez libovolne CPU ... a to prave proto, ze uz dnes umi v jednom kroce provadet stovky vypoctu, narozdil od CPU kde to sou jednotky.

    Mluvil sem o energeticky uspornosti. Pokud budu mit 100 uloh ktery se poustej semo tamo, tak bud pro ne budu mit trebas GHz jednojadro, se spotrebou 100W nebo 100x 1W. Jiste, procaky umej (z casti) regulovat svoji spotrebu uz tak, ale ve vetsim mnoztvi by to bylo daleko efektivnejsi. Pri tom jednom jadre mi pak procak bude zrat trvale 100W, protoze na nem porad "neco" bezi, kdezto v pripade 100 CPU po 1W budu mit prumernou spotrebu trebas 30W, protoze se ty ulohy budou stridat na +-30jadrech ... pricemz celkem budu mit k dozpozici stejnej vypocetni vykon.

    Spotreba procaku kterej misto na 3G bezi na 1G5 bude rekneme 30%, to furt neni 0. Navic ty CPU neskalujou ani v takovymhle rozsahu ... A ze to neni problem technickej je zcela jasny, kdyz s trochou snahy ty procaky podtaktovat vpohode lze ... a lze je tak uchladit vpohode pasivne ... protoze na generovanej vykon se totiz vazou (pro tebe zjevne prekvapko) i dalsi prvky - jako vetraky (ktere lze vypnout) ... vlastni spotreba zdroje ...

    Mam tu procak, kterej s pomoci OC vytocim nekam na 3G5 ... a podtaktovat ho umim nekam k 600MHz (min nedovoli nasobicka). Podtaktovanej se uchladi bez problemu pasivne s relativne malym chladicem, kterej ani nijak zvlast nehreje.

    A pro zajimavost, rozpal prikonu cely sestavy bez "vnejsich" zasahu je cca 150W (idle - full load), rozsah mezi max OC a min je temer 250W. Samo, vetsinu z toho dela grafarna.

  • 2. 9. 2013 17:22

    nemo (neregistrovaný)

    Ani neviem ci sa mi chce reagovat ale skusim to. Prosim Vas aj ste nieco naprogramovali? A tym myslim aj nieco viac ako skript v php (ktore mimochodom dodnes neni thread safe), nehovoriac tiez ze sledovat vytazenie threadov/scheduleru cez WindowsTaskManager je tiez "presne".
    Co sa tyka ovladacu ku grafickym kartam, tak tie su dnes asi najkomplexnejsie a najzlozitejsie ovladace k beznemu kusu hw ake vobec existuju. Prepisat takyto driver zo single threadoveho do multithread prostredia je peklo. Si uvedomte z ovladac bezi v kernel mode, staci jeden deadlock a minimalne ma kernel problem v horsom pripade prdne cely OS.
    Co sa tyka pretaktovavania tak pre Vas je asi CPU akurat tak ALU ze ano. Okrem ineho cpu obsahuje registre,lokalne cache, radice, zbernicu, dnes uz aj pametovy radic a dalsie obvody ktore zdaleka vsetky nebezia na plnej frekvencii CPU. Dalej samotne cpu nemoze byt az tak nizko podtaktovane nie len mozno z technickych pricin ale jednoducho aj koli tomu ze zdvyhnutie frekvencie na pozadovanu velkost a tym odpovedajuci vykon trva niekolko taktov a taketo oneskorenie moze byt v niektorych pripadoch katastrofalne. Potom prave vznika lagovanie celeho systemu.

  • 2. 9. 2013 17:31

    Bert (neregistrovaný)

    Proč se ho ptáte, jestli někdy něco naprogramoval, když z jeho příspěvků je jasné, že ne? Tedy mohl programovat nějaké školní úlohy v nějakém základním kurzu, ale skutečnou praxi zjevně nemá.

  • 3. 9. 2013 13:47

    JSH (neregistrovaný)

    > GPU je nejspis jako Buh ...

    Kdyby byly v řiti ryby... Až budou GPU vypadat úplně jinak než teď, pak se budu hodně divit, pokud se budou jen trochu podobat tvým ignorantským představám.

    Ve spoustě úloh jsou GPU zase pomalejší než kdejaké staré CPU. Je vidět, že netušíš, jak uvnitř GPU vypadají. Na GPU se dobře paralelizuje jen hodně specifická třída úloh. Většina toho, co dnes počítače dělají, nemá vůbec cenu na GPU cpát.

    > 100W nebo 100X 1W

    Takhle se procesory dělit nedají. TEČKA.

    K tomu co je nebo není efektivní buď dodej nějaká tvrdá data, nebo si tu dojmologii strč někam.

    Fajn, dokážeš podtaktovat procesor. Jak rychle ten podtaktovaný procesor zvládne naběhnout na plný výkon, když je to potřeba?

    Když mi bylo o polovinu míň než teď, tak jsem si o sobě taky myslel, že jsem sežral Šalamounovo hovno a všichni návrháři počítačů to dělají blbě. Bylo to proto, že jsem věděl kulové.

  • 2. 9. 2013 18:32

    petík (neregistrovaný)

    Souhlasím, 3D herní engine - tj. část hry, která se stará o vykreslování scény v současnosti není vhodná pro nasazení na více procesorech. V 3D vykreslování se paralelizace bohatě využije na grafické kartě. Pro j (2001:470:9e7­0:...): Přepisování ovladačů sice možná probíhá, ale rozhodně to není triviální.

    Jednotlivé herní subsystémy - tam už je to něco jiného. Pokud má voják vymyslet "plán napadení hráče" - nemusí to stihnout v 1 framu a ten thread by mu vůbec neškodil (nemusí tam být 50 threadů pro 50 vojáků - prostě jen může existovat úkol "Vymysli plán útoku vojáka 138 na tank 334").

    S těmi lokálními kopiemi dat si to ve hře moc nedokážu představit. Pokud už mám nějakou důležitou sdílenou hodnotu (integer - 4B ... matice 4*4*4 = 64B), tak do ní někdo (oprávněný thread) zapisuje řekněme 50x za 1s - každý frame jednou (pokud ne, tak to lze jistě upravit).
    Samotný zápis ale trvá šíleně krátce, takže i kdyby čtecí thread použil aktivní čekání, tak ztratí řádově pár desítek taktů ( a jen v situaci, kdy se v tom moři času potkají) ... Chápu, že pokud se vývojář vydá cestou kopírování, tak za chvíli nedělá nic jiného.

    Semafory a zamykání mohou dělat problémy v cache a zapisovaná hodnota se kvůli pomalosti hlavní paměti musí probít i do cache toho správného jádra, ale k zneplatnění cache dojde (snad by se to tak dalo napsat :-)) jen u čtecího procesu - ten má ale relativně více času, protože si běží na svém "méně zatíženém" jádru.

    Pomalost hlavní paměti: Je pomalá. Máme ale celou hierarchii pamětí - registry, několik úrovní cache a hlavní paměť. Procesor má navíc prostředky (x86 - prefix LOCK, případně speciální instrukce (Compare-and-swap)), kterými mu může program naznačit, že tato data jsou zamykána a že by je tedy měl udržovat ve sdílené (mezi jádry) cache.

    Více jader na mobilních zařízeních - ano, máte pravdu, že využití dalšího jádra není "zadarmo", ale platí se energií akumulátoru. Proti tomu ale zase stojí energie na sdílené prostředky - např. připojení k wifi a osvětlení displeje, tj. pokud lze úlohu dokončit dříve, tak lze ušetřit na těchto "fixních nákladech". Obecně pokud by měla režie na vícevlákno sežrat 10% energie navíc a výsledek jsem měl 5x rychleji, tak bych určitě (pokud se nebavíme o 5ms a 1ms) volil vícevlákno.

    Vždy jde o to, co ta aplikace dělá. Složitější výpočty bych z mobilu spíše přesunul někam na server. Vytížit 8 jader na plný výkon bude umět brzy každý začátečník :-) Profík zvládne stejnou úlohu na 10% výkonu jednoho jádra.

  • 2. 9. 2013 20:37

    nemo (neregistrovaný)

    Naoak pamet je kruto pomala ci uz citanie alebo zapis. Napriklad pri poslednom Doom3 BFG, prestali pouzivat pri skinningu animacii predpocitanie do bufferu aby tieto vysledky boli dostupne aj dalsim threadom/funkciam a na miesto toho to na kazdom mieste kde treba znovu rataju pretoze ten vypocet na CPU je radovo rychlejsi ako nacitanie dat z pameti takze tam prakticky nieje penalizacia.
    Tak isto riesili napriklad zdielanie dat medzi threadmi v CPU cache pretoze je rychlejsia ako ramka. Ostatne je to celkom zaujimave citane od Jan Paul Van Waveren, programatora z iD software (Mr. Elusive, ak si niekto pameta mal na svedomi vyborneho bota do Q2 - GladiatorBot a na zaklade toho ho aj prijali do iD Softu kde mal potom na starosti botov do Q3A), a prave ten clanok pojednava o pameti http://fabiensanglard.net/doom3_documentation/index.php . Co sa tyka threadov a celkoveho planovaca tak na win je problem s tym ze nemate pod kontrolou scheduler a preto sa moze stat ze nejaky ten thread dostane menj procesoroveho casu. Pokial je to nieco co neni az tak casovo narocne ako rendering, ale povedzme pathfinding tak je to este ok, aj ked zasa vznika problem zo synchronizaciou, ale ak sa takto zamota thread spracuvajuci povedzme sietovy kod alebo audio moze to byt dost neprijemne.

  • 2. 9. 2013 13:26

    Karel (neregistrovaný)

    1. Grafický herní engine obvykle nemá vůbec žádný problém ukrmit grafickou kartu. Naopak zcela běžně na ni musí čekat
    2. Úzké místo není výkon procesoru, ale přístup do paměti. Pro vykreslení jedné scény je potřeba velké množství objektů, které zabírají hodně paměti. Do cache se to nevejde.
    3. Grafické karty jsou zcela běžně mnohojádrové. U High End jsou to stovky jader.

    Režie paralelního procesu je obecně obrovská. Nejde jen o předávání práce, ale o vlastní generování úloh. V dnešní době se paralelizace používá jen na velmi malou skupinu úloh, které splňují požadavky:
    * Příprava balíku práce je jednoduchá a předání balíku práce je také jednoduché
    - nebo -
    * Balík práce se zpracovává tak dlouho, že je čas jeho přípravy a předání zanedbatelný

  • 2. 9. 2013 18:51

    petík (neregistrovaný)

    1. možná jak který, ale ok
    2. grafické karty tady ale kopou úplně jinou ligu - mají paměťovou architekturu přizpůsobenu paralelnímu zpracování grafických informací - vše je podřízeno tomu, aby jednotlivá jádra měla plynulý přísun dat, na nich provedla své operace a zase je vyplivla k dalšímu zpracování / zobrazení. Není ani zásadní problém rozšíření sběrnic pro maximalizaci datových toků (zvyšuje to cenu karty :-)
    3. ano

    Ty dva požadavky jsou velmi správné - prostě je potřeba vyhodnotit, zda se to vyplatí a v určitých situacích se vyplatí a v jiných ne. Pokud jsou splněny, tak režie paralelního procesu je zanedbatelná.

    Celou dobu se tady hádají dva tábory, jedni říkají "režie zamykání je velký problém" a druzí "je to úplně v pohodě" - a přitom je to vztaženo vždy k jinému typu úloh a rozhraní mezi nimi je dáno právě těmi dvěma požadavky :-)

  • 2. 9. 2013 13:03

    j (neregistrovaný)

    Promluvil uberznalec ....

    Bezny clovek vubec netusi, jaky CPU ma ve svym stroji. A je mu zcela uprdele, jestli je to 1x100GHz nebo 100x1GHz. Ten kdo neumi vyuzivat vice jader neni uzivatel, ale aplikace, potazmo jeji vyvojar. Existujou sice ulohy, ktere obecne paralelizovatelne nejsou, ale i na zcela obycnejnem domacim desktopu zcela bezne zaroven bezi stovky ruznych uloh - a klidne muze kazda bezet na vlastnim CPU.

    Typickym prikladem neschopnosti vyvojaru jsou trebas hry ... neb to je zarny priklad aplikace, kde lze paralelizovat temer vse. Kdyz pudu do extremu, tak trebas kazdy NPC muze mit vlastni CPU.

  • 2. 9. 2013 13:28

    gamer (neregistrovaný)

    Teorie je to hezká, všechno paralelizovat by bylo krásné, prakticky to ale nefunguje. Každé NPC by mohlo mít vlastní thread a CPU, ale narazíš na problém při naprosto triviálních operacích. Co když chce vzít NPC nějaký předmět? Jak víš, že ho nechce vzít současně nějaké jiné NPC? Nevíš, takže tam musíš dát zámek... a je to celé v háji, bude tam na každou blbost lock, režije toho bude ohromná a ve výsledku to poběží pomaleji než single thread rešení.

    Navíc paralelizace v reálných úlohách naráží na to, že jsou tam potřeba nějaké společné neparalelní operace a platí Amdahl's law: http://en.wikipedia.org/wiki/Amdahl%27s_law

  • 2. 9. 2013 16:49

    j (neregistrovaný)

    ... pokud po tom NPC chci nejaky netrivialni chovani, tak pro nej potrebuju dostatek vykonu. A pokud tech NPC ma byt ve hre milion, tak pro ne potrebuju milionkrat dostatek vykonu ... a navic pro me zacne byt zcela zasadni problem prepinani kontextu, kdy CPU s kazdym NCP pracuje jen chvilku ... a pak musi obslouzit ostatni, takze vlastne po vetsinu casu ty NPC nedelaji nic, protoze na ne CPU nema cas.

    A tenhle problem se aktualne resi bud v singlu tim, ze CPU realne obsluhuje par desitek (max) NPC v dohledu hrace, a ostatni opravdu nedelaji nic, maximalne maji ulozen nejaky stav ... nebo v online hrach tim, ze NPC nedelaji nic ani realne, a jen stoji a cumi, maximalne jich nekolik desitek chodi sem a tam.

    Jinak, kupodivu, kdyz chci poslat update do databaze, tak taky nevim, jestli zrovna ve stejny okamzik nechce totez pole aktualizovat 150 jinych uzivatelu.

  • 2. 9. 2013 17:24

    gamer (neregistrovaný)

    Hele programoval jsi někdy nějakou hru? Pokud máš funkční řešení AI, kde bude každé NPC bežet ve svém threadu a má to znatelně vyšší výkon než single thread rešení, tak s tím bež do libovolné herní firmy, okamžitě tě tam zaměstnají a nabídnou ti královský plat. Jinak je to teoretizování o ničem.

  • 2. 9. 2013 17:32

    Bert (neregistrovaný)

    To je ještě horší otázka, než co položil ten nahoře. Proč se ho ptáte, jestli programoval nějakou hru, když je z jeho příspěvků evidentní, že v programování laik?

  • 2. 9. 2013 17:29

    nemo (neregistrovaný)

    Vy ste fakt dost mimo.
    Jednak ak chcete udrzat data o hernom svete konzistentne tak sa v tej vasej predstave zamkom nevyhnetne co ma obrovsky dopad na vykon alebo by kazda NPC musela mat lokalnu kopiu celeho herneho sveta co je zasa nechutne velky narast na pametovu narocnost nehovoriac o porblemoch zo synchronizaciou.
    A ako montovat do porvnavania realtime enginov db storage engine je fakt sila.
    Ak si postavite herny engine kde to ze ma bezat realtime neni priorita, tak ano uz aj dnes neni problem spravit sandbox s povedzme 100 NPC chovajucimi sa rozumne ale bude to bezat od 30FPS kludne aj do 0.000001FPS, ale ved to neni priorita ci ?
    Pri DB fakt uzivatelovy je jedno ci sa request zapise za 1ms alebo 400ms. Nehovoriac ze zapis do DB je vecsinou atomicka operacia - zapis jedneho riadku,popripade bunky a len tie su uzamknute, kdezto interakcia NPC urcite neni jednoducha operacia, dokonca vela krat to neni ani operacia na jeden frame (uz len napriklad koli animacii samotnej postavy)

  • 2. 9. 2013 19:31

    petík (neregistrovaný)

    Pokud byste někdy programoval hru, která se má prodávat, tak vám garantuji, že milion NPC, které budou všechny dělat netriviální chování prostě neprojde.

    Jeden kolega AIčkář sice přemýšlel o desítkách tisících NPC, které by měly nějaký svůj individuální denní program (v 5:30 budíček, vyčistit zuby, 5:40 snídaně, 5:50 odchod do práce - stihnout trolejbus v 5:58 do práce v konkrétní budově/patře/židli) ... ale mám dojem, že to zůstalo jen ve fázi snění. Taková koncepce má ale minimální nároky na CPU/NPC.

    Na AI dostanete 1-2 jádra a pokud se to nestihne všechno důležité=to co je vidět, tak to dají napsat někomu jinému.
    Nikoho z vedení neoslníte tím, že NPC na druhé straně mapy usilovně přemýšlí, co si dá k snídani.

    Databáze - tam si prostě počkáte, až těch 150 jiných uživatelů před vámi dokončí svoji aktualizaci a pokud se vám to zdá dlouho, tak se zainvestuje do lepšího hardwaru nebo se nakoupí chytřejší programátoři nebo se upraví zadání ...

    U hry sice můžete dát minimální požadavky na 32 jádrový procesor s 128GB RAM, ale tu hru nikdo ani nevydá, protože potenciálních zákazníků jsou jen stovky.

  • 15. 9. 2013 12:18

    Trident (neregistrovaný)

    Vsechno je blbe. Zacit znovu. Proc se mi na nejnizsi urovni automaticky nepostavi stroj podle definice ulohy na nejakem ohromnem optickem FPGA (jeste asi nebylo vynalezeno)? Proc kdyz chci zacit tu samou ulohu nechat bezet tak se mi nezreplikuje ten dany stroj jeste jednou? Tady se skryva ohromny potencial.

  • 31. 8. 2013 20:05

    Tonda (neregistrovaný)

    Procesory s mnoha slabými jádry (v tomto případě 8 x Cortex A7) je prostě politika čím víc pruhů tím víc adidas, dělat aplikace nuceně paralelní jenom aby byly použitelné na takovémto šuntu může být často nesmyslně pracné nebo nemožné, rozhodně lepší vývoj je zlepšovat architekturu aby rostl výkon per core a nerostla nebo klesala spotřeba. Ale namlátit tam víc jader je jednodušší.

  • 1. 9. 2013 1:23

    petík (neregistrovaný)

    "často nesmyslně pracné nebo nemožné" - ano jsou případy, kdy to (více vláken) jde, kdy to jde těžko a kdy to nejde; prakticky vždy je to dražší na vývoj a testování.

    Můžete počítat s tím, že nárůst výkonu na jádro bude čím dál pomalejší a počet jader bude čím dál větší, tj. u stále více úloh se bude vyplácet použít vícevláknovou architekturu.

  • 31. 8. 2013 22:52

    Lael Ophir (neregistrovaný)

    Jenže řadu úloh prostě na více jader nerozsekáte, ani kdybyste se rozkrájel :). Navíc například Android si s více jádry moc nerozumí.

    Existují sice způsoby jak využít mnoho jader, ale praktické aplikace zatím moc nejsou.
    http://research.microsoft.com/en-us/projects/barrelfish/

  • 1. 9. 2013 9:42

    whata (neregistrovaný)

    Tak Android si s více jádry nerozumí? A která část přesně? :-)
    Kernel Linux, který se zdaleka nejvíc používá na superpočítačích s tisícovkama procesorů, aplikační vrstva v Javě, která má od začátku Thread stejně přirozeně jako Object, nějak nevidím to místo, kde si ten Android s více procesory nerozumí...

    No hlavně, že agenti Microsoftu právě v projektu Barrelfish objevili, že počet procesorů roste. Hlavně, aby nakonec nedopadli jako s Windows Phone 8 :-)

  • 1. 9. 2013 18:54

    Lael Ophir (neregistrovaný)

    Jenže ty superpočítače s tisícovkama procesorů neběží jednu kopii OS. Jde o velké výpočetní clustery složené z nodů, které mají typicky 2-4 jádra. Linux má s více procesory dost problémů díky nevhodnému designu kernelu (BKL po desítkách let slavně rozbitý na subsystem locky), což ale u superpočítačů naštěstí moc nevadí, protože vlastní výpočty kernel většinu času nevolají.

    Android má navíc UI v jediném threadu, což výkonu také moc nepomáhá. Nakonec se podívejte na to škubání UI i na velmi výkonném HW.

    Barrelfish je projekt, který bere podporu více jader i různých architektur v rámci jednoho počítače z jiného pohledu, než tradiční SMP/ccNUMA/NUMA architektura. Zkuste si o tom zjistit více.

  • 1. 9. 2013 20:20

    dustin (neregistrovaný)

    Hm, nejsem žádný znalec superpočítačů, ale minimálně SGI takové systémy vyrábělo (zda pořád jsem nezjišťoval)

    https://www.msi.umn.edu/hpc/koronis

    http://www.tomshardware.co.uk/Linux-supercomputer,news-25814.html

    http://en.wikipedia.org/wiki/Altix

    Chápu, že se moc nevyskytují, protože nejde o žádný stock hardware.

  • 1. 9. 2013 22:21

    Lael Ophir (neregistrovaný)

    Hm, společnost SGI v roce 2009 vyhlásila bankrot, a koupila jí společnost Rackable Systems. A to za 42.5M USD, přičemž ještě v roce 1995 byla tržní kapitalizace SGI okolo 7G USD.

    Systémy typu big iron jsou si schopny proradit s pár tisíci jader. Bohužel ale jen pokud aplikace příliš nevyužívají služeb kernelu. Kernel - zvlášť ten linuxový - má spoustu zámků. Pokud jeden thread zavolá kernel, funkce v průběhu volání dojde na nějaký zámek, a pak další volání kernelu z jiného threadu dojde na ten samý zámek, tak druhý volající čeká až do jeho uvolnění. Linux měl až do nedávna tzv. Big Kernel Lock, takže veškerá volání kernelu zamkla všechno; teď je BLK rozdrobený na menší zámky, ale pořád je to dost slabé.

    Zkuste na takovém stroji s tisícem CPU provozovat třeba DB server, který často volá kernelové funkce provádějící networking a přístup na disk. Zjistíte že od pár jader bude nárůst výkonu velmi malý (a to bez ohledu na rychlost disků).

    Dalším problémem je přístup k paměti. Výhodou systémů typu big iron by měla být možnost práce více threadů nad těmi samými daty. Bohužel RAM je proti CPU velmi pomalá, takže je třeba k CPU dát cache. To přináší problém: pokud jeden CPU něco změní v paměti, ostatní CPU pracující s tou samou pamětí o tom musí dostat informaci, a načít ta data do cache. A to je bohužel dost pomalé.

    Navíc pro mobily je to všechno irelevantní. Většinu akcí uživatelem typicky prováděných na mobilu totiž nelze rozumně rozdělit do více threadů. A kde je rozdělit lze, tam do toho autor aplikace stejně ve spoustě případů nepůjde, protože multithreadové programování i ladění je poměrně obtížné (podle vývojářů je navíc emulátor plný bugů). K tomu má Android singlethreadové UI, což dovede zabít část z těch několika scénářů, kde by multithreading ještě po tom všem dával smysl.

  • 1. 9. 2013 23:40

    dustin (neregistrovaný)

    ====
    teď je BLK rozdrobený na menší zámky, ale pořád je to dost slabé.
    ====

    1. Jak se kernel obejde bez zámků ke sdíleným proměnným, ke sdíleným zdrojům?

    2. Slabé oproti čemu? Benchmarky atp.?

  • 2. 9. 2013 1:03

    Lael Ophir (neregistrovaný)

    1. Tak že se kernel od začátku píše jako preemptivní a reentrantní. Samozřejmě se nelze zbavit všech zámků, ale dají se výrazně omezit jak co do počtu, tak do jejich velikosti.

    2. Now a lot of the BKL conversions recently were simply code locks. About those I must admit I’m not really excited. -- Andi Kleen
    http://halobates.de/blog/p/56

  • 2. 9. 2013 7:50

    dustin (neregistrovaný)

    1. Nějaký konkrétní příklad z aktuálního jádra, kde to udělat lépe?

    2. Zkusíme jinou citaci stejného autora v komentářích k tomu článku:

    You are making the same basic mistake as a lot of other people: assuming that there is actually a lot of cycles spent under the BKL. While one could construct extreme examples where that may be true I maintain it's not in most cases on a 2.6 kernel
    (and even on 2.4 it wasn't all that big)

    The interesting entry points to drivers typically were already BKL less for a long time and the other subsystems all had to do explicit lock_kernel()s too. It was all already fully under the control of the driver writer.

    Jinak např. commity v 3.10:

    http://kernelnewbies.org/Linux_3.10#head-5c725e42ba8f05ed7767cfaf1c8e8c6546c4caec

    http://kernelnewbies.org/Linux_3.10#head-a510ab8fd667eee519a088a193a1e6aa61e445a6

    http://kernelnewbies.org/Linux_3.10#head-9754bb18b327a7c86a0051d124104a0ae9069660

  • 3. 9. 2013 0:23

    Lael Ophir (neregistrovaný)

    1. To chce profiling s různými typy zátěže a na různých počtech CPU, identifikovat bottlenecks, opravovat a upravovat. Neživím se jako kernelový vývojář, takže na tohle fakt nemám čas.

    2. Samozřejmě můžeme citovat i dále:
    There’s an old rule of thumb that 90% of all program run time is spent in 10% of code (I suspect the numbers are actually even more extreme for typical kernel loads). And that should only tune the 10% that matter and leave the rest of the code alone. The BKL is likely already not in your 10% (unless you’re unlucky). The goal of kernel scalability is to make those 10% run in parallel on multiple cores.

    Tady se můžete podívat třeba na odstranění dispatcher locku v kernelu Windows. Motivací bylo vylepšení výkonu na strojích s více než 64 jádry při jistých typech zátěže. Rozdíl je v tom, že MS systémy opravdu profiluje na různém HW, s profily zátěže sesbíranými u zákazníků. Výsledek podle toho pak vypadá.
    http://channel9.msdn.com/Shows/Going+Deep/Arun-Kishan-Farewell-to-the-Windows-Kernel-Dispatcher-Lock

  • 2. 9. 2013 0:03

    Lael Ophir (neregistrovaný)

    WP i W8 používám, a interface se mi neseká. V W8 Metro používám velmi omezeně, ale na WP bych si sekání všimnul. Na všech třech telefonech je GUI nádherně plynulé.

  • 2. 9. 2013 11:23

    Sten (neregistrovaný)

    Linux nemá s více vlákny problém. Všechny kritické části umí více jader využít.

    UI stejně může kreslit najednou jenom jeden thread. Android má AsyncTask, který slouží právě pro rozložení zátěže. Ale Java programátoři si s ním nerozumí a pak to končí škubáním UI a spoustou varování v catlogu, který ale tihle programátoři stejně nečtou (alespoň pro síť už Google přidal vyhazování výjimky, pokud se komunikuje na UI vlákně).

    Btw. až nastoupí na mobilní Windows programátoři ze stolních Windows, můžete čekat stejný problém.

  • 3. 9. 2013 0:04

    Lael Ophir (neregistrovaný)

    Programátoři ze stolních Windows na prvním místě zjistí, že API Windows Phone prakticky nenabízí synchronní volání. To se pak UI thread těžko blokuje.

  • 3. 9. 2013 19:59

    Sten (neregistrovaný)

    Nevím, jaké máte zkušenosti s programátory, ale já znám hodně takových, kteří si to synchronní volání vyrobí třeba aktivním čekáním pomocí while. Navíc asynchronní volání nikdy nebude mít výkon jako paralelizované.

  • 3. 9. 2013 23:17

    Lael Ophir (neregistrovaný)

    On snad někdo říká, že to asynchronní volání musí nutně běžet na stejném jádru CPU?

    Samozřejmě "programátoři" dokážou zprasit cokoliv, ale MS jim to značně ztížil. Navíc aplikace před přijetím do Store musí projít schválením.

  • 2. 9. 2013 16:14

    j (neregistrovaný)

    Hmm, ty zjevne vubec netusis, jak vypadaj ty velky stroje ... nody se daji pouzivat jen pro konkretni ulohy, ale tam, kde potrebuji aby se jim to chovalo jako jedinej stroj, samozrejme sou tisice CPU v jedinem OS.

    A jestli ma nejaky OS zasadni problem, tak predevsim widle, ktery klido 30% casu travej tim, ze zjistujou, ktery jadro pouzit ... a ve finale to vypada tak, ze singlecore appka klido zatizi "z neznamych duvodu" vsechny jadra a to nemluvim o tom, ze jadro 0 si pro sebe sezerou widle vzdy, a defakto neexistuje zpuob, jak je prinutit aby ho nechaly napokoji (pro zajemce, v pripade games se vzdy vyplati, vynutit afinity tak, aby nebylo vyuzivano prvni jadro, protoze na nem bezi vse co je ve widlich => ziskate pro gamesku par % vykonu navrch)

  • 2. 9. 2013 22:59

    Lael Ophir (neregistrovaný)

    Což má přesně ta omezení, které jsem už popsal.

    widle, ktery klido 30% casu travej tim, ze zjistujou, ktery jadro pouzit - LOL, dobrý vtip

    singlecore appka klido zatizi "z neznamych duvodu" vsechny jadra - asi ne singlecore aplikace, ale singlethreaded aplikace. A pokud ani neumíte zjistit co konkrétně aplikace dělá, tak asi nemá smysl se dál bavit.

  • 15. 9. 2013 12:06

    Trident (neregistrovaný)

    Android 3.0 jiz si s vice procesory rozumi a Bionic ma vlastni implementaci pthread a o level vys taky neni problem.
    http://www.slideshare.net/coolmirza143/multithreading-in-android

    Ale trvalo jim to.

  • 2. 9. 2013 13:21

    j (neregistrovaný)

    Ze neumi vice jader pouzivat M$, to je dlouhy roky znama vec. Proto jedou vsechny viceprocesorovejsi platformy na tuxovi.

    BTW: Jen tak pro zajimavost, pro kolika jadrech odmitnou 8my nabootovat? Ja abych vedel co cekat, az si za 2-3 roky budu kupovat novej stroj. M$ totiz velmi s oblibou stanovuje vsemozne "vic nikdy uzivatel nebude potrebovat" hranice, ktere vydrzi tak 2-3 roky ... viz win 98, ktery nenabootovali s vic nez 512MB RAM ...

  • 2. 9. 2013 23:41

    Lael Ophir (neregistrovaný)

    SMP/NUMA přeskočím, protože se o tom s vámi nemá smysl bavit.

    Windows 8 umí až dva fyzické procesory, s maximálně 256 jádry. Není to ale technický limit - Windows Server 2012 podporuje až 64 fyzických procesorů a 640 jader. BTW proč by měl systém odmítnout nabootovat? Například Windows 7 Home prostě druhý fyzický CPU ignorovaly.

  • 17. 9. 2013 0:19

    Trident (neregistrovaný)

    Od nejakych Windows NT tyto podporuji vice jader. Ale tam byl umely limit. V zakladu myslim 1-2CPU. Ty jely i na alphe. Co mne ale vzdycky stvalo byl totalne podelany diskovy subsystem. Clovek tomu urazi nesystemovy disk a cely system se hvizdne. U novych win systemu zas blbne lun expansion. Jakekoliv cachrovani s disky aby clovek dal hadr na hlavu. Jeste ze nejsem woknousak.

  • 1. 9. 2013 9:43

    to_je_jedno

    Bambilion jader dokazes rozumne pouzit treba na konverzi videa kde to rozsekas na mensi kusy a jeden nemusi na druhy cekat. Docela dobre to pouzijes na webserver kde nacteni stranky pro navstevnika x nemusi cekat az nactes stranku navstevnka y. pak par dalsich "drobnosti".

    To je, ale naprosta minorita beznych cinnosti - tam kde to potrebujes tak si to koupis (viceprocesorove desky). Ale drtiva vetsina populace si dneska bohate vystaci s obycejnym celerem a kdyz maji SSD tak nemaji pocit ze na neco cekaji.

  • 17. 9. 2013 0:29

    Trident (neregistrovaný)

    Pri vice procesorech narusta rezie. Vzdyt se bavime o hloupem primitivnim SMP. To uz je lepsi koupit celku cpu-pamet vice. Jaky ze tam ma ted pro pecka linux limit? 128?256? uz jsem se dlouho nekoukal.

    Kdyz na nepeckovem hw za mrzky peniz z vyprodeje 8x2 coru a na novem hw za mega 128 coru(jedna nekolikauckova krabice), tak ty parcorove xeonace je fakt bida.

  • 2. 9. 2013 12:13

    Kaacz (neregistrovaný)

    Jo, sice se mi video líbí, má to hlavu a patu a má v něčem pravdu. Na druhou stranu je vidět, že výrobce má vizi pro současné mobilní OS, které jsou jen parodie na multitask. Když na nich "opravdu běží" současně jen jádro OS, GUI OS a jedna APP co je v popředí, tak víc procesorů opravdu potřeba není.

    Ale na mobilu s opravdovým/ne­limitovaným multitaskem se pár jader navíc hodí. A já takový používám (bohužel se single core) a příští mobil mám objednaný taky plně multitaskový (již na dualcore - hurá).

    Vůbec totiž nejde o nutnost napsat aplikaci jako multithread. To je snad jen záležitost herní konzole nebo pro enkodování videa. Ale běžný uživatel (na desktopu a rád by i na mobilu) má většinou spuštěno více aplikací, každá běží ve svém threadu.

    A souhlasím, že těch víc jader může být klidně slabších pro thready na pozadí a na (klidně dual) main CPU by běželo to, co je na popředí (OS, GUI + app).

    Mimochodem, spousta výpočtových věcí se dnes přesouvá na GPU, které mají větší výkon než CPU. Tupé přidávání CPU vyhovuje tupým programátorům ..

  • 2. 9. 2013 18:43

    Sten (neregistrovaný)

    Přinejmenším je vhodné psát aplikace jako dualthread: UI thread oddělit od worker threadu. Už jen z toho důvodu, aby měl uživatel možnost výpočet přerušit nebo změnit. Za chvíli programování také přijdete na to, že se dá snadno používat těch threadů hodně: třeba jeden kreslí obraz, druhý mixuje audio, třetí komunikuje po síti, čtvrtý počítá stav a pátý detekci hran. Jenže spousta programátorů má problémy odladit rozumnou synchronizaci (a přitom nevynalézat kolo) a tak se vrátí k jednomu vláknu.

    Na GPU se přesouvá jenom těch pár výpočtů, co má smysl na GPU počítat. Náročnost GPGPU je obrovská a pro obecné úlohy výkon mizerný.

  • 2. 9. 2013 19:59

    petík (neregistrovaný)

    Asi neznám současné mobilní OS, ale u Androidu bych čekal, že má normální preemptivní multitasking (standard asi od Windows 95) :-)

    Pokud potřebujete mít na pididispleji mobilu 5 aplikací, které usilovně něco počítají, tak jste asi výjimka.

    Rozumně napsaná aplikace - pokud po ní uživatel zrovna nic nechce, tak také nic nedělá a spí. Že se jedenkrát za minutu mrkne na kurzy akcií bych jí odpustil, ale i to je prakticky jen čekání.

    GPU je hodně specifický kus hardwaru a k většině činností (90%) je velmi nevhodný. Pokud se využije na to, k čemu je navržen (nejen grafika), tak je velmi efektivní. Zkuste si třeba otvírákem na konzervy čistit zuby :-)

    Poznámkami o tupých programátorech se cítím dotčen, ale omlouvá vás vaše neznalost :-)

Byl pro vás článek přínosný?

Autor zprávičky

Bývalý redaktor serveru Root.cz, dnes produktový manažer a konzultant se zaměřením na Bitcoin a kryptoměny.