Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Jen 48 jader? Za deset let se plánuje 16k jader s 1 MB paměti na jádro :D
Ale vážně, tenhle projekt je docela zajímavý, před 4 dny splnil svůj cíl na Kickstarteru a dostal skoro $900k: http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-...
Tu multijádrovou jednotku nazývají akcelerátor, pro běžné apliakce tam jsou 2 klasická ARM jádra, já bych to bral jako kříženec CPU a GPGPU. Mezi těmi příklady použití se najde i dost reálně využitelných. Samozřejmě to bude záležet na programátorech, přece jen člověk je stále víc limitujícím faktorem při rozvoji výpočetních technologíí, zvlášť když jde o vícevláknové/víceprocesorové aplikace. Aby udržel krok, tak potřebuje stále nové vrstvy abstrakce, které opět zpomalují, takže nakonec jsme skoro tam kde jsme byli před x lety, akorát všechno vypadá líp a taky žere víc paměti.
Stejně jako CAD už bude nezbytné nějaké pokročilejší CAP (computer aided programming). Přece jen bušení písmenek do editoru už nějakou dobu není efektivní (i z hlediska chybovosti) způsob programování.
Ještě jsem našel pěkné zamyšlení od pana Dijkstry: http://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD237.html
To povídání je pěkné, ale na "computer aided programming" si ještě počkáme nějaký ten pátek. Líbí se mi jak píše, že naprogramovat a pak debugovat je samo osobě fail :), ale Dijkstra byl boss a nám normálním lidem nezbývá než debugovat :(
Pokud je bušení písmenek do editoru nefektivní, určitě máš k takovému výroku programovací proces, který by ve srovnání "efektivity" vyšel lépe?
... a ty ho ještě nemáš? ... stačí skládat jednotlivé "funkční bloky" netodou ctrl+c, ctrl+v :-) JOKE
Tak CASE systemy su tu uz davno a mnohe vedia napriklad z UML definicie rovno vygenerovat db model, zdrojove kody v roznych programovacich jazykoch ( vecsinou objekty,interfejsy, nejake to orm a pod.). Problem vecsinou nastava v momente ked sa zacnu pridavat featury do sw a doladovat "drobnosti". Vecsina klientov ma totiz stale predstavu ze SW, uz podla nazvu, je nieco co sa lahko meni a kedze najprv sme sy odsuhlasili auto so 4 kolesami tak predsa nemoze byt problem v polke vyvoju tam pridat piate ehm. Ved viac pruzkov viac adiddas nie? A potom to aj tak vecsinou dopadne.
Tak pokusy odstranit bušení písmenek do editoru tu už byly před 15 lety, ale ono se to nějak moc neujalo (pominu-li specifickou možnost rozházet si po obrazovce ui elementy) a víš proč? No protože to bušení písmenek do editoru je a ještě dlouho bude nejefektivnější.
hmm takže z toho nakonec vznikne "něco jako celeron" - a hlavní idea procesoru s minimální spotřebou je ta tam...
a zase to bude žrát... a na baterky to prd vydrží... tomu říkám výhra...
na frázi „ne však s dvoujádrovým procesorem“ nemuseli moc lákat - stačila zkušenost s havarovaným procesem, který sežral prakticky vešekerý výkon CPU pro sebe a byl problém urvat trochu výkonu pro systém a sestřelit kousnutý program - to už byl pokrok v mezích zákona i virtuální dvoujádro v podobě HT u P4
Jenže to se ti může stát i dneska - když je aplikace dobře odladěná na využití více jader, ale obsahuje jiné bugy, může stejným způsobem jako popisuješ sežrat výkon všech jader a jsme tam, kde jsme byli.
Cestou ven je jedině prioritizace systémových procesů nad uživatelskými a pak nedojde k podobné situaci ani v jednom z případů - dokud podobná chyba nenastane v systémovém procesu, pochopitelně ;)
ano teoreticky se to může stát i dnes, ale prakticky se mi už dlouho nestalo, abych se dostal do situace jako v dobách w98 na jednojádru. jednak od wNT a w2k mají procesy přiřazenou prioritu a do P4 s HT jsem na jednojádru neprovozoval nic kritického, druhak jsem ještě nepotkal aplikaci, která by se kousla na všech dostupných jádrech
Já bych tak neprožíval, že na to nejsou aplikace. Pět let je v IT hrozně dlouhá doba... Úsporné to bude, při malé vytíženosti bude většina jader vypnutá.
Nemyslim si, ze se za pet let zmeni zatim platnej fakt, ze programovat pro vic vlakem a navic efektivne je proste narocna prace, ktera vyzaduje vyrazne vyssi znalosti nez bezny jednovlaknovy programovani.
To by znamenalo, že by se každý blb, který umí základy HTML, přestal nazývat programátorem :-)
Možná se na to dívám z trochu jiného pohledu. Pokud půjde o jádra řekněme výkonem blízká Atomu, pak v případě jedné náročné aplikace, která nebude schopná efektivně využít řadu jader, bude výkon stejný, jako kdyby byl použitý 2-4jádrový Atom. Výkonnostní přínos se projeví teprve v okamžiku, kdy by na tom mělo běžet zároveň 10+ náročnějších aplikací, což zrovna není případ mobilních zařízení. V současné době se na mobilních zařízeních nenajde vytížení ani pro čtyři jádra, což je mimo jiné důvod, proč se řada dvoujader jeví jako rychlejší než čtyřjádrová Tegra 3.
Pět let zase tak dlouhá doba není, když si uvědomíme, že například první Tegra přišla už před čtyřmi lety, nebo naopak v desktopu ani pět let nestačilo k tomu, aby většina aplikací dokázala efektivně profitovat ze čtyřjader.
Presne tak, na skole jsme se ucili teorii "systemu hromadne obsluhy", ktera na toto presne pasuje, ale i na dalsi zarizeni, obory atd...
Globalni zaver je, ze pocetne svazky(jadra,fronty,apod) jsou NEVYHODNE.
Zde oficialni info ve forme slide prednasky: www.uai.fme.vutbr.cz/~jdvorak/vyuka/tsoa/PredO11.ppt
PS: stejne jako je nevyhodny velky vyber poctu jidel v restauraci pro jeji provoz, i to ta teorie pokryva :-)) viz. Mr.Pohlreich :-))
Nemyslim si ze to nutne musi dopadnut tak ako pisete.Dost zalezi pd celkovej architektury celej platformy. Napriklad pri 48 jadrach nieje problem vyclenit par jadier na pevno pre os, dlasie sa mozu starat cisto o hw zalezitosti - kamera, gsm modul, spracovanie roznych senzorov.Otazne je aky to bude mat prinos po hw a cenovej stranke (spracovanie obrazovych dat sa presunie povedzme z cipu v kamerovom module do cpu), ale minimalne to umozni flexibilnejsie programovanie a pridavanie novych funkcii kedze to nebudu specializovane dsp a ine cipy. Nevyhoda je ze takato platforma a jej stabilita bude extremne zavysla od kvality sw, resp firmwaru a ovladacov.
S tou dlouhou dobou bych nesouhlasil. Stačí se podívat, jak dlouho máme 64bitové procesory (případně operační systémy)...
.. no dokazal bych si i predstavit ze Intel vymysli nejaky hw mustek- rozhrani mezi jadry a zbytkem pc - v samotnem cpu, kde by i jednolaknova aplikace jela na vice vlaknech diky tomu rozhrani ktere by prerozdelovalo praci bez ohledu na OS a aplikaci jako takovou .... coz by bylo super
Něco jako hardwarový paralelizátor LOL
To zavání metodou použítí více matek na zrácení doby těhotenství :-)
výstižný příklad :-)
Nemyslis, ze kdyby to bylo tak jednoduche, tak by se to delalo? Problem je v tom, ze 70% prikazu nelze pararelizovat a to co jde, tak to udela programator a ten tvuj mustek by tomu nepomohl, nebot by stejne nevedel co pararelizovat.
Stejne jak tady nekdo napsal vetu "pouzit vic matek pro zkraceni doby tehotenstvi"-to je naprosto stejny jak to co jsi napsal, naprosta hnupovina ;)
tou hnupovinou jsem nechtel urazit autora, chapu ironii.
tou hnupovinou jsem nechtel urazit autora, chapu ironii.
tou hnupovinou jsem nechtel urazit autora, chapu ironii.
.... pred lety by taky nekdo rekl, ze to a to nejde a dnes; jsou disky co maji treba 3TB ci GDDR5 pameti na 4 GHz atd. ... a rekl bych ze pred par lety by pro vetsinu lidi bylo mnohem vice veci bizardnich ci jeste vice divnejsich (nez co jsem psal) , a dnes se nad tim nikdo nepozastavi ...... a zrovna u Intelu si nemyslim, ze slovo NEJDE nepouzivaji tak casto
No jo, ale tohle je problém snílků s nulovými znalostmi. Od toho se pak odvíjejí jejich nadšené a naprosto defektní představy. No offence!
no to se jeste uvidi kdo bude bize k pravde :-) :-q .. jestli zapšklej frikulin nebo snilek No offence! :-))
To o cem mluvite jsou v podstate kvantitativni zmeny ktere narazi leda na fyzikalni limity. Na urovni instrukci dela zrovna intel paralelni zpracovani uz od dob pentii, tedy nejakych 20 let.
Co se tyce zpracovani aplikace ve vice vlaknech, nejsem si jist co tim presne myslite a mam pocit, ze to nevite ani vy. Zde je problem uz v tom, jak jsou programy napsany - vetsina programatoru uvazuje proceduralne a tak pise sw - nejdriv udelam tohle, pak tamto a tohle muzu rozdelit na vic vlaken a tamto ne... Aby tato uvaha probehla v CPU, musel by se analyzovat kod a tok dat, vedlejsi efekty atd., coz skoro narazi na samotne moznosti porozumeni problemu tak jak to delame my mozkem. Pokud vim, tak na to neni ani sw, natoz aby to nekdo dratoval do hw.
A pokud uz to nekdo udela tak zjisti, ze ten prinos je minimalni, protoze vetsina kodu stejne ceka na zpracovani predchozich kroku. A kdyz uz nekdo udela CPU, ktere bude schopno ten kod a tok dat prehazet aby to slo, tak radim zdrhat hodne daleko, protoze behem nekolika malo hodin zacnou z automobilek vyjizdet roboti, kteri nas eliminuji protoze pro ne budem zbytecni :-) .
Dalsi cesta je treba pres funkcionalni programovani (a kod bez vedlejsich efektu), ale takto vznika radove mene programu a interpretry to pak muzou dost dobre rozvlaknovat samy - uz to tak je v podstate napsane. Zde by se CPU udelat mohlo, ale kvuli malemu rozsireni se to nejspis nevyplati/nema to takovy efekt.
> paralelizacia nema nic spolocne s tym...
Ma v tom smyslu o jakem mluvil predrecnik - slo by automaticky pustit cast programu v samostatnem vlakne pokud interpret dokaze (pripadne programator napovi), ze ta cast nema zadne vedlejsi efekty a zavisi ciste na svych vstupech a ty jsou konstantni. To u funkcionalnich jazyku lze docela snadno a je zvykem tak psat. U beznych proceduralnich to jde hur az vubec (a neni zvykem tak psat :-) ).
Cili teoreticky muze takovy FP program bezet ve vice vlaknech aniz by si o to programator rekl. Akorat nevim jestli to nejaky interpret dela.
To ze kazdy sdileny prostredek je pak bottleneck je jasny.
Tak hlavně ta paralelizace se v CPU již dnes děje, pokud to některé instrukce umožňují tak je procesor zpracovává paralelně. Paralelizace na vyšší úrovni tedy v řádech alespoň stovek až tisíců instrukcí, tak aby se vyplatilo je rozkládat na více jader je IMHO v dohledné době skutečně nemožná a především by se o ní měl postarat kompilátor (pokud je vůbec možná) a nikoliv procesor.
Pro nejaky webovy nebo DB server s vykonnym diskovym polem, proc ne. Hodne jader (vlaken), prumerny vykon a nizka spotreba. Neco jako ARMy.
Ale nasazeni do mobilnich zarizeni mi jaksi (zatim) nedava zadny smysl.
Programovat vicevlaknove aplikace jako takove neni zase tak slozite, spis je problem vymyslet, jak pozadovanou cinnost logicky paralelizovat. Casto to moc nejde nebo to ani fakticky nelze.
Pokud se nenajde zpusob, jak toto resit automaticky at na strane SW nebo/a HW, pak se soucasny stav nebude moc lisit od toho budouciho.
Az bude vymyslena automaticka paralelizace programu, budou se pocitace uz programovat sami. S vyjimkou nekolika specialnich pripadu to totiz vyzaduje pochopit pouzity algoritmus a nahradit ho jinym, ktery lze paralelizovat.
Celé to je důsledek současného stavu procesorové techniky, které je tak trochu u konce s dechem.
Výkon můžete zvyšovat
- počtem současně zpracovávaných bitů došli jsme k 64.
- počtem taktů potřebných na zpracování jedné instrukce, pokud opominu různé pseoudo finty je konečná zkracování jedné instrukce na jeden takt
- zvyšováním frekvece, Intel nákladem miliard dolarů v praxy ukázal, že jednotky GHz jsou reálně konečná a žádné desitky GHz se konat nebudou
Jediné co zbylo je sekat jádra vedle sebe, technologii již dovolí nacpat jich vedle sebe desítku , brzy desítky, ale jaksi pro ně není práce protože práci nedokážeme rozdělit a včil jsme v řiti :-)
64bit procesory byly uvedeny hlavně proto, že umožňují adresovat více paměti, nijak to nesouvisí s počtěm současně zpracovávaných bitů. Dnešní CPU vykonávají instrukce paralelně, mohou zpracovat i několik instrukcí za 1 takt (IPC>1). Vektorová jednotka AVX pracuje najednou s 256ti bity a bude se do budoucna dále rozšiřovat.
A ještě si nastudujte jaké novinky přinese nová architektura Haswell - díky nim se vyrazně zjednodušší programování pro více jader a také se zmenší režie komunikace mezi vlákny.
Procesory se prohlasili za 64bitove, protoze ADRESOVE registry byli natazeny na 64bitu. Float point registry byli 80bitove davno pred tim a MMX prineslo i 64bitove integer registry kdyz zacali byt zapotrebi. Dneska jsou i 256bitove integer registry, ale procesor je porad 64bitovy.
Vzhledem k tomu, ze u vetsiny sw nejsou vyrazne rozdily ve vykonu mezi 32 a 64bit bych rekl, ze to zpracovani nadvakrat se vetsinou ztrati v ostatnim kodu - skoky a pristupy do pameti maji mnohem horsi dopad.
Hlavni figl bude v tom, ze vsechny na vykon kriticka mista, na kterych slo zvednout vykon vetsimi registry, byly uz DAVNO prepsany prinejmensim na MMX. Vcetne veci jako kopirovani nebo mazani velkych bloku pameti (je zjevne rychlejsi provest jeden 64bitovy pristup do pameti nez dva 32bitove dokonce i pres cache ...).
Me spis prijde, ze se ceka na to, az se zase trochu posuneme v syntaxi programovacich jazyku. Soucasna prace s vice jadry vyzaduje hlidani threadu, zamku a buhvico vsechno... neboli vyzaduje netrivialni premysleni na strane programatora. V okamziku, kdy date lidem do ruky neco jako blok prikazu cobegin - coend z Ady, ktere zapouzdri paralelismus na lidsky pochopitelne urovni a nikoliv na urovni desitek radku "glue-code", tak zacnou byt programy paralelnejsi.
Nepochybuji, ze se nejakym takovym smerem v Intelu nekdo uz nevydal, ale cesta to nebude jednoducha - jak takovy jazyk napsat (precijen Ada je spise akademicke cviceni), druhak (a to spis vic) prinutit sirsi komunitu k jeho pouzivani.
já myslím, že základní problém není v syntaxi psaní kódu, ale ve schopnosti programátora vymyslet svůj algoritmus tak, aby byl paralelizovatelný v řádu desítek vláken, pokud je to vůbec možné...
No to Vami popisane zvysovanie vykonu je relativne a nepresne.
Mimochodom kde sa doslo na 64bit? Na intel platforme? Ano ale aj tam sa to jedna iba pre zakladne registre.Fpu/mmx jednotka je 80bit a viac.
Skratenie jednej instrukcie na jeden takt tiez nieje pravda. Ak sa jedna o cpu a ma 4 jadra tak mam 4 instrukcie na takt ale aj tie vdaka pipelingu su vecsinov v roznych stadiach rozpracovania s dalsimi instrukciami. Okrem toho aj zalezi ako je IPC vyuzite, resp aky druh instrucie. Napriklad ukon ktory je na CISC jedna instrukcia moze byt na RISC niekolko instrukcii (aj ked toto delenie architektur uz dnes moc nesedi) a nehovoriac o SMID jednotkach kde jedna instrukcia pracuje s viacerimi udajmi naraz.
Kdyby nebylo ARMu, nikdy takovou zprávu Intel nevydá. Atomy by byly stále sračky.
Nicméně toto dává smysl, Intel by se měl zaměřit na mnohojaderné procesory, což jim jde a mají v tom náskok. Tím by mohl ARMy porážet.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.