Gartner varuje: vícejádrové procesory se vyvíjejí rychleji než software

Diskuze čtenářů k článku

vaseo  |  29. 01. 2009 00:28  |  Linux Mozilla 1.9.0.5

ale je to vetsinou kvuli naproste neschopnosti nebo dokonce nepochopitelne odmitavosti programatoru delat paralelni programy. neni to sice zadna sranda, ale vetsina problemu je nejakym zpusobem vice ci mene paralelizovatelnych a o vyuziti vice samostatnych vypocetnich jednotek si primo rika.
podobne se podivuji nad pomalosti prechodu na 64bit, 64bitove programy jsou stale neco specialniho, casto jsou dokonce zcela nedostupne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
nordic  |  29. 01. 2009 00:39  |  Microsoft Windows Vista IE 8.0

Tak to sa strasne mylis.Dost programatorov by to chcelo.Ale proste to nikto nezaplati.A podruje, podpora od vyrobcov je docela slaba.Ale existuje super dll pre .net parallel FX. ktora to zjednodusuje, neviem ci je nieco take pre javu, alebo podobne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 02:48  |  Linux Mozilla 1.9.0.5

hmm i to je mozne, v tom pripade je to kratkozrakost toho, kdo si plati vyvoj vlastniho produktu bez podpory vice jader. ale predpokladam, ze i ti brzo budou muset prehodnotit investice (samozrejme jen tam, kde to ma nejaky smysl).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  29. 01. 2009 22:15  |  Microsoft Windows Server 2003 IE 7.0

Přehodnotit investice? Vždyť dnes je primární cena! Manažer, který nákup software schvaluje, typicky nemá vůbec žádnou představu o programování (ani základní), takže se rozhoduje podle ceny. A co je dražší, to nemá šanci uspět.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miroslav Šilhavý  |  29. 01. 2009 22:19  |  Microsoft Windows XP IE 8.0

Kromtoho je pošetilé si myslet, že vývojářské domy si neumějí spočítat, co se vyplatí a co ne... Holt na co zatím nepřišli špičky, to jim může vaseo poradit :)
Pochopitelně netvrdím, že se nezmění. Je dokonce pravděpodobné, že přijdou nástroje, systémy a frameworky, které poměr výhodnosti změní - a až to bude, tak na to všichni rychle přejdou, uvidíte.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 22:46  |  Linux Mozilla 1.9.0.5

nevim, segmenty (hry, 3d grafika), ktere sleduju nebo se v nich pohybuju, paralelizaci primo vyzaduji. ten, kdo plati, neresi paralelizaci ano/ne, proste je mu receno nebo vi, ze bez ni to efektivne nejde. ale jsou to asi segmenty uplne jinde nez (nejen) webove aplikace - dikybohu
pokud bude projekt 4x pomalejsi nez konkurencni, ale levnejsi, muze to za jistych okolnosti projit, mozna i dlouhodobe - to je opravdu vec manazera. jsou ale aplikace, ve kterych to nelze tolerovat a dobry manazer samozrejme musi prehodnotit investice - o tom jsem psal.
a masivni prechod na paralelni kod? ne ze uvidime, to je jiste! ti, kterym se to nelibi, muzou jet dal sekvencne
jsem zastancem paralelizmu a myslel jsem, ze tu budou podobni fandove a ostatnim to bude jedno. co me ale sokovalo je, ze jsou tu odpurci - nachapu jestli je to konzvervatismus, neschopnost myslet 'paralelne' - tedy strach nebo neco jineho.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  30. 01. 2009 09:17  |  Microsoft Windows XP IE 7.0

3D grafika není žádný mainstream a jako taková výrobcům procesorů nemůže zajistit žádný velkosériový odbyt. Hry se postupně přesouvají na konzole, ale i ty na PC jsou dle mého dobře paralelizovány. A teď zbývá oblast, která je pro výrobce procesorů obrovským odbytištěm.
Jsou to počítače na práci. Nevím, jestli do nějaké chodíte, nicméně tady je situace jiná. Typické úlohy jsem už jmenoval a žádnou z nich nelze nějak rozumě paralelizovat. Na vině tedy nejsou programátoři ani jejich chybějící nadšení, ale nemožnost paralelizace plynoucí z povahy těch úloh. Proto v tomto segmemtu není zájem o vícejádra a převládá stagnace.
Osobně se domnívám, že pokud něco zabije Mooreův zákon, tak to nebudou technologické limity, ale nedostatek potřebných úloh pro našlapaný HW.

Souhlasím  |  Nesouhlasím  |  Odpovědět
BlackRider  |  30. 01. 2009 09:38  |  Microsoft Windows XP Firefox 3.0.6

Tvoje uvaha ma dve chyby:
1) vetsina prace se odehrava u browseru, emalu a kancelarskych aplikaci a u vsech tehle programu jde paralelizace udelat bez problemu (napriklad jeden thread pro samotne GUI, jeden pro IO operace, treba nekolik napriklad pro vypocty v excelu). Dobre to je videt na Google Chrome jak i u neceho tak nenarocnyho jako je webrowser, muze multithreading pomoci k vyssimu vykonu.
2) Vykon CPU je dnes takovy, ze malokdo potrebuje vetsi vykon pro praci v kancelarskym baliku. A proto ani neni vule vice paralelizovat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  30. 01. 2009 09:49  |  Microsoft Windows XP IE 7.0

1) Ten Chrome by měl vyšší výkon i na jednojádru. Nezlobte se na mě, ale uvádět prohlížeč jako důvod paralelizace je směšné. Ukažte mi procesor, který nestíhá zpracovávat datový tok 1-4 MBit v reálném čase.
2) No přesně tohle tvrdím. Když to nic nepřinese, tak proč to dělat? To je snad logické

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
29. 01. 2009 02:31 | Microsoft Windows XP Maxthon 7.0

Spis je problem u vyrobcu, kteri misto toho aby vytvareli vykonejsi CPU, presouvaji problem na programatory.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 02:42  |  Linux Mozilla 1.9.0.5

ja to rozhodne nevidim jako presouvani nejakeho problemu, je to zcela prirozeny vyvoj. naopak vykon cpu roste daleko rychleji, jen ho vyuzit. graficke cipy maji uz dnes 1000+ jednotek, je to v soucasnosti jedina mozna cesta v honbe za vykonem.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  29. 01. 2009 22:17  |  Microsoft Windows Server 2003 IE 7.0

Z mého pohledu výkon procesorů už cca pět let stagnuje. Protože mít nový hardware, který je výkonnější jen někdy (za specifických okolností) není žádný pokrok. Grafické karty bych sem netahal, u nich je k paralelizaci prostor a software je jim přímo přizpůsoben a to při přijatelných nákladech (driver dělá výrobce grafické karty). Ekonomickou efektivnost přesunu problému s nedostatkem výkonu z výrobců CPU na programátory nevidím.

Souhlasím  |  Nesouhlasím  |  Odpovědět
BlackRider  |  30. 01. 2009 09:12  |  Microsoft Windows XP Firefox 3.0.6

Vykon procesoru stagnuje protoze dnes uz nikdo vykonejsi CPU nepotrebuje. U desktopu ten vykon dopredu tlacily hry, ale ty si dnes uz vystacej s vykonnou grafikou a na CPU nejsou tak zavisly.
Dnes tahnou vykon nahoru uz maximalne servery a ty vyuzivaj multiprocesing a multithreading uz leta, takze zvysovani pocet jader je pro vyrobce procesoru nejsnadnejsi a nejshudnejsi reseni.
Prijde mi ze se Gartner potreboval po delsi dobe zviditelnit, a tak vydal zpravu, ktera by snad jako spekulace mela nakou relevantnost pred peti lety. Ovsem media se chytej kazdy blbosti...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  30. 01. 2009 23:20  |  Microsoft Windows Server 2003 IE 7.0

Ale to přece není vůbec pravda. Dnešní levný procesor sice stačí na valnou většinu úloh, ale stále jsou takové, kde je výkonu velký nedostatek. A rozhodně se nejedná jen o úlohy paralelizovatelné.

Souhlasím  |  Nesouhlasím  |  Odpovědět
BlackRider  |  31. 01. 2009 00:02  |  Microsoft Windows XP Firefox 3.0.5

Napriklad?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  31. 01. 2009 12:21  |  Microsoft Windows Server 2003 IE 7.0

Tak například starší počítačové hry se softwarovým renderingem, které bychom chtěli hrát v rozlišení dnešních monitorů. Nebo rozsáhlé strategické hry, které nejsou optimalizované (např. Civilization III, částečně i Civilization IV).
Dále třeba makra ve VBA - spousta "softwarů" používaných ve finančním sektoru je dělána ve VBA. To ale samo o sobě neumožňuje multithreading (podpora tam není) a i kdyby umožňovalo, lidé píšící tyto makra by to nezvládli (nejsou to profesionální programátoři). Některá tato makra mohou jet i hodiny denně.
Pak také komprese audia, videa a dat, pokud nechceme přijít o výstupní kvalitu.
A to jsem uvedl programy, které jako celek mají potíže. Pak jsou i dílčí náročné úlohy, které trpí tím samým. Obecně lze tyto problémy "řešit" tím, že narušíme integritu dat - to se dneska běžně děje u počítačových her, kde nějaká nepřesnost výsledku nevadí. Jenže to si nemůžeme dovolit všude.

Souhlasím  |  Nesouhlasím  |  Odpovědět
29. 01. 2009 05:02 | Linux Mozilla 1.9.1

To neni ani tak odmitavost, ale vetsina programu vic jader proste nema cim vyuzit. Ano vetsina se jich da paralelizovat ale vysledek je jen zbytecne narocnejsi na cpu protoze pak na sebe vlakna vecne navzajem cekaj, museji resit pristup ke spolecnym datum atd.
S 64bit je problem hlavne na woknech. Sam sem si to vyzkousel kdyz mi uzivatel mi hlasil problemy s kompilaci programu na linuxu, hazelo mu to pri kompilaci chyby ktery mi compiler neukazal. Nakonec sem zjistil ze ma 64bit linux a kompiluje tak 64bit verzi. Patchovani probihalo stylem ze on mi napsal co mu to hlasi a ja mu vratil co ma opravit, cely to trvalo asi pul hodiny. Portaci toho samyho programu na woknech sem ztravil haldu hodin pri dohadovani se s tim bazmekem od microsoftu jmenem visual studio (pokud vim jinej pouzitelnej c/c++ compiler pro 64bit na woknech stale neni) To se pak clovek nemuze divit ze nikdo radsi 64bit programy nedela.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tehomas  |  29. 01. 2009 10:03  |  Microsoft Windows XP Firefox 3.0.5

Neni pravda, ze neexistuje jiny kompilator pro windows. Zkus intel. Mam pocit, ze generuje o poznani vykonnejsi kod.
A co se tyce toho, zes mel problem s preklopenim na 64bit na visual studiu - opravdu bych rad vedel, cos delal. S tim nikdy zadne problemy nebyly. Naopak gcc mi nekdy bez kecu prelozilo kod, ktery byl ponekud pochybny, zatimco ms mi vyhodil warning, ze tady bych mohl narazit, pripadne nektere praktiky rovnou oznacil za chybu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
29. 01. 2009 17:05 | Linux Mozilla 1.9.1

Zkusit intel me nenapadlo, ale i kdyby tak ten nepripada v uvahu vzhledem k tomu ze pozadavek je pokud vim intel procesor a to po uzivatelich nemuzu chtit (ja vim ze ono to co to vytvori beha i na amd ale neni to ono).
Provadel sem to ze sem chtel kompilovat program vyuzivajici integery z c99, neco co borlandi compiler (ktery pouzivam ke kompilovani 32bit verze pro windows) umi spoustu let, stejne tak gcc na linuxu. Microsofti compiler je neumi. Nasledovala halda warningu pokud se nepletu diky size_t ktery je na 32bitu signed a na 64bitu unsigned a pak dalsi halda diky tomu ze na woknech je nelogicky na 64bitu int jen 32bitovy.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 15:41  |  Linux Mozilla 1.9.0.5

VS je imho nejlepsi IDE - nemluvim o rychlosti prelozene binarky (to neumim posoudit), ale o moznostech IDE. po prechodu na linux jsem byl zdesen malymi moznostmi tamnich IDE, proto me velmi zajima, co pouzivate, rad bych se inspiroval - predevsim mi jde o debugging, ktery se pod linuxem snad neda ani povazovat za debugging. jo a jde mi o C++, jinde je situace asi jina.
s 64bit by pri kompilaci nemely byt zadne problemy, jen nejspis par warningu u konverzi, ktere lze zpravidla jednoduse opravit (treba size_t ma jinou velikost a prevody na unsigned neprojdou). ve VS se da zapnout detekce moznych chyb pri prechodu na 64bit, takze ani nemusite byt v 64bit systemu. kazdopadne nejsou tam zadne zasadni problemy, proto se prave divim, ze je tak pomaly prechod.

Souhlasím  |  Nesouhlasím  |  Odpovědět
29. 01. 2009 17:35 | Linux Mozilla 1.9.1

Ja netusim co kdo vidi na vs tak uzasnyho ale mozna je to tim ze mi vicemene staci textovy editor se zvyraznovanim syntaxe. Takze na windows si vystacim s dev-cpp a na linuxu s anjutou. Program testuju na linuxovem vserveru, takze pri debuggingu pouzivam gdb z prikazove radky. Pokud se s tim clovek nauci tak poslouzi velmi dobre. K tomu jako doplnek pouzivam google-perftools (heap-checker, heap-profiler a cpu-profiler).
Problemy pri kompilaci bohuzel jsou, a bohuzel to neni jen par warningu. V mem pripade slo o chybejici podporu C99 integeru a spoustu warningu diky size_t a tomu ze int je pouze 32bitovy. Na to ze slo o relativne jednoduchy program behajici jako konzolova aplikace nebo windows service to neprijemne prekvapilo. V pripade kompilace neceho slozitejsiho s gui tech problemu vyskace mnohem vic (i kdyz vetsina je chyba programatora.. veci ktery ve 32 bit nejsou problem ale v 64bitu jsou chyba).

Souhlasím  |  Nesouhlasím  |  Odpovědět
hanur  |  29. 01. 2009 20:35  |  Linux Mozilla 1.9.0.4

Ja pouzivam
Eclipse + CDT + GCC + GDB + Mylyn + Subclipse
Maximalna spokojnost

Souhlasím  |  Nesouhlasím  |  Odpovědět
BlackRider  |  30. 01. 2009 09:23  |  Microsoft Windows XP Firefox 3.0.6

Pokud na sebe vlakna musej cekat, tak nekdo udelal chybu u vlakna, ktery ma ty vypocetni vlakna obsluhovat. Multithread aplikace pokud je dobre napsana, tak neni duvod, aby mela vetsi rezii nez single thread aplikace o vic jak jednotky procent.

Souhlasím  |  Nesouhlasím  |  Odpovědět
lemming  |  29. 01. 2009 08:09  |  Microsoft Windows XP Firefox 3.0.5

Zajimalo by mne, kde berete tu jistotu, ze "vetsina problemu je nejakym zpusobem vice ci mene paralelizovatelnych". Problemu obecne mozna, ale problemu ktere bezne resi pocitace uz o dost mene.
A navic:
a) Ma smysl paralelizovat program, ktery vyuziva jedno jadro maximalne na 10% tak, aby vyuzival dve jadra, kazde na 5%? Vetsina programu totiz nevyuziva na 100% ani jedno jadro; brzdou je spise rychlost disku.
b) Ma smysl nakladne paralelizovat operaci co ji uzivatel vyvola cas od casu a ona trva 0.5 sekundy tak, ze pak trva 0.3 sekundy?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  29. 01. 2009 08:53  |  Microsoft Windows XP Opera 9.61

Tak zrovna tyto programy nema smysl paralelizovat. Smysl to ma u programu, ktere zpracovavaji vetsi baliky dat. Zpracovani zvuku, obrazu, 3D sceny, modelovani procesu,...
U beznych programu (text procesor, WWW prohlizece) paralelizace muze trochu pomoct, ale s mensim efektem. (Rychlejsi otvirani a ukladani souboru, rychlejsi renderovani slozitejsich stranek)

Souhlasím  |  Nesouhlasím  |  Odpovědět
lemming  |  29. 01. 2009 09:10  |  Microsoft Windows XP Firefox 3.0.5

Ano, to jsem presne mel na mysli kdyz jsem rozporoval tvrzeni ze "vetsina problemu je paralelizovatelnych". Z tech veci co dela bezny uzivatel je to maximalne tak kodovani nejakeho videa/audia, co je rozumne paralelizovatelne...

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 15:50  |  Linux Mozilla 1.9.0.5

ahmdaluv a gustaffsonuv zakon. mozna jsem byl nepresny - kazdy problem ma sekvencni a paralelni slozku, u kazdeho je pomer jiny. pro vetsi instance problemu dochazi u nekterych problemu az k linearnimu zrychleni v zavislosti na poctu vyp.jednotek.
to, ze vetsina problemu je paralelizovatelnych ale neimplikuje, ze se ma vetsina problemu paralelizovat, to jste me spatne pochopil. samozrejme souhlasim, ze to chce aplikovat jen tam, kde to ma smysl. myslim ale, ze u clanku o vykonu cpu se bavime o aplikacich narocnych na cpu, tudiz tech, kde se stale zkouma, jak je zrychlit.

Souhlasím  |  Nesouhlasím  |  Odpovědět
satai  |  29. 01. 2009 08:38  |  Macintosh OS X Firefox 3.0.5

Ona je tu i druha strana. A to, ze programatori maji vetsinou na starost existujici kod, ktery s vicevlaknovosti moc nepocita. A i kdyby mohli zacinat na zelene louce, tak neni po ruce moc nastroju, ktere by jim pomahaly.
Troufnu si soudit, ze 8+ jader bude pozadovat velkou zmenu v pristupu. Minimum "mutable" dat, velkou inspiraci funkcionalnim programovanim (presne to, na co na vejsce vsichni kaslali, protoze to "je na nic"), nove jazyky ve stylu Erlangu, Scaly, F#, hodne asynchroniho kodu. Samozrejme je mozne pokracovat i se starymi nastroji, rekneme s javou nebo nedejboze C, ale s takovym pristupem bude programator celit dost problemum a tak jako tak bude muset zacit myslet jinak.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Nemo7  |  29. 01. 2009 10:48  |  Linux Mozilla 1.9.0.5

>> tak jako tak bude muset zacit myslet jinak
Pokud by lidé mysleli jinak, tak funguje i komunismus. Myslím, že se asynchronní kód prosadí pouze v případě, že se na něj bude optimalizovat automaticky a s malou námahou, nejlépe v existujících jazycích. Můj názor je, že jakmile se to "blbě" představuje a "blbě" ladí, tak do toho žádný programátor moc rád nepůjde. Proč řešit zbytečně souběh(race condition), přemýšlet, kde může nastat a přidělávat si s tím práci ? Jenom aby programátor udělal radost Intelu a řešil to týdny navíc ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
satai  |  29. 01. 2009 14:11  |  Macintosh OS X Firefox 3.1

Myslim, ze je torchu rozdil mezi komunizmem a pristupem k programovani. Trebas protoze prechod ke komunismu vybuchl vsude, zatimco zmenu paradigmatu jsem uz nekolikrat usatly (a ze trebas OOP je uplne ijne mysleni nez strukturovane prgani).
Jinak mate pravdu v tom, ze to je v ledascems tezsi. Ale v tom mohou doceal rozumne pomoci nastroje a metodiky. Zadny raj na zemi to nebude, ale s dobrou podporou to neni to zas o tolik tezsi nez objektove mysleni.

Souhlasím  |  Nesouhlasím  |  Odpovědět
kareI  |  29. 01. 2009 11:30  |  Microsoft Windows XP Firefox 3.0.5

S tim "myslenim jinak" bych spis zacal. Nektere jazyky paralelni algoritmy usnadnuji vice, jine mene, ale v prvni rade si musi autor ujasnit, jak na to, jake jsou toky dat a kdy se na co ceka atd. Bez toho nenapise dobry algoritmus i se sebelepsima nastrojema.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 16:00  |  Linux Mozilla 1.9.0.5

to je presne ono - "myslet jinak"
kdyz jste zacal programovat, taky jste zacal myslet jinak (nekteri z nas zacali myslet jinak i v real.zivote :))
jak pisete, prechod na paralelni kod lze ubirat smerem k ciste objektovym jazykum (smalltalk), vetsimu zapouzdreni a nezavislosti objektu s komunikaci mezi nimi. ale lze to resit i na nizsi urovni klasicky s hlidanim kritickych sekci, navic v imperativnim OO jazyku lze docela dobre umele vytvorit prostredi zminenych nezavislych objektu. smer se tedy ubira k jinym jazykum, ale rozhodne to neznamena nutnost na ne prechazet, staci se inspirovat tim, jak funguji a podle toho 'myslet jinak' :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  29. 01. 2009 13:21  |  Microsoft Windows XP IE 7.0

Programátoři nejsou neschopní. Neschopní jsou ti, kdo si myslí, co všechno nejde paralelizovat. Bohužel vás musím zklamat. Na desktopu, který je největším odbytištěm CPU, nelze paralelizovat prakticky nic. Typické záležitosti jako surfování po internetu, čtení emailů, psaní dokumentů nebo dělání tabulek nelze paralelizovat.
Skutečně bych rád věděl, co chcete na desktopu paralelizovat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Alterovo Ego  |  29. 01. 2009 13:46  |  Microsoft Windows XP Chrome 1.0.154.43

No tak třeba na začátek to, co hrne vývoj do předu krokem patřičně svinským. Hry. Pak tu máme takové ne příliš využívané blbinky, jako SW na úpravu obrázků jak obyčejných, tak i pohyblivých.
Druhá strana mince je taky to, proč mi OS cpe tři současně běžící aplikace na jedno jádro, zatím co druhé se nudí a šťourá v nose. Dál tu jsou takové nepodstatné drobnosti, jako proč mi jedna aplikace dokáže takovou kravinou, jako je zjišťování dostupnosti dat na síťovém úložišti, zaměstnat celou mašinu tak, že si nepřehodím ani dvě běžící aplikace do popředí. A pokud se nepletu, tak OS se dá taky považovat za SW a že tam by toho bylo třeba k paralelizování tuna. Takže z pohledu uživatele v celkovém objemu ano, programátoři jsou neschopní.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  29. 01. 2009 14:24  |  Microsoft Windows XP IE 7.0

Většina z těch přípádů, co jste jmenoval, není paralelizace, ale multitasking. To, že běh jedné aplikace brzdí běh druhé, bych teda nerozebíral. Stejně tím využijete jen pár jader, u čtyřech - když to hóóódně nafouknu - končíte.
Hry ano, ale nejsem si jistý, jestli tohle je ten správný segment pro prodej široké škály CPU, protože tady se čím dál víc uplatňují specializované konzole. Navíc hodně nových her paralelismus stejně využívá, takže programátorům není co vyčítat.
Na úpravu obrázků stačí s přehledem současný HW a editace videa je dost specifická oblast.
Čili podle mě jste neuvedl jediný argument, který by nabízel nějakou rozumnou paralelizaci.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  29. 01. 2009 14:38  |  Microsoft Windows XP Opera 9.61

V dobach, kdy domaci pocitace casto slouzi jako PVR, a kdy ma temer kazdy digitalni fotak a mnoho dalsich kameru ty obrazky a video moc vynechavat nemuzeme...
Mate pravdu v tom ze mnoho z drive uvedenych pripadu jsou na multitasking a blbe navrzeny system.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  29. 01. 2009 15:01  |  Microsoft Windows XP IE 7.0

Osobně mám 10Mpx Canon a fotky upravuju v Zoner Photo Studiu 2007 na notebooku s 1GB RAM a CPU 1,7 GHz, který ale stejně věčně jede pod 1GHz. Nemám s odezvou systému ABSOLUTNĚ žádný problém.
Do videa nedělám, zrovna jako 99% všech ostatních uživatelů, protože na střih prostě nemají čas. Ano, editace videa je oblast, kterou je možné velmi dobře paralelizovat, nicméně ji využije tak málo lidí, že je to o ničem.

Souhlasím  |  Nesouhlasím  |  Odpovědět
V0cas  |  29. 01. 2009 21:19  |  Microsoft Windows Vista Firefox 3.0.5

to ze Vam to jde na notebooku nic neznamena, dneska je trend miniaturizace a snizovani spotreby vseho a tam se to bez multicore neobejde, protoze se zvysovanim frekvence jde nahoru spotreba kvadraticky (kvuli nutnosti zvysovat napeti) a zvysujici se mira integrace narazi na limity, ze nedokazeme patricny pocet tranzistoru v jednom jadre vyuzit!

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  29. 01. 2009 22:13  |  Microsoft Windows Server 2003 IE 7.0

Se zvyšujícím se počtem jader ale spotřeba taky roste. A logicky pokud má dvoujádrový procesor dvojnásobek transistorů, pak jeho spotřeba je za stejných parametrů dvojnásobná. A to bez ohledu na to, zda se jedná o maximální spotřebu nebo spotřebu při nevytížení - jednoduše řečeno problém se spotřebou stále zůstává, jen se objevuje z jiného směru.

Souhlasím  |  Nesouhlasím  |  Odpovědět
V0cas  |  30. 01. 2009 19:35  |  Microsoft Windows Vista Firefox 3.0.5

Asi jste nepochopil muj prispevek. U jednojadra neprekrocite pri dnesnich technikach programovani hranici CPI = 1 (cycles per instruction) proto nemate jinou sanci na vyssi vykon nez zvysovat jeho frekvenci ktera si vynuti zaroven zvysovat napeti (narust spotreby je pak kvadraticky). Vyssi mira integrace sama o sobe frekvenci bez zvysovani napeti tolik nezvysi. Zaroven take musite zvetsovat cache kvuli prodluzovani pipeline, takze moc plochy cipu neusetrite. To je to na co dojel PIV.
Jinak dvoujadrovy procesor neznamena automaticky dvojnasobny pocet tranzistoru. Pokud zachovate velikost cache tak se zvedne plocha treba jenom o polovinu. Je pravda ze mensi cache na jadro bude mit dopad na vykon, ale ten se nepropadne nijak zasadne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ustijuf  |  30. 01. 2009 20:52  |  Microsoft Windows XP Chrome 1.0.154.43

Ale od PIV tu bola predsa architektúra jednojadra Conroe-L, ale tá sa dávno nevyvíja. Ostatne aj VIA Isaiah architektúra je silnejšia výkonnejšia ako PIV a na nižších frekvenciách (ale tá je určená niekde inde).
Ak by Intel pokračoval vo vývoji jednojadra, predsa len od uvedenia Conroe-L pretieklo už veľa vody a tebars by tam dal aj HyperThreading fetiš mohli by sme mať lacnejšie, menej žravé CPU.

Souhlasím  |  Nesouhlasím  |  Odpovědět
V0cas  |  30. 01. 2009 23:10  |  Microsoft Windows XP Firefox 3.0.5

Je videt ze technologii procesoru nerozumite. To ze Conroe-L bylo vykonnejsi bylo dano komplexnejsi strukturou a kratsi pipeline, coz vedlo k lepsimu IPC, jenze kratsi pipeline zase znamena nizsi frekvence. Muzete treba dat do jadra vice vypocetnich jednotek, jenze bez optimalizace SW to vykon uz nezlepsi. U jednojader je proste jedina cesta zvysovani frekvence coz nezvratne vede ke spotrebe. Priklad: pro 2x vyssi frekvenci potrebujete o polovinu vyssi napeti, to samo o sobe zvedne spotrebu 2,25 nasobne a dvojnasobna frekvence dale zvedne spotrebu 2x, takze jsme na 5,5 nasobne spotrebe pro 2x vetsi vykon!
Hyperthreading je zjednodusene emulace dualcore, bez optimalize pro vicevlaknovy provoz to vykon nezvedne. Krome toho to zveda pocet tranzistoru v CPU a tim take spotrebu.
Pokud chcete nizkou spotrebu v single core tak tu mate Atom. Ten je take krasnym prikladem toho ze dalsi zvysovani vykonu bez narustu spotreby je mozne pouze navysovanim jader. Proc myslite ze neudela vykonnejsi single core Atom? protoze uz by nebyl usporny a Intel to moc dobre vi ....

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  30. 01. 2009 23:39  |  Microsoft Windows Server 2003 IE 7.0

Kratší pipeline neznamená nutně nižší frekvence. Fakt si myslíte, že Pentium M s 12 stupňů pipeline a max. frekvencí kolem 2.5 GHz by mohlo v upravené a zesložitěné verzi s 14 stupňů pipeline (= Core 2) dosáhnout frekvence 3.5 GHz ? To asi těžko. Počet stupňů pipeline je pouze jedním z faktorů, ale lineární úměra počtu stupňů a frekvence neexistuje.
"Muzete treba dat do jadra vice vypocetnich jednotek, jenze bez optimalizace SW to vykon uz nezlepsi." - To přece není vůbec pravda. Vše závisí na instrukčním okně a sekvenci instrukcí. Moderní CPU jednotky duplikují jen u primitivních ALU operací, vše ostatní vychází z toho, že v běžném kódu se vyskytuje mix různých instrukcí, které je možné v rámci okna přesouvat. Takže i bez optimalizace SW je možné na novém CPU dosáhnout vyššího výkonu za hodinový cyklus.
U vícjader je také jedinou cestou zvyšování výkonu zvyšování frekvence. Protože když software další jádra nevyužije, tak jsou k ničemu a jen naopak snižují dostupný výkon (tyto jádra totiž taky něco spotřebují, i když nic nedělají). Fyzikální omezení nevyřešíte přidáním více jader a snížením frekvence.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ustijuf  |  31. 01. 2009 00:14  |  Microsoft Windows XP Chrome 1.0.154.46

Skutočne nenapadá ma čo viac dodať. Veľmi pôsobivé (všetky príspevky)

Souhlasím  |  Nesouhlasím  |  Odpovědět
V0cas  |  31. 01. 2009 16:47  |  Microsoft Windows Vista Firefox 3.0.5

Pokud budeme uvazovat stejnou vyrobni technologii, tak pri kratsi pipeline musi byt kazdy stupen slozitejsi, abysme dosahli stejneho vysledku jako u delsi pipeline. To je snad jasne. Tim je dano omezeni frekvence. Proste slozitejsi stupen nemuze dosahnout takove maximalni frekvence diky vetsimu zpozdeni, jako jednodussi stupen u delsi pipeline. Maximalni frekvence pak bude odpovidat maximalni frekvenci nejslozitejsiho/nejpomalejsiho stupne pipeline.
Asi se shodneme na tom, ze optimalizovat cokoliv nelze donekonecna, bohuzel. Od urciteho okamziku uz je takova optimalizace diky kritickym mistum v programu neefektivni. Amdahluv zakon hovori jasne. A je jedno jestli se jedna o optimalizaci kompilatorem nebo primo v CPU. Naopak vicejadro v idealnim pripade u vicevlaknove aplikace dokaze vykon skalovat umerne k poctu jader. V dnesni dobe je opravdu mozne vetsinu SW, ktery je opravdu narocny na CPU, paralelizovat. Ten zbyly SW zase tolik vykonu nepotrebuje, takze v tom nevidim rozpor.
Kdyz to shrnu tak v dnesni dobe je vykon jednoho jadra pro neparalelizovatelne ulohy dostatecny, nema nejaky zvlastni vyznam dale VYRAZNE zrychlovat vykon jednoho jadra na ukor spotreby. Ty zbyle ulohy staci upravit pro multicore a vykon nam poroste dale velmi vyrazne pri zachovani nizke spotreby.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  31. 01. 2009 17:43  |  Microsoft Windows Server 2003 IE 7.0

Jak už jsem uvedl níže, rozhodně nelze tvrdit, že výkon na jedno jádro je dostatečný. Existuje spousta úloh, které takový výkon vyžadují a kde je ho stále velký nedostatek. Převádět software na multithreaded lze často jen na úkor integrity dat - a o to já opravdu nestojím.
ad vícjádra - S rostoucím počtem jader klesá i při stejné frekvenci výnos na další jádro a to i u dobře optimalizovaných úloh (z důvodu režije při synchronizaci).... až se tento výnos stane negativním. Přičemž dále platí, že čím víc jader, tím nižší frekvence (fyzikální limity). Vícjádra tedy efektivně snižují výkon u neoptimalizovaných úloh, zatímco u optimalizovaných jsou ho schopny zvyšovat jen do určitého počtu jader. S přehnaným množstvím jader ho také snižují. A tyto poklesy jsou v desktopu, kde je optimalizace těžko realizovatelná, značné. Navíc, vícjádra jsou snadno nahraditelná pomocí více jednojádrových procesorů, jejichž frekvence může být vysoká. A já osobně bych byl mnohem radši, kdyby bylo na trhu 5 GHz jednojádro se 150 W a snadné možnosti pořízení vícesocketu, než 150 W čtyřjádro na 3.5 GHz.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  31. 01. 2009 18:43  |  Microsoft Windows XP Opera 9.61

Zajimalo by mne, co je podle vas "Na ukor integrity dat" Tohle obvykle znamena naprostou nepouzitelnost a takovy algoritmus nikdo programovat nebude. Ani v nejvykonnejsich pocitacich nejsou procesory taktovane nad 5 GHz ( mozna se mylim) Pokud nekdo paralelizovat chce a uloha to umoznuje, tak to udela ciste.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  31. 01. 2009 21:03  |  Microsoft Windows Server 2003 IE 7.0

Na úkor integrity dat znamená např.:
1) U komprese binárních dat, jejíž algoritmus využívá ke kompresi dat v místě X+1 podobnost s daty v místě X to, že celý soubor dat je rozdělen na více částí, z nichž každá je komprimována separátně. Podobnost je v místě rozdělení narušena. Toto využil WinRAR.
2) U komprese audio / video dat obdobnou situaci jako u komprese binárních dat, pouze s tím rozdílem, že namísto podobnosti binárních dat jde o podobnost obrazů / zvuků. Toto využívá řada složitých kodeků (čím složitější, tím větší závislosti).
3) U her to, že sekvenční úlohy jsou předělány na paralelní na úkor ignorování kolizí. Příklad: Mějme panáky 1 a 2, kteří se pohybují proti sobě (x jsou možné pozice). Výchozí stav je:
1xxx2
V sekvenčním zpracování bude postup kroků následující:
x1xx2
x1x2x
xx12x
vyhodnocení kolize
V případě paralelního zpracování budou kroky následující:
x1x2x
xx1xx a zároveň xx2xx - zde dojde k ignorování kolize
Dalším narušením integrity dat u her je nutná logická sekvence těchto úkonů: reakce hráče -> fyzika -> grafika a zvuk. Těžko je možné počítat fyziku paralelně, když nejdřív je potřeba zjistit, jaké klávesy hráč stisknul, tj. kam se má panák hýbat. Tím, že je fyzika počítána bokem, se vnáší předpoklad, že hráč setrvá v minulých úkonech (např. pohyboval se vpřed, tak počítám fyziku na pohyb vpřed - to ale vnáší chybu, pokud se hráč začal pohybovat doleva).

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  31. 01. 2009 21:36  |  Linux Mozilla 1.9.0.5

to jsou naprosto nepresne zavery, rekl bych az blaboly.
komprese sice vyuziva toho, co pisete, ale vetsinou pouze v ramci omezene casti - nebo snad (nejen) streamovane video musi byt nacteno cele, aby se prehralo?? to, o cem mluvite je analyza dat, ta se da taky paralelizovat, vysledky slozit dohromady, distribuovat a kodovat opet paralelne - velmi hruby nastin. SKORO NIKDY NENI PARALELIZOVAN CELY PROBLEM! nerikam, ze to jde u vsech typu kompresi nebo konverzi, spis naznacuji moznosti.
ten priklad s hrou sice plati, ale takovy to pristup je naprosto amatersky. fyzika, AI, ovladani, rendering samozrejme jdou paralelizovat bez jakychkoliv ztrat presnosti nebo snad dokonce funkcnosti. problem, o kterem mluvite, je synchronizace. vykresleni jednoho snimku znamena spocitat fyziku, AI, zmeny v geometrii a cele to vykreslit. tyto kroky sice na sobe do jiste miry zavisi, ale zase ne vsechno na vsem. co takhle rozdelit objekty a entity na ty, co se mohou ovlivnovat a na ty co ne, podle toho pak rozdelit ukoly vlaknum a pripadne synchronizovat?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  31. 01. 2009 22:30  |  Microsoft Windows Server 2003 IE 7.0

Pokud podle vás komprese využívá dané věci jen v omezené části, tak jak je možné, že výsledný soubor není binárně identický? Není to třeba o tom, že ona část závislostí není dána fixně, ale podle závislostí na předchozích datech? Fakt by mě zajímalo, proč když je to tak jednoduché, ty soubory nejsou stejné a proč se u video kodeků uvádí, že multithreading vede k poklesu výstupní kvality. Jak s tím souvisí streaming, to tedy nevím, řešíme tady snad enkóding, ne dekódování.
Amatérský? A jak to podle vás v reálu vypadá? Na tomto příkladu není nic amatérského. Celý multithreading je o synchronizaci, takže tu poznámku ve stylu paralelizace != synchronizace nechápu. Rozdělit entity na ty, které se mohou ovlivnit a které ne? A jak to chcete předem zjistit? To, jestli se ovlivní nebo ne, je právě výsledkem výpočtů. Kdybyste to věděl, tak přece nemusíte nic počítat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  31. 01. 2009 23:06  |  Microsoft Windows XP Opera 9.61

Ale ona vyuziva dat jen v omezene casti. Pokud MT verze kodeku dava horsi vysledek, nez ST verze, pak je kodek naprogramovan blbe. Pokud pri ruznych postupech je vysledkem binarne jina podoba dat, nemusi to byt problem, zvlast u ztratovych kodeku. Napr. i bezztratova komprese obrazu: PNG. Muzete dostat kompresi ruzne soubory z jednoho zdroje. Ale je tam stale presne stejny obrazek (zrovna tomuhle jsem nedavno nechtel moc verit, tak jsem si to overoval a az nasledne zjistoval info o formatu)
U video souboru se uvazuje jen omezena zavislost na predchozi scene. Kdyby byla delsi zavislost, znamenalo by to, ze kdyz otevrete soubor, z nejakeho duvodu se rozhodnete se divat az od 60minuty videa (treba proto, ze pprvni pulku jste videl vcera), tak nez se zacnete koukat, prehravac bude treba pul hodiny zpracovavat onech 60minut aby mel vsechna data potrebna pro prehrani daneho snimku. Proto jsou v obraze klicove snimky, ktere obsahuji plnou informaci o obraze a prehravac zacne soubor zpracovavat az od nejblizsiho predchazejiciho klicoveho snimku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  01. 02. 2009 00:01  |  Microsoft Windows Server 2003 IE 7.0

Tak v tom případě jsou kodeky naprogramovány blbě .
Výsledně jiná binární podoba je přece špatně. Programové úlohy mají jasný sled činností a musí vést k jednomu konkrétnímu výsledku. Pokud budu mít nekomprimované video (tj. samé klíčové snímky) a vedle něj bezztrátové video s kompresí, tak je to pro uživatele ekvivalentní, ale ten správný výsledek je jen jeden - ten, který má menší požadavky na objem dat. Když to převedu na klíčové snímky - jejich poloha ve filmu závisí na podobnosti (rozdílnosti) s předchozími snímky. Pokud video roztrhnu na dvě části a každou začnu klíčovým snímkem (abych je mohl zpracovávat paralelně), tak nutně onen klíčový snímek v druhé části nijak nerespektuje závislost na předchozích datech. To znamená, že v jednovláknovém zpracování by na daném místě třeba vůbec klíčový snímek umístěn nebyl, protože změna oproti předchozímu snímku by ho nevyžadovala. Rozdělením souboru naruším integritu dat, protože takto zpracovaný soubor bude nutně o onen jeden klíčový snímek větší nebo bude při zachování stejné velikosti nutné ubrat z kvality.

Souhlasím  |  Nesouhlasím  |  Odpovědět
V0cas  |  01. 02. 2009 00:30  |  Microsoft Windows XP Firefox 3.0.5

Ted jste to hezky popsal,ale fakticky potvrzujete ze se jenom tahate za slova. Jeden klicovy snimek navic kvalitu nesnizi, je pravda ze video o nejakych zavratnych treba 50kB nafoukne, ale to je snad jedno. Mnohem dulezitejsi je ze ho zkomprimujeme 2x rychleji popripade muzeme ten cas navic venovat lepsi kvalite komprese a dosahnu lepsiho vysledu ve stejnem case. Ja jsem se treba na DC naucil pouzivat lepsi kompresi i lepsi kvality filtru...

Souhlasím  |  Nesouhlasím  |  Odpovědět
V0cas  |  01. 02. 2009 00:36  |  Microsoft Windows XP Firefox 3.0.5

A ted jsem si jeste uvedomil jednu vec. Nemusite do videa doprostred natvrdo vlozit klicovy snimek, ale muzete v tom miste zacit hledat kde ho umistite. Na danem miste zacne druhe vlakno komprimovat a prvni vlakno komprimaci u nej dokonci. V tom pripade dosahnete i binarne stejneho vysledku se zrychlenim blizici se 2. Vse tedy zalezi na konkretni implementaci...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  01. 02. 2009 00:53  |  Microsoft Windows Server 2003 IE 7.0

Začít ho hledat jde dost těžko, když nevíte, co před ním máte a co nemáte a kdy byl naposledy vložen (aby právě fungovalo ono rychlé přetáčení). Navíc čím složitější kodek použijete (tedy čím časově náročnější), tím víc v něm bude závislostí a tím víc porušení integrity dat při paralelním zpracování. To s jedním klíčovým snímkem byl jen příklad, v reálu můžou být rozdíly mnohem větší, zejména když se pokusíte paralelizovat i jiným způsobem (u H.264 bylo uživateli hlášeno, že zejména v tmavých scénách s malým datovým tokem lze pozorovat rozdíly ve výstupní kvalitě). Každopádně výsledek je ten, že soubory nebudou stejné, což značí, že něco evidentně není úplně v pořádku. A ano, je to otázkou implementace - s těmito zásahy může být multithreading relativně jednoduchý, bez nich naopak často nerealizovatelný. To je otázkou preferencí uživatele. Obdobně pak i třeba "optimalizace" 64bit SSE2 vs. 80bit FPU. Já si klidně na nejlepší možnou kvalitu počkám.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  31. 01. 2009 23:11  |  Linux Mozilla 1.9.0.5

ad1)
dekodovani-streamovani beru zpet.
nechapu, co ma byt s cim identicke?
pro vetsinu kompresi a koderu staci analyza (klidne paralelni) a pak paralelni komprese - vychazeji vsechny ze stejne analyzy. nerikam, ze to bude rychlejsi, to nedokazu posoudit, ale paralelizovat by mela jit vetsina kompresnich algoritmu. takovy JPEG napriklad ma paralelni zrychleni skoro linearni.
ad2)
psal jste o nejakem kolidujicim avatarovi, ja rikam, ze to paralelizovat jde, staci synchronizace. v tomto konkretnim pripade by render vlakno cekalo na update geometrie, takze zrychleni zadne. pri analyze a vhodnem vyberu objektu, pro nez je nutne synchronizovat (rozumej seradit za sebe) faze vypoctu, lze dosahnout zrychleni, ktere bude zaviset zhruba na pomeru dynamickych a statickych objektu. 1 vlakno pocita AI, 2.vlakno pocita fyziku dynamickych objektu, 3.vlakno renderuje staticke objekty.
dalsi zrychleni: 2.vlakno prubezne posila vysledky tretimu, takze 3.muze pokracovat paralelne i po vykresleni statickych objektu. AI vlakno muze bezet temer zcela nezavisle, u vysledku AI neni pozadovana okamzita reakce na urovni jednotlivych snimku.
predevsim si vsimnete spolupraci 2. a 3. vlakna, na kterych jde videt, ze i na sobe casove zavisle akce lze provadet paralelne s limitne linearnim zrychlenim - paralela s pipeline v procesoru.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  01. 02. 2009 00:14  |  Microsoft Windows Server 2003 IE 7.0

ad 1} Identické mají být výstupní soubory, protože jinak je někde narušená integrita dat. Konkrétně třeba v oné analýze - tu přece nemůžu snadno provádět paralelně, když mám závislosti na předchozích datech. Pokud někde začnu odznova (což u multithreaded zpracování začnu), tak tuto závislost ignoruji. Konkrétní příklad JPEG neznám, ale z logiky věci mi vyplývá, že zrychlení tam být může (a to skoro lineární), ale taky to může být na úkor binární integrity - JPEG přece aproximuje původní obraz pomocí obdélníků / čtverců. Pokud obraz rozdělím na dvě půlky, tak v místě rozdělení může nastat situace, kdy jednovláknové zpracování by dalo jeden větší čtverec a dvě samostatná vlákna dají dva menší obdélníky. Jistě, šlo by to později korigovat sekvenční kontrolou těchto problémových míst, ale to zesložiťuje celý software a vede ke zpomalení.
ad 2) Lze s tím souhlasit, jen bych si dovolil oponovat v tvrzení, že u AI není požadována okamžitá reakce na úrovni jednotlivých snímků - v tomto případě totiž narušujete integritu dat, jelikož se program chová s různým počtem paralelních vláken rozdílně. U her to jistě příliš nevadí (tato nepřesnost nikoho pálit nebude), ale co u jiného software? Taky je samozřejmě v daném příkladu otázkou, nakolik bude renderování statických objektů náročné - ono totiž oněch statických objektů nemusí být mnoho, když je dnes tendence k tomu, aby se rozpadaly v hrách i zdi, aby panákům upadaly ruce atp. A to se vůbec nebavíme o tom, na kolik paralelních vláken je možné tyto úlohy dělit a zda je možné využít výsledky "core wars".

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  01. 02. 2009 00:55  |  Microsoft Windows XP Opera 9.61

(pardon cislovani mi nebude sedet s vasim, odpoidam na vic veci najednou)
1) Co je na vysledne rozdilne binarni podobe spatne, pokud oboji odpovida specifikaci a spravne reprezentuje zadani? Kdyz date dvom lidem za ukol popsat strom, je jeden s tech popisu spatne? Konkretne PNG dovoluje vic zpusobu komprese a pokud vim, tak se neda dopredu rict, ktery bude uspornejsi. Nektere implemetace pro nejvyssi kompresi testuji ruzne moznosti a vyberou nejlepsi vysledek. Zkusit vsechny moznosti ale neni realne a tak udelaji jen urcity pocet pokusu. Mohou testnout nekolik predem nastavenych metod, ale mohou take vybrat par metod nahodne. Vysledkem pak muzou byt ruzne sobory popisujici naprosto presne vzor.
2) Nechapu co presne myslite tou integritou. Podle mne integritaa znamena, ze data davaji smysl, neni v nich nesoulad, jsou spravne dekodovatelna dle specifikace.
3) JPG - zakladem je komprese dlazdic 8x8pixlu. Kazdy relevantni SW to samozrejme vi a vyuzivaji to programy pro bezztratovou editaci JPG obrazku (otoceni, oriznuti obrazu) neni problem obraz rozdelit prave s ohledem na dlazdice. Rika snad nekdo, ze pro dve jadra musim rozdelit obraz na rovnocene poloviny? mohu jej rozdeli klidnne na 50 dilu a ty pak postupne predhazovat dvema vlaknum. (jsou jeste dalsi vylepseni kvality, ktera v tom delaji trochu bordel, ale je to zvladnutelne a myslim, ze i zvladnute)
Hmm ano, tato vylepseni vedou dalsim ztratam vykonu, ale mame tu navyseni rychlostina 200% diky rozdeleni zpracovani na dva proudy a pak ztratu treba 10% k tomu aby se dodelalo to co neslo hned diky zavislostem.
4) video - klicovy snimek navic zpravidla neni problem. Navic pro starsi typy kodovani (nebudu mluvit zrovna o tom poslednim, protoze s tim nemam zkusenosti) se vkladali klicova snimky ve dvou pripadech: a) pri detekci zmeny sceny, b) pokud uz bylo prilis mnoho zmenovych snimku. Oboji je mozne vyhodnocovat pri predzpracovani snimku a pak by nedoslo k zadnemu zhorseni kvality ani velikosti souboru.
OK, jedna vec mne napadla, rizeni datoveho toku pri VBR rezimu pak muze byt nektera cast ulozena s mensi ci vetsi kvalitou, nez by odpovidalo klasickemu jednomu pruchodu. Ale u dvoupruchodoveho kodovani by too uz nemel byt problem, protoze data pro rizeni toku jsou zjistena a zpracovana prvnim pruchodem pro cely soubor.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  01. 02. 2009 10:26  |  Microsoft Windows Server 2003 IE 7.0

Špatně je na tom to, že ten soubor není stejný. Principem v programování je, aby se něco vypočetlo a aby ten výpočet vedl vždy ke stejnému výsledku, přičemž daný postup vede k nejlepšímu možnému řešení. Pokud se výsledek mění s tím, že je spočten na různém hardware, tak je něco evidentně špatně. K čemu mi bude, že 80bit FPU výpočet převedu na 32bit SSE2, tím ho urychlím 4x, když výstupní kvalita bude horší? A stejně u multithreadingu - čím víc vláken, tím častěji musí být porušeny logické závislosti a tím víc klesá kvalita.
WMV codec:
"Yes, although it's probably negligible in most cases. Multithreaded encoding is done by splitting up the image into splices and then encoding each splice in a separate thread. This can affect the estimations because each thread only has access to a part of the image."
LAME:
"Of course the MT version is of lesser quality if you want to use it in MT, as it requires to disable bit reservoir."
x.264 (MPEG 4 AVC):
"x264 has poor communication between threads regarding the state of the VBV buffer, meaning that it often runs out of bits to encode with and you get serious artifacting on some frames. When encoding a 1-hour TV show from DVD for my iPod I get about 20 or so VBV underflow warnings, even with the VBV patches applied. The underflows are much less frequent (though not eliminated altogether) when encoding with one thread."
VC1:
"Classic multithreaded encoding uses slices, basically cutting the frame into horizontal stripes which are encoded independently.
Speaking of our current VC-1 implementation, we do good rate control between the slices (so if one band has more detail, it'll get more bits than the other bands, in order to keep the overall level of compression constant in each frame). But motion vectors won't cross over between threads. Now, most video doesn't have that much vertical motion (most motion is horizontal), but a wide shot of a pogo-stick contest might not look as good at the same bitrate with 4-slices compared to a single-slice. But most of the time, its fine (especially when you factor in the more accurate work we can do within each slice given the greater horsepower). But we normally recommend to have at least 64 pixels per slice.
Our current codec implementation goes up to 4 slices per instance, and for >4 core machines, we find that doing temporal segmenting (encoding different parts of the movie at the same time) is a better way to speed things up further.
The big reason why codecs do this is because they're predicting future frames compared to the previously predicted frame, and things get gnarly when the reference frame is a different size than the encode frame. There are other approaches that are being looked at, but require more raw horsepower per pixel, and quite a bit more memory for the total encode. But for now, I think segment parallelism is the right approach for >4 core encoding."

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  01. 02. 2009 11:45  |  Microsoft Windows XP Opera 9.61

"Špatně je na tom to, že ten soubor není stejný. Principem v programování je, aby se něco vypočetlo a aby ten výpočet vedl vždy ke stejnému výsledku, přičemž daný postup vede k nejlepšímu možnému řešení." Je mnoho uloh, kde neni realne nalezt optimalni reseni. (ze skript: problem obchodniho cestujiciho). Najde se suboptmalni reseni, ktere se prohlasi za dostatecne dobre. Pouzivaji se napriklad geneticke algoritmy: Nahodne se zvoli nekolik pocatecnich reseni, ktere se pak algoritmus snazi obmenovat a vybira ty nejlepsi vezre, nejlepsi dosazenou pak prohlasi za finalni reseni. Ale nikdo nedokaze zarucit, ze pokud se na pocatku vybralo jine reseni, nebo nahodne v prubehu zkusili jinou obmenu, nedojde se k lepsimu vysledku.
"K čemu mi bude, že 80bit FPU výpočet převedu na 32bit SSE2, tím ho urychlím 4x, když výstupní kvalita bude horší" Vzdy je treba zvazit co ma vesti cenu, zda kvalita ci cas. Prilis narocne ale extremne kvalitni kodeky se neuchyti, protoze nikdo nebude cekat 2 dny na kompresi 10 minutoveho sotu (samozrejme s vyjimkou profesionalu, tam jim to muze stat za to) Stejne je to s HW. Kdo ho pouziva sam musi zvazit cemu dava prednost. Cely svet je o kompromisech.
"VC1" pokud jsem pochopil z popisu, paralelizaci delaji rozdelenim obrazu na casti. My jsme tu navrhovali rozdeleni obrazu na sceny, treba nekolikavterinove. V dusledku rozdeleni na sceny znamena vyssi pametovou narocnost, zato mene problemu s vyhodnocovanim sceny (kazdy stream si vyhodnocuje cely obraz podle potreby) Je mnoho cest k cili a kazdy si musi vybrat tu svou. Nektara je lepsi, nektera horsi a ne vzdy je mozne je zhodnotit predem.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  01. 02. 2009 15:59  |  Linux Mozilla 1.9.0.5

1) vysledek kodovani nemusi byt binarne stejny a pri tom bude rekonstrukce identicka - lze vymyslet mnoho prikladu, ale to urcite vite. u ztratove komprese multimedii obecne existuji algoritmy s nahodnym faktorem - napr. vyuziti neuronovych siti, tezko budete mit binarne identicke vysledky, presto budou kvalitativne ekvivalentni. vyuziva se psychovizualnich metod, tam proste neni vse 0/1, mozna byste se mohl inspirovat.
2) vsechny ty 'diskuzni prispevky' mluvi o prostorovem deleni, ne casovem (z pohledu proudu dat v case). tam je samozrejme nevyuzita podobnost s okolim znacna.

rozhodne nerikam, ze se ma vsechno paralelizovat, ale pripada mi, ze z nekolika neprilis vhodne vybranych prikladu delate obecne zavery pro celou problematiku - to vede k optimalnim vysledkum a porusujete tim integritu poznatku

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  01. 02. 2009 16:01  |  Linux Mozilla 1.9.0.5

ehm, samozrejme 'NEVEDE k optimalnim vysledkum' - oprava v posledni vete

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  01. 02. 2009 02:00  |  Linux Mozilla 1.9.0.5

1) jine binarni podoby vysledku nemusi byt vubec spatne. pochybuju, ze vsechny kodovaci algoritmy (zvlast ty ztratove) jsou deterministicke.
1a)JPEG - jak uz uvedl kolega - 8x8 bloky zcela na sobe nezavisle
1b) komprese a video
AVI video je keyframe + N rozdilovych snimku, porad dokola. rozpojoval jste nekdy avi soubor?? staci ho pretrhnout presne pred dalsim keyframem - hotovo, zadna ztrata kvality, ani narust velikosti. jedine, co je treba predem analyzovat na CELEM rozsahu je pripadny VBR, ale ten se da zase analyzovat paralelne na castech. uz me to prestava bavit, je to porad dokola - komprese = analyza (paralelizovatelna) + kodovani (paralelizovatelne). i v tom nejextremnejsim pripade, kdy by se keyframe vkladal zbytecne znova na zacatek kazdeho segmentu je narust smesny, navic podotykam, ze tohle by udelal jen hodne hloupy algoritmus.
2) co mate porad s integritou dat? nezavisly vypocet AI nerusi zadnou integritu dat, jen se projevi reakce NPC treba o 2 snimky pozdej, coz vubec nevadi, mate zachovanou kontinuitu a zpozdeni nenarusta (to si muzete ohlidat). ve hrach je zpravidla v jeden moment minimum objektu, pro ktere se pocita fyzika, v pomeru k celkovemu poctu. navic jsem popsal hrubou myslenku jak paralelizovat, i kdyby vsechno kolidovalo se vsim...
vyvojare 3d enginu prechod na vicejadra donuti nad temito vecmi premyslet a uvidite, kolik napadu se vyroji, obecne ve VR je tolik veci, co urychlovat, pripadne kam vlozit usetreny vykon.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  01. 02. 2009 12:04  |  Microsoft Windows XP IE 7.0

V hodně věcech máte pravdu a nemůžu než souhlasit. Tady se ale mýlíte. Jde o to, že těch panáků/předmětů je v každé hře víc, přičemž jejich jednotlivé části jsou tvořeny určitýmy obalovými tělesy pro hrubou detekci kolize a nakonec jednotlyvými body.
Už jen kolize obalových těles, kterých jsou ve hře minimálně stovky, je pro každý frame velmi dobře paralelizovatelná. Zrovna tak geonetrické transformace jednotlivých bodů panáka při pohybu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ustijuf  |  31. 01. 2009 00:04  |  Microsoft Windows XP Chrome 1.0.154.43

:o)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Bol by ste neskutočne prekvapený, čomu všetkému rozumiem ... (to hovorí len zdravé sebavedomie)
Naozaj skutočne podarené túto hlášku si dám zarámovať "Je videt ze technologii procesoru nerozumite." V0cas

Souhlasím  |  Nesouhlasím  |  Odpovědět
V0cas  |  31. 01. 2009 17:10  |  Microsoft Windows Vista Firefox 3.0.5

tak schvane mi napiste jak byste si dal predstavoval zrychlovani jednoho jadra aniz byste zvedl jeho spotrebu
zajimalo by me kolik by zralo takove Conroe-L na frekvenci 4 GHz, 150W? Intel by musel vyrazne zvednout napeti aby zajistil stabilitu...
Ja radsi dve jadra na 2,5GHz pri spotrebe 60W Vykon v aplikacich psanych pro vice jader budu mit vykon podobny a v tech ostatnich nebude zasadni rozdil...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  30. 01. 2009 23:31  |  Microsoft Windows Server 2003 IE 7.0

Pentium 4 nebylo pomalé kvůli dlouhé pipeline. To je všeobecně známá interpretace, nicméně chybná interpretace. Delší pipeline sama o sobě neznamená ztrátu výkonu, pouze může omezovat využití jednotek v důsledku "bublin" ve schedulingu., To nastává u kódu, který není instrukčně dostatečně nezávislý. Dlouhá pipeline tedy vyžaduje velké instrukční okno a i nějakou tu optimalizaci kompilátorem. Pentium 4 bylo pomalé z toho důvodu, že experiment s trace cache nevyšel - procesor se kvůli nedotaženému dekódování ve většině případů choval jako skalární CPU a nikoli jako superskalár. A s IPC a lá 486ka toho opravdu moc předvést nedokážete.
A k tomu CPI - to platí pouze obecně a v průměru, ale v praxi dobře optimalizovaný software dosáhne IPC kolem 1.5 až 2, výjimečně dobře optimalizovaný software hodnoty až 3. Ale jde samozřejmě o náklady - software by měl být především spolehlivý, modulární, snadno modifikovatelný, odladěný. Optimalizace na hardware je věc, která tyto zásady porušuje, a proto by se o ní měl starat kompilátor. A to je s multithreadingem neslučitelné a s instrukčním paralelismem slučitelné jen částečně. Proto odpověď na požadavky software spočívá ve zvyšování frekvence. Ať se to výrobcům líbí nebo ne.
BTW, procesor jako Core 2 Duo netrpí stejný teplotními problémy jako Pentium 4 jen proto, že má úsporné mechanismy odpojování nevyužívaných částí. Takové mechanismy Pentium 4 nemělo. Kdyby je neměl ani Core 2, tak bude mít obrovskou spotřebu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 16:14  |  Linux Mozilla 1.9.0.5

'Neschopní jsou ti, kdo si myslí, co všechno nejde paralelizovat' - zajimava teze
mozna byste se divil, co vsechno lze paralelizovat, na druhou stranu mate pravdu, ze na desktopu je samozrejme situace trosku jina. ale opet, bavime se o aplikacich narocnych na cpu!!!
- prace s videem, zvukem, prehravani, enkodovani - pro paralel jako delany
- komprese, dekomprese, enkrypce, dekrypce - vsechny metody mozna nelze paralelizovat, ale rozhodne nektere ano a ty budou v budoucnu prevladat
- hry - pokud trochu sledujete herni prumysl, nenapsal byste tu vetu nize o konzolach, pc je stale jasnym vedoucim a hry jsou taky prukopniky paralelizace na desktopu, jak tomu byva ostatne u vsech novych metod a pristupu
- 3d grafika - rendering, cad, atd. atd. jednoznacna vyhoda paralelizace
- 2d grafika - narocnejsi operace, filtry atd - to same
cele bych to otocil, nenapada me aplikace narocna na cpu, ktera by netezila z paralelizace.
no a ten multitasking je prece taky vyhoda vice jader, kdyz neschopny OS a program zahlti cele jadro, dalsi muzou normalne pracovat. dokonce i ten web browsing - tusim chrome ma taby ve vlastnich vlaknech, pad jednoho neshodi cely browser - dalsi nespornou vyhodou paralelizace je bezpecnost.
abych to shrnul na Vami vyjmenovane ukony - cteni mailu, psani ve wordu nepotrebujeme nejen paralelizaci, ale ani vykonne cpu, o techto ukonech se zde vubec nebavime.

Souhlasím  |  Nesouhlasím  |  Odpovědět
m.b.  |  29. 01. 2009 16:52  |  Microsoft Windows XP Firefox 3.1

Jen oprava: chrome vytvari pro kazdy tab vlastni proces, nikoliv jen vlakno. A stejne tak to dela i IE8.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  29. 01. 2009 22:08  |  Microsoft Windows Server 2003 IE 7.0

S tím bohužel nemůžu souhlasit. Právě že komprese (ať už audio, video nebo binárních dat) sestává z algoritmů, které pro maximální kompresi pracují s podobností dat vzhledem k předchozím datům - u videa klíčové snímky, u datových souborů binární řetězce. Čím účinnější tyto algoritmy jsou, tím obtížněji jsou paralelizovatelné, neboť tím více se odkazují na dřívější data. Pokud se u nich má paralelizace nasadit, pak to vede ke ztrátě integrity dat. To je případ MPEG 4 AVC (H.264), MPEG Audio Layer 3 (MP3), ale i třeba WinRARu. Schválně si to zkuste, uvidíte, že soubory nebudou stejné.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  29. 01. 2009 23:19  |  Microsoft Windows XP Opera 9.61

U videa se klicove snimky vkladaji radove po vterinach casto se pro urceni klicoveho snimku dela nejdriv analyza videa a klicovy snimek se vklada na zacatek sceny. Neni az takovy problem v jednom vlakne udelat analyzu a na jejim zaklade pak rozdelit video na useky, ktere se zpracuji paralelne. S mp3 je to mozne udelat podobne, tam ani neni zavislost ostatnich snimku na klicovem, pokud vim. Dalsi vlakno se pak muze postarat o sestaveni jednotlivych casti do jednoho souboru.
U raru nevim, zakladem je komprese dalsich dat s pouzitim predchozich pravdepodobne pokud by byl zajem o MT i v teto oblasti musel by se vyvinout jiny algoritmus, nebo novy format, ktery by dovolil ulohu rozdelit. Ale ani tady neni nemozne reseni vymyslet (Ale myslim, ze tady je to zatim min potrebne nez treba u toho videa)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  30. 01. 2009 23:41  |  Microsoft Windows Server 2003 IE 7.0

Teorie sice pěkná, ale v praxi použití multithreadingu vede u kompresního formátu H.264 (MPEG 4 AVC) ke ztrátě kvality. Formát MP3 také neumožňuje paralelizaci bez ztráty kvality.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  31. 01. 2009 00:46  |  Microsoft Windows XP Opera 9.61

To uz neni principialni zalezitost, ale problem dane implementace. Neznam podrobnosti formatu, tak mohu jen rict, ze neverim, ze je nemozne kodovani videa paralelizovat.
Data v mp3 jsou pokud vim ostre rozdelena na samostatne casove bloky. Nevidim duvod proc by se nemeli zpracovavat samostatne. Ev. s ohledem na pouzivani ruznych filtru vidim moznost rozdelit soubor na davky, kazdou radove na nekolik desitek bloku s tim, ze se pouzije i potrebne mnozstvi bloku predchazejicich a nasledujicich. (Domnivam se, ze tento princip by mel byt pouzitelny i u MPEG 4)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  31. 01. 2009 12:06  |  Microsoft Windows Server 2003 IE 7.0

Diskuze k tématu paralelizace LAME proběhla už před pár lety na domácím fóru LAME - HydrogenAudio. Programátoři LAME tam tvrdí, že paralelizace je možná jen v případě, kdy se degraduje výstupní kvalita.
A co se videa týče, na netu lze nalézt povídání, že paralelizace MPEG 4 AVC vede ke ztrátě kvality, resp. ke snížení kompresního poměru při zachování kvality.

Souhlasím  |  Nesouhlasím  |  Odpovědět
jehoVista  |  29. 01. 2009 00:47  |  Linux Mozilla 1.9.0.3

Z cisel 1,2 a 4 prolozit krivku do 80ti a rict, ze to je budouci vyvoj! Tomu rikam odvaha.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vaseo  |  29. 01. 2009 01:13  |  Linux Mozilla 1.9.0.5

intel ma prototyp 80core uz dnes

Souhlasím  |  Nesouhlasím  |  Odpovědět
vlastagf  |  29. 01. 2009 01:20  |  Microsoft Windows XP Firefox 3.0.5

ale uprimne, obcas mam pocit, ze analytika v Gartner by mohl delat kde kdo...

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
29. 01. 2009 07:29 | Microsoft Windows XP Firefox 3.0.3

+1

Souhlasím  |  Nesouhlasím  |  Odpovědět
hurvajs77  |  29. 01. 2009 09:11  |  Linux Firefox 3.0.3

Tak to se mi zda take, hlavne Gartner zije v jinem svete. Nicmene, neco na tom pravdy bude. Podobne je to s 64bit architekturou.

Souhlasím  |  Nesouhlasím  |  Odpovědět
touchwood  |  29. 01. 2009 09:27  |  Microsoft Windows XP Firefox 3.0.5

ano, není problém seskládat na pivní tácek 80 broučků Slunéček sedmitečných (s nulovým IQ), zkus ale na stejný tácek (dobře, vyjdu ti vstříc - ber ten ALU tác co nosí pinglové) poskládat 80 štamgastů (s IQ lehce inteligentního houpacího koně)

Souhlasím  |  Nesouhlasím  |  Odpovědět
hnusak  |  29. 01. 2009 10:24  |  Microsoft Windows XP Firefox 3.0.5

Gartner je nejvetsi komik v oboru.

Souhlasím  |  Nesouhlasím  |  Odpovědět
29. 01. 2009 08:34 | Linux Mozilla 1.9.0.5

Gartner objavil Ameriku - intal a AMD o tom rozpravuju viac ako rok

Parallel programmers not prepared for the glorious revolution
Tuesday, 27 November 2007, 12:28
INTEL ZISTIL, ze ani nie 1 percento programatorov nie je pripraveneych celit vyzved paraleneho programovania,, ktore je z HW pohladu buducnostou (readktora to neprekvapuje)
http://www.theinquirer.net/inquirer/news/585/1026585... ...
Multicore puts screws to parallel-programming models
02/15/2008
Intel Corp. a Microsoft Corp. dali 10 milionov USD, na 5 rocnu prevadzku new Parallel Computing Lab at the University of California at Berkeley, pre 14 studentov!!!!!!!!
"Priemysel je trochu v stave paniky ohladom problemu ako programovat multicore processory, specialne tie heterogenne, (GPU+CPU)" povedal Chuck Moore, a strsi odborny poradca u AMD, ktory mimo ine ma aj poziciu chief architect of the company's so-called accelerated computing initiative (t.j napr. GPU akjo koproc esor). "Aby stevytvorili, program, ktory dokaze efektivne vyuzit multicore hardver uz dne , potrebujete mat tituk PhD z informatiky. To sa musi zmenit ak chceme uviest na trh heterogenne CPUs. (AMD Fusion Intel Larabee...)"
http://www.eetimes.com/showArticle.jhtml...

Souhlasím  |  Nesouhlasím  |  Odpovědět
29. 01. 2009 09:05 | Linux Mozilla 1.9.0.5

spotreba CPU je dana vzorcom
P = n * C *U^2 *f
kde
P je spotreba
n je pocet tranzistorov
C je parazitna kapacita dna vyrobneou technologiou a jej zvladnutim
U je napjacie naptqie
f je pracovna frekvencia
^2 znamena druhu mocninu
* je nasobenie
http://en.wikipedia.org/wiki/CMOS...
navyse ak chcem aby CPU pracovalo stavbilne
Us = k *f
kde k je konstanta
a Us je napatie pri ktorom je chip pracuje stabilne na danej frekvencii
cize suma sumarum
P=n* C*k^2*f^3
zvysenim poctu jadier zvysim n ale zvysenim frekvencie zvysim f
a teda zvysenie frekvencie na dvojnasobok zvysi spotrebu 8x!!! dve jadra ju vsak zvysia len 2x

doteraz to riesil novou technologiou ale

Problémem moderních procesorů je velmi tenká vrstva dielektrika, ta má u 65nm procesorů tloušťku pouze 1,2nm, což odpovídá pěti vrstvám molekul SiO2! Pokud si vzpomenete, 90nm procesory Prescott měly s tímto velké problémy, úniky proudu (current leakage) zde byly dosti vysoké. Výsledkem je vyšší spotřeba i zahřívání procesoru.
http://www.svethardware.cz/art_doc-652667672B522A04C... ...
Podarilo sa vyriešiť aj problémy s únikmi prúdu, tzv. leakage current. Problém spôsobuje veľmi tenká vrstva dielektrika, pri dnešných 65 nm procesoroch je to len 1,2 nm, to znamená 5 molekúl SiO2. Pri 45 nm procesoroch je báza procesora vyrobená z kovu a dielektrikum je high-k materiál založený na hafniu.
http://www.pcrevue.sk/buxus_dev/generate_page.php...


Souhlasím  |  Nesouhlasím  |  Odpovědět
snake  |  29. 01. 2009 14:35  |  Microsoft Windows XP IE 6.0

Ech, asi mi to nějak nemyslí, a nebo je to plné chyb. Tak za prvé, ten leakage current, pokud vím, je nezávislý na frekvenci, a právě proto je to leakage. Je to prostě ta složka spotřeby CPU, která se dá velmi těžko uspořit, protože utíká, ať jede CPU pomalu či rychle. Vyhnout se jí dá jen vypnutím dané části CPU, případně snížením napětí a tedy i proudu (čili spotřeba jde dolů kvadraticky s napětím). Ta neleakage část spotřeby ale skutečně na frekvenci závisí (v podstatě jde o spotřebu vynucenou přepnutím tranzistoru z jednoho stavu do druhého, pokud se tranzistor v daném taktu nepřepne, nic se nespotřebuje, ale zjednodušeně lze říci, že každá instrukce si vynutí v průměru tolik a tolik přepnutí, a tudíž i takovou a takovou spotřebu).
No a kde se vzal ten kubický člen ve vzorci pro multijádro, to jsem opravdu nepochopil!? Nahoře je vzorec, který až na tu potíž s leakage current beru, ale to multijádro?!

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  29. 01. 2009 14:48  |  Microsoft Windows XP Opera 9.61

kubicky clen: kolega tam shrnul nekolik zavislost:
1) prikon pri konstantnim napeti a proudu roste s frekvenci linearne takze je ve vzorci prvni "f"
2) pro zvednuti frekvence bez technologickeho pokroku je nutne zvysit napeti,cimz se zvisi i proud, pak je mozne nahradit napeti k1*f a proud jako funkce napeti pak k2*f
tim vypadne napeti a proud a zustane tam f^3 s nejakyma konstantama
vysledek je, ze spotreba pri zvysovani frekvence roste kubicky zatimco pri zvysovani poctu jader pouze linearne s vykonem.
Nakolik je to presne je otazka, ale smysl to dava

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
29. 01. 2009 08:49 | Microsoft Windows Vista IE 8.0

Doufejme, že se to zlepší s příchodem .NET Framework 4.0, který zjednodušuje paralení zpracování dat. Zjednodušeně řečeno, místo cyklu for a foreach, můžu použít "pralelní" verzi:
for (int i = 2; i
{
...
});
Něco podobného existuje i pro LINQ. Programátor si ale musí pořád hlídat přístup k proměným sám, aby se o ně vlákna neprala.

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
29. 01. 2009 08:53 | Microsoft Windows Vista IE 8.0

Tak ukázky kódu to nějak nepobralo. Najdete je na http://cid-b72202f1e9313557.skydrive.live.com/self.aspx/Public/Program.cs...

Souhlasím  |  Nesouhlasím  |  Odpovědět
29. 01. 2009 09:45 | Microsoft Windows Vista Chrome 1.0.154.43

Umm, dokazu fci isPrime urychlit tak, ze ten testovaci cyklus bude na jednojadru rychlejsi nez tvoje na stojadru

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
29. 01. 2009 12:06 | Microsoft Windows Vista IE 8.0

O tom nepochybuji, je použit velmi primitivní způsob, aby byl rozdíl v čase ve zpracování paralelním a neparalelním co nejvíce vidět.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  29. 01. 2009 13:24  |  Microsoft Windows XP IE 7.0

Čili pokud to shrnu, vidíte na vašem příkladě velmi názorně, jak je efekitvní paralelizace obtížná a jak je na desktopu k ničemu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
steelspace  |  29. 01. 2009 14:06  |  Microsoft Windows Vista Firefox 3.1

Tak špatně bych to neviděl. Konkrétní použití přímo v UI vidím např. při vytváření různých efektů, animací, filtrování seznamů, řazení apod. To vše lze velmi dobře zpracovávat paralelně, neboť se jedná o relativně krátkodobé oprace na sadou mnoha prvků.

Souhlasím  |  Nesouhlasím  |  Odpovědět
steelspace  |  29. 01. 2009 14:08  |  Microsoft Windows Vista Firefox 3.1

Ještě doplním, že nejpoužívanější desktopová aplikace dneška - webový prohlížeč - si o paralelní zpracování přímo říká. Máme mnoho objektů, jako obrázky, písma atd, které lze předzpracovat paralelně a pak zobrazit do stránky.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  29. 01. 2009 14:36  |  Microsoft Windows XP IE 7.0

Pomalé vykreslování GUI určitě není taková katastrofa, jak líčíte. Pokud je přesto odezva GUI delší, než na co byl člověk dříve zvyklý, tak je to problém přeobjektovaných frameworků, které v současné době prostě nedokážou pracovat efektivně. Tady by spíš pomohlo zoptimalizovat kód a ne přidávat další jádra.
U prohlížeče je vaše námitka ale naprosto absurdní. Pokud něco brzdí zobrazení stránek, tak je to konektivita a ne rychlost CPU.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Olda_rab  |  29. 01. 2009 17:43  |  Microsoft Windows Vista Opera 9.63

v pripade ze kazdy tab nebo kazde okno bezi jako samostatne vlakno to smysl ma, a patrne to bude pouze pokud bude videt nekolik stranek najednou, a jeste jen kdyz tam pobezi nejaka animace, gif, flash a podobne, jinak mi prijde zbytecne aby na pozadi pokud se neocekava nejaka reakce ci data od servru neco bezelo a vlakno muze byt klidne pozastaveno.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  30. 01. 2009 09:24  |  Microsoft Windows XP IE 7.0

Samozřejmě že nemá, protože ty procesy v ostatních tabech budou pozastaveny. Internetové animace zvládá s přehledem i jednojádro. Při jakékoliv práci s internetem osobně nevnímám rozdíl mezi mým prastarým Athlonem XP @ 1,8 GHz z roku 2002 a moderním PC. Snad jediný rozdíl je rychlost náběhu OS.

Souhlasím  |  Nesouhlasím  |  Odpovědět
kozec  |  30. 01. 2009 09:31  |  Microsoft Windows XP IE 6.0

> Samozřejmě že nemá, protože ty procesy v ostatních tabech budou pozastaveny.
Nerealne a nevhodne. Od dokoncenia tej animacie moze celkom kludne zavysiet skript a nikto netuzi po tom, aby mu s minimalizaciou zatuhla cela webova aplikacia.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  30. 01. 2009 10:18  |  Microsoft Windows XP Opera 9.61

"v ostatních tabech budou pozastaveny."
Bohuzel ale nejsou. Typicky FLASH reklama (proto ji mam zakazanou). Kdyz jsem si otevrel nekolik tabu se zpravama, na kazdem jedna az dve flash reklamy, tak se pocitac stal nepouzitelnym.
Nekdy by bylo vhodne je pozastavit (reklamy) nekdy ne (video muzu chtit nechat "bezet na pozadi" a jen poslouchat)

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  30. 01. 2009 10:58  |  Microsoft Windows XP IE 7.0

Mám taky flash vypnutý
To, co píšete nemůžu potvrdit. Teď jsem to zkoušel a zdá, se, že pokud není flash na popředí, tak nežere nic. Otevřel jsem čtyři taby a je to v pohodě. Vytíženost konstantně max 10%. Pokud je flash reklama vidět, tak i 30%. Při minimalizaci browseru pak standardně 2%.
Dejme tomu, že se jedná o multithreading/procesing, ale ne o úlohu pro více jader.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dochy  |  30. 01. 2009 11:34  |  Microsoft Windows XP Opera 9.61

Ted se mi to taky nepodarilo nasimulovat. Ale nemam ted pristup k pocitaci na kterem jsem s tim mel problemy. Mozna uz je ted lepe optimalizovany SW.
"multithreading/procesing, ale ne o úlohu pro více jader" Nemohu souhlasit s timto tvrzenim. Pokud je neco MT ci MP pak tomu (az na male vyjimky) prave vice jader vyhovuje a vetsi pocet jader v takovem pripade znamena vyssi vypocetni vykon.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MorOn_CZ  |  30. 01. 2009 11:39  |  Microsoft Windows Vista Firefox 3.0.4

Zkušte youtube, to hraje pořád

Souhlasím  |  Nesouhlasím  |  Odpovědět
bafman  |  29. 01. 2009 09:08  |  Linux Mozilla 1.9.0.4

to je sice nadherne, ale neresi to konzistenci dat. To je vzdy v rukou programatora. Multithreading je obecne nedeterministicky. Nejenom u LINQ-u
PS: ani synchronizovane promenne jak ukazuje ukazka nize nejsou vselek proti moznym deadlockum, takze si to hlidat musis stejne sam. Jak psat bezpecny kod existuji patterny, ktere frameworky nejsou schopny pokryt

Souhlasím  |  Nesouhlasím  |  Odpovědět
29. 01. 2009 09:18 | Linux Mozilla 1.9.0.5

presne .NET nic neriesi

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
29. 01. 2009 11:36 | Microsoft Windows Vista Opera 9.60

Konzistenci dat se pak musí řešit na úrovni databáze transakčním zpracováním, trigery, referenční integritou apd.

Souhlasím  |  Nesouhlasím  |  Odpovědět
steelspace  |  29. 01. 2009 13:58  |  Microsoft Windows Vista Firefox 3.1

To není pravda. Pro tyto jednoduché příklady, jako smyčka "for" to funguje velmi dobře.
Navíc většina dnešních velkých aplikací jsou webové nebo jiné bezestavové typu "request-response" a tam je paralelní zpracování na úrovni dotazů jednotlivých klientů přímo zakomponováno v hostu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bafman  |  29. 01. 2009 23:52  |  Linux Mozilla 1.9.0.5

smarja jeste jednou si to prectete. Nejde o smycku for )

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
29. 01. 2009 14:24 | Microsoft Windows Vista Opera 9.60

Konzistenci dat se pak musí řešit na úrovni databáze transakčním zpracováním, trigery, referenční integritou apd.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bafman  |  29. 01. 2009 23:53  |  Linux Mozilla 1.9.0.5

ale ja nemluvim o databazi. Mluvim o datech daneho kodu. Jedna se o pristup k atributum objektu, zavisloti a deteminicnosti. Proste kdyz se vice threadu bije o jeden zdroj.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Olda_rab  |  29. 01. 2009 17:32  |  Microsoft Windows Vista Opera 9.63

paralelismus na urovni beznych a zejmena kancelarskych programu je prakticky nevyuzitelny, vetsina operaci probiha linearne, jedna operace musi pockat na vysledek predchozi operace a podobne. Paralelismus na urovni systemu uz je diky operacnim systemum celkem dobre vyuzivan a u beznych a akancelarskych systemu ma smysl prave tam. Vyuzit na urovni aplikaci se da prevazne u konverzi video/audo, cad, cam, fem a u her a zde se uz take zacina prosazovat, na servrovych aplikacich uz se vyuziva davno. Takze z meho pohledu je vse v poradku a clanek je jen placnutim do vody.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MorOn_CZ  |  30. 01. 2009 11:13  |  Microsoft Windows Vista Firefox 3.0.4

"paralelismus na urovni beznych a zejmena kancelarskych programu je prakticky nevyuzitelny, vetsina operaci probiha linearne, .."
A tohle je právě nesmysl.
Vemte si běžný kancelářský program, např. Excel - tabulka plná výpočtů.
Řkněme, že vzorce budou tak složité a bude jich tolik, že výpočet bude trvat 1 vteřinu.
A teď jednovláknový program:
Změníte jednu buňku, program se na vteřinu zasekne, přepočítá výsledky a pak se překreslí.
-> Změníte 20 buněk, celkem !20! vteřin budete koukat na zaseklej program.
2. Příklad Word:
Otevřete dokument.
Otevírání trvá obvykle hodně dlouho (všichni víme) a s jendovláknovým programem budete koukat na šedou obrazovku. Většina lidí si vezme jiné okno a zkusí mezitím Word celý "vygumovat" - protože procesor se nedostane k tomu oby Word překreslil.
Zkuste si pustit správce procesů->Zobrazti->Vybrat sloupce->Podprocesy (takhle je to ve Vistách)
Z mých spuštěných 81 propgramů jsou pouze 3 jednovláknové

Souhlasím  |  Nesouhlasím  |  Odpovědět
Eagle  |  30. 01. 2009 23:46  |  Microsoft Windows Server 2003 IE 7.0

S tím Excelem se dá souhlasit, verze 2007 přepočítává listy obecně mnohem rychleji než verze 2003 (navíc má také GUI ve vlastním threadu, takže se nezasekává). Nicméně je třeba si uvědomit jednu věc - paralelní přepočítávání je možné jen u buněk, které jsou nezávislé. A to často nemusí být. A samotné stanovení závislostí buněk je čistě sekvenční operace, kde žádné zrychlení být nemůže.
Multicore také v Excelu nezrychlí často velice náročná makra ve VBA, protože ta jednak multithreading vůbec nepodporují, druhak lidé, kteří je píší, by ho ani nezvládli udělat.
ad Správce úloh - To nic nedokazuje, samotná vlákna neznamenají nutně, že jsou zátěžová. Může se jednat o vlákna, která čekají na vstup uživatele a nespotřebovávají žádný strojový čas. Takových vláken zvládne i jednojádro tisíce bez zaváhání a ani to nepoznáte.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Speciál o přechodu na DVB-T2

Velký test herních myší

Super fotky i z levného mobilu

Jak snadno upravit PDF