Názory k článku
Qualcomm se naváží do MediaTeku: Osm jader? K ničemu!

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

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.

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

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.

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.

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.

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.

> 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? :)

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.

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.

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

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

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.

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.

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ý

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

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.

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?

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)

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.

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.

====
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.?

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

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

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

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

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.

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

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.

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.