Podle zjištění Intelu jen asi jedno procento všech programátorů umí psát kódy pro paralelizované čipy, nebo si něco takového alespoň vyzkoušeli. Anwar Ghuloum, hlavní inženýr jedné z technologických laboratoří Intelu, v blogu Intelu přesně...
29.11.2007, Pavel Boček, aktualita
Skutecne paralelni programovani by si totiz mistni experti osahali na FELu az tesne pred diplomkou.
Odpovědět0 0
Nejen FELem svět je živ.
https://new.stag.zcu.cz/apps/stag/prohlizeni/pg$_prohlizeni.sylabus?kat=KIV&predm=PPR&rok=2007
https://new.stag.zcu.cz/apps/stag/prohlizeni/pg$_prohlizeni.sylabus?kat=KIV&predm=PPR&rok=2007
Odpovědět0 0
Na kybeře se dělalo řízení motoru a tam to bylo nutné naprogramovat více vláknově....a bylo to tušim ve čtvrtém semestru ;).
Odpovědět0 0
Hmm .. asi 99% programatorov nechape co to je programovat pre viac jadier, a ako pozeram diskusiu tak asi to je aj pravda. Ohanat sa vlaknami :) C#pisti a Javisti - ved len bezna enterprise applikacia ma spustenych 20-50 vlakien, ale ved to vobec nezarucuje ze to pojde lepsie ked tam budes mat 50 jadier, a tych vasich 50 vlakien bezi v pohode aj na 1jadrovych CPU. Aby to slo lepsie tak by VM muselo byt napisane(zooptimalizovane) pre viacej jadier a aj samotny compiler javy, ale ani to by Jave nezarucilo vyssi vykon kedze tam nevyriesis optimalizaciu na jadro :) ...
Odpovědět0 0
... ano
Odpovědět0 0
Spis bych rekl, ze jen jedno procento firem je ochotno platit zvysene naklady (clovekocas) na psani a odladovani slozitejsich vicevlaknovych aplikaci, pokud to neni nezbytne nutne. Zakaznici za to totiz platit taky nechteji. Navic mnoho uloh proste vicevlaknove udelat nelze. V podstate se to zaplati u vedeckych aplikaci a velkorozpoctovych her :) (Jestli si nekdo mysli, ze staci v kompileru zapnout "nejakou" "optimalizaci", tak mu doporucuju, at si o tom nejdriv neco precte. To uz by to byly vsechny aplikace vicevlaknove, ze.)
Odpovědět0 0
Problem nie je v tom, ze to nejde, ale v tom, ze to nik nechce. Dokonca aj v knihach o C/C++ sa stala viac objavuje myslienka, ze optimalizuje sa az na konci a len casti, ktore to skutocne potrebuju. Podobne pristup firiem je casto kratko zraky a miesto riesenia, ktore by sa dalo pouzit aj v buducnosti, chu rychle riesenia konkretneho problemu.
Odpovědět0 0
Nějaké postupné iterace se píšou vícevláknově dost blbě ...
A naprosto nesouhlasím ... opravdu má cenu optimalizovat jen 5% kódu, který žere 95% času ... teď nemluvím o tom, že se program musí dobře navrhnout, aby ten čas nežral zbytečně. Rychlé a aspoň nějaké řešení chce zákazník, programátorům je to jedno.
A naprosto nesouhlasím ... opravdu má cenu optimalizovat jen 5% kódu, který žere 95% času ... teď nemluvím o tom, že se program musí dobře navrhnout, aby ten čas nežral zbytečně. Rychlé a aspoň nějaké řešení chce zákazník, programátorům je to jedno.
Odpovědět0 0
Je jasne ze niektore operacie sa nedaju paralelizovat jeden priklad za vsetko, je rekurzia.
Tiez mi je jesne, ze prehnana optimalizacia plikacie typu maoovanie stratou casu, ale su aj opacne extrmy.
Tiez mi je jesne, ze prehnana optimalizacia plikacie typu maoovanie stratou casu, ale su aj opacne extrmy.
Odpovědět0 0
To je právě otázka. Jednak není rekurze jak rekurze a jednak třeba prohledávání stromu do šířky je paralelizovatelné moc dobře. Ale to je již o skutečném paralelním programování - tj. kompletně navrhnout nový algoritmus, který bude skutečně počítat dílčí úkoly paralelně.
Odpovědět0 0
Jenže vícevláknové aplikace nejsou tak napsány jenom kvůli optimalizaci. Např. pro realtime aplikace, které obsluhují více klientů současně je možné napsat buď komplikovaný state-machine nebo jednoduché obslužné postupy. Druhý případ je určitě přehlednější a jednodušší na údržbu a rozšiřování. Akorát je potřeba vyřešit pár drobných problémů s vícero vlákny.
Odpovědět0 0
No v mojej predchadzajucej praci som sice nerobil realtime systemy, ale vyuzival so viac vlakien koli obsluhe HW a ten jednoduchy a lahko rozsiritelny system sa vedel bez spravnej analyzy zvrhnt na take zverstvo, ze by sa clovek cudoval a koli spetnej komtibilite nebolo mozne jednoducho stare zahodit a zacat na zelenej luke.
Za to teraz robim realtime systemy vyuzivam stavove automaty a aj systemy ovela zlozitejsie ako tie s ktorymi som sa predtym stretol sa daju lahko pochopit. Cela praca je zalozena na perfektne navrhnutom frameworku.
Ale toto skor dokazuje aka je dolezita dobra analyza, a aj ked na to neprides hned tak po okoch to moze stat vela usilia.
Za to teraz robim realtime systemy vyuzivam stavove automaty a aj systemy ovela zlozitejsie ako tie s ktorymi som sa predtym stretol sa daju lahko pochopit. Cela praca je zalozena na perfektne navrhnutom frameworku.
Ale toto skor dokazuje aka je dolezita dobra analyza, a aj ked na to neprides hned tak po okoch to moze stat vela usilia.
Odpovědět0 0
Stavový automat nezavrhuji, je to dobrý přístup. S nástupem vícejádrových procesorů ale mají výhodi ti, kdo používají více vláken.
Odpovědět0 0
Problem je v tom ze drviva vedsina realtime systemov nestoji na klasickych CPU, ale na specialzovanych kontroleroch a tie maju stale len jedno "jadro" a tak skoro sa to nezmeni. Tam vedsinou nie je pozadovany spckovy vykon, ja napriklad viem pracovat s vlaknami, viam ich synchronizovat, a starat sa o kriticke sekcie, ale naprogramovat zlozity algoritmus na vypocet niecoho tak to je trocha o inom tam nestaci vedet pouzit vlakna, ale aj vedet vybrat spravne algoritmi a s tymto nemam skoro ziadne skusenosti.
Odpovědět0 0
Souhlasím, ale jenom částečně. Některé typy aplikací (typicky třeba CTI) jsou stavěné na PC architektuře a tam už se vícejádrové procesory tlačí i do industry segmentu (cP - compact PCI).
Odpovědět0 0
Sice m tato oblast moc nehovori, ale nemyslim,z e zrovna tu je nevhinutne zachovat podmienku na real time system. Latenciu 20-30ms nik nespozna a tam sa vies dostat aj bez nutnosti pouzitia real time systemov.
Odpovědět0 0
... ale dnes se programuje prevazne v C++ nebo podobnych vecech a tam jde spis o kompiler nez o programatora.
Pokud bude diskuze o Assembleru tak potom ano. Malo kdo dokaze napsat spravne zretezene instrukce.
Pokud bude diskuze o Assembleru tak potom ano. Malo kdo dokaze napsat spravne zretezene instrukce.
Odpovědět0 0
No právě že v C++ je potřeba ošetřit např. přístup k jedné instanci objektu z dvou paralelních vláken. K tomu není potřeba ani více procesorů, stačí preemptivní mutitasking. Jinak se stane, že volání jedné metody ještě neskončí a někdo zavolá druhou a nalezne objekt v nekonzistentním stavu.
Na jedné straně by se jistě dalo na úrovni kompilátoru ošetřit, aby metody byly skutečně atomické (nerozdělitelné), ale na druhou stranu tím bereme možnost optimalizace programátorovi. Myslím, že v případě C++ je dobře, že to ošetřeno není. U méně efektivních a bezpečnějších jazyků je to naopak vítáno.
Na jedné straně by se jistě dalo na úrovni kompilátoru ošetřit, aby metody byly skutečně atomické (nerozdělitelné), ale na druhou stranu tím bereme možnost optimalizace programátorovi. Myslím, že v případě C++ je dobře, že to ošetřeno není. U méně efektivních a bezpečnějších jazyků je to naopak vítáno.
Odpovědět0 0
Staci sa pozriet na skoly, moc k tomu studentov netlacia aby sa pokusali prevadzat svoje aplikacie na viac vlakien, pokial to niekto chce skusit ostava sam na sebe, teoriu k tomu ma dostupnu na nete ale na labakoch sa necvici napriklad synchronizacia vlakien, takze sa do toho nechce nikomu len tak pustat.
Pokial chce intel zvysit toto procento tak bude musiet trosku podporit skoly k iniciatíve tieto navyky u buducej generacie programatorov vybudovat.
-
Samozrejme vyzera, ze svita na lepsie casy, o viac vlaknach zacinam v skole pocut cim dalej tym viac, hadam sa v buducnosti vytvori trebars predmet kde by sa studenti naucili zakladne tipy a triky ako spravne synchronizovat...
Pokial chce intel zvysit toto procento tak bude musiet trosku podporit skoly k iniciatíve tieto navyky u buducej generacie programatorov vybudovat.
-
Samozrejme vyzera, ze svita na lepsie casy, o viac vlaknach zacinam v skole pocut cim dalej tym viac, hadam sa v buducnosti vytvori trebars predmet kde by sa studenti naucili zakladne tipy a triky ako spravne synchronizovat...
Odpovědět0 0
Pozerám-li sa na děti u nás ve škole. Tak vícevláknové programy u nás píšou už děti ve 3 třídě, tedy když je jim 9 let. Přijde jim to naprosto normální a nedělají s tím žádné cavyky.
Používáme Robocode nebo Scratch.
Používáme Robocode nebo Scratch.
Odpovědět0 0
No nevim o jakejch skolach mluvis ale u nas treba vsechny nutil aby pouzival bud vlakna nebo vic procesu takze myslim ze to zas tak cerny neni
Odpovědět0 0
.... zlatý Packal ......... :))))
Odpovědět0 0
Několik let jsem se jako aplikační programátor živil psaním SQL spuštěného z prostředí, které nepodporuje vlákna. Na druhou stranu databázi systémáci nastavili pro podporu paralelního zpracování, takže to dělala na osmi procesorech za mě. Odhaduji, že podíl vývojářů systému k počtu aplikačních programátorů je mnohem menší než 1% a není důvod si myslet, že je něco špatně.
Odpovědět0 0
O Javě se asi nebavil, že?
Odpovědět0 0
taky mi to cislo prijde nejak podezrele nizke ... s vlakny se prave v Jave pracuje ani o tom clovek nemusi vedet a napsat multivlatknovou aplikaci neni vubec zadny problem i pro programatora, ktery v ni pracuje velmi kratce
a vzhledem k tomu, ze Java ma dominantni postaveni mezi programovacimi jazyky, tak si myslim, ze 1% je jen nejake marketingove cislo, kde marketaci zapocitali snad i uzivatele VisualBasicu a podobnych jazyku
a vzhledem k tomu, ze Java ma dominantni postaveni mezi programovacimi jazyky, tak si myslim, ze 1% je jen nejake marketingove cislo, kde marketaci zapocitali snad i uzivatele VisualBasicu a podobnych jazyku
Odpovědět0 0
Asi jak kde. Ale v prumeru ma Java velice minoritni postaveni. Jednak mi ukazte bezne domaci PCko, kolik na nem bezi Java aplikaci. A na serverech to je jen o trochu lepsi situace (a to maximalne u nejakych proprietarnich malo zatizenych aplikaci typu banky apod.). Treba u webovych aplikaci s radove tisici transakcemi za vterinu je jeji podil mozna jeste mensi nez u tech koncovych uzivatelu. Takze zbyvaji jedine vicevlaknove aplikace pro mobilni telefony :)
Odpovědět0 0
Java, je najpouzivanejsi programovaci jazyk. Ja jej sice stale neviem prist na chut, ale je rozsirena, koli multiplatformovosti a koli tomu, ze sa v tom nauci programovat, kazdy kdo chce(ja som nechcel). Aplikacie v Jave pravdepodobne bezia vo viac vlaknach koli JRE, ale vo vedsine pripadov to nie je koli tomu, ze by to tak aplikacny programator chcel.
Odpovědět0 0
Škoda jen, že napsat to na x vláken v Java vyjde rychlostně jako na jedno vlákno v C...
Odpovědět0 0
To je na flame ... jak kdy ...
Odpovědět0 0
To nebylo v úmyslu.Java je skvělá svou snadnou přenositelností mezi platformami, jen by to chtělo nějak líp zoptimalizovat.Pokud něco v Jave chtete provozovat na fanless miniaturnim (VIA) PC s 400MHz procesorem tak je to doslova utrpení a je to škoda,protože má velký potenciál.
Odpovědět0 0
Mozno to je dovod na flame, ale podla roznych porovnani co sme hladali na nete je na Java este ovela horsie ako C# a porovnavat s C/C++ asi fakt nema zmysel. Na druhu stranu HW jw dnes tak vykonny, ze pri vedsine aplikacii je jedno v com je napisana, rozdiel sa strati.
Odpovědět0 0
Asi sa pohybujem vo vyberanej spolocnosti, ale nemam pocit, ze by len jedno percento programatorov malo realne skusenosti s pisanim programov do viacerych vlakien. Aj ked C++ rozhodne nie je najrozsirenejsia platfomra, takze to co vidim okolo seba nemusi davat realny obraz.
Odpovědět0 0
v robote programujeme v C# a sme tu 4ja programery a vsetci vieme programovat viac vlaknove aplikacie...
Odpovědět0 0
Tak to panove asi patrite do toho jednoho procenta ;)
Odpovědět0 0
Zajímá Vás tato diskuze? Začněte ji sledovat a když přibude nový komentář, pošleme Vám e-mail.
Nový komentář k článku
Pro přidání komentáře se přihlaste (vpravo nahoře). Pokud nemáte profil, zaregistrujte se pro využívání dalších funkcí.
reklama
reklama
Z dalších serverů
