abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:44 | Zajímavý projekt

Kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů, úspěšně skončila. Bylo vybráno více než 2,1 milionu dolarů, tj. cíl kampaně byl splněn na více než 141 %. Objednáno bylo cca 3 000 telefonů. Telefon Librem 5 by měl být k dispozici v lednu 2019.

Ladislav Hagara | Komentářů: 1
včera 21:11 | Komunita

Ke zhlédnutí jsou videozáznamy přednášek z konferencí All Systems Go! (media.ccc.de) a GStreamer Conference 2017 (ubicast.tv) konaných o víkendu 21. a 22. října. All Systems Go! v Berlíně a GStreamer Conference 2017 v Praze.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Komunita

MojeFedora.cz informuje (en), že Fedora 27 přináší snadný přístup k Red Hat Enteprise Linuxu. Virtualizační nástroj Boxy nyní umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vytvořit lze neomezené množství virtuálních mašin s RHEL.

Ladislav Hagara | Komentářů: 1
včera 19:00 | Komunita

Konsorcium Linux Foundation oficiálně představilo licence pro komunitní otevřená data Community Data License Agreement (CDLA). První licence je copyleftová CDLA-Sharing a druhá permisivní CDLA-Permissive. Odpovědi na často kladené otázky ve FAQ.

Ladislav Hagara | Komentářů: 0
včera 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
22.10. 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 7
22.10. 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 10
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (0%)
 (1%)
 (75%)
 (12%)
Celkem 236 hlasů
 Komentářů: 8, poslední 22.10. 23:02
    Rozcestník

    Budoucnost paralelního programování

    15.3.2006 12:20 | Přečteno: 2551× | Počítače

    K úvaze o paralelním programování mě inspirovala nedávná debata s kamarádem na téma vícejádrových procesorů. Nečekal bych, že někdy začnu na abclinuxu psát blog. Stalo se. Blogy jsou zde navštěvované právě těmi lidmi, kteří mě zajímají a se kterými lze krásně podiskutovat nad některými aspekty výpočetní techniky.

    Současná podoba počítačů vznikla někdy v době druhé světové války. Celou koncepci přivedl na svět VonNeuman, taky se mu od té doby říká VonNeumanova architektura. Trochu odlišná je architektura Harwardská, ale v zásadě se od VonNeumanovy nijak neliší. Základním principem obou architektur je sériové programování. Programy zapisujeme shora dolů, procesor louská instrukce jednu za druhou a ani "paralelní" zpracování v moderních procesorech na tom nic nemění. Procesory pouze předžvýkávají několik instrukcí předem, tak aby hlavní výkonná jednotka v procesoru mohla vykonávat instrukce bez větších prodlev - sériově.

    Programování od dob druhé světové války udělalo veliký pokrok - assembler, fotran, strukturované programování, objektové programování, událostní programování, programování vláken... nicméně procesory se stále drží zaběhnuté praxe a přebírají se instrukcemi jak babička klokočím na růženci. Nenastává pomalu čas změnit i procesory a konečně použít na přehazování instrukcí bagr?

    Údajně nejsou vytvořené metodiky pro paralelní programování a nejsou připravené ani překladače, které umí zaměstnat více procesorů a nejsou ani procesory, který by obsahovaly desítky či stovky jader. První vlaštovky v podobě vícejaderných procesorů slibují, že se v budoucnu začnou objevovat na uživatelských stolech počítače s desítkami či stovkami jader a vývojáři se budou snažit tyto procesory pochopitelně využít co nejlépe.

    Asi každý, kdo někdy donesl jednomu člověku do kanceláře nový počítač, musel zaznamenat, jak se najednou všem ostatním okolo skokově zpomalily počítače. Lidé mají na stolech procesory, které devadesát procent doby zahálejí, přitom jejich uživatelé skřípou zubama a skuhrají, jak ten excel zase dneska dlouho startuje. Mají pravdu - pusťte si na nejrychlejším počítači ve svém okolí třeba office (koffice, openoffice, msoffice - dle vlastního výběru a možností) a sledujte, jak pomalu a jedna za druhou se vykreslují ikonky, čudlíky - celé pracovní prostředí. Rychlejší procesor na tom mnoho nezmění, protože si svým prstíkem ukazuje na instrukci, kterou právě zpracovává, a ani dvakrát rychleji není dostatečně rychle.

    Procesory většinu doby zahálejí - lidé výkon nepotřebují. Co potřebují, je rychlá odezva.

    Programovací techniky jsou pro paralelní programování připravené. Na uživatelském rozhraní složitejšího programu je vidět, jak se vykreslují komponenty jedna za druhou. Přitom jsou jednotlivé komponenty v kódu solidně oddělené a událostní programování přímo vybízí k jejich paralelnímu zpracování. Brání dnes něco tomu, aby každá vybraná metoda běžela na vlastním procesoru? Dovedu si představit, že v programu rozešlu stovce komponent událost expose a stovka komponet (technicky stovka oddělených vláken) se na stovce procesorů zároveň překreslí. Uživatel může mít procesor se sériovým výkonem prvního pentia (více výkonu není potřeba) a navzdory tomu nebude muset čekat na aplikace půl dne. Stačí se jen vzdát myšlenky, že nejvýkonnějších vícejaderných procesorů je škoda na tak podřadnou úlohu, jako je kreslení blbinek na obrazovku.

    Je moje představa správná? Může vést rozvoj vícejádrových procesorů k tomuto způsobu programování? Jakým způsobem by se musely změnit dnešní zaběhnuté programovací techniky, aby programy dokázaly využít stovky procesorů zároveň? Musí být paralelní programování výsadou distribuovaných síťových výpočtů a specializovaných strojů, které stejně nic užitečného nedělají (nepočítám-li simulace atomových výbuchů, hledání mimozemšťanů a léků na X chorob)?

    Diskutujte. Zajímá mě váš názor.

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    15.3.2006 13:10 zde | skóre: 9 | blog: Linuch | Brno
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    > a událostní programování přímo vybízí k jejich paralelnímu zpracování.

    Podle mého názoru naopak události vybízejí k sekvenčnímu modelu, resp. jej vynucují. Spoléhají na getmessage/translatemessage/dispatchmessage smyčku, kterou paralelně implementovat nelze.
    Táto, ty de byl? V práci, já debil.
    15.3.2006 13:32 Abraxis
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Ne nutne. Jasne, ze tahle smycka muze bezet prakticky jen jedna, ale dokazu si predstavit, ze bude "minimalisticka" - tzn. bude vybirat udalosti, ale jejich casove narocne zpracovani bude predavat nekolika paralelne bezicim procesum.
    15.3.2006 13:47 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    V tom případě ale budete muset řešit otázku návazností, protože v některých případech je potřeba zaručit, že určitá událost bude zpracována až po jiné.
    15.3.2006 14:05 zde | skóre: 9 | blog: Linuch | Brno
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    To by ovšem dispatchmessage muselo být asynchronní, což ale v žádném reálném gui není. Pro WM_PAINT a obdobné "broadcast" zprávy by to sice implementovat docela snadno šlo, ale jinak asi ne. To že samotný dispatch bere minimum cpu je pravda, ale protože je blokující tak to nepomůže.
    Táto, ty de byl? V práci, já debil.
    25.3.2006 15:14 polo
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    SMP je rozumne pouzivat pouze tehdy, dosahnemeli distribuci problemu zrychleni, tj dokazemeli rozdelit danou ulohu na takove casti, ze jejich casti na ruznych uzlech se budou pocitat dobu delsi nez je doba potrebna pro predani dat. Coz se domnivam, ze v pripade vykreslovani GUI jentak nedosahneme.

    Dalsi problem je se synchronizaci etc, ale tyto veci uz jsou pro paralelni stroje celkem vyresene, vetsinou se resi ruznymi algortimy pro zamikani sekci atp..

    Domnivam se ze implementace v zadanem pojeti v dnesnich meritkach by byla nefektivni.

    Pekny den.
    15.3.2006 13:41 Marek 'marx' Grác | skóre: 21 | blog: Paralelný blog | Brno / Bratislava
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Programovacie techniky na to práve nie sú pripravené. Paralelne dokážeme procesory/počítače využiť hlavne v prípade, že dokážeme rozdeliť úlohu na časti, ktoré dokážeme vykonávať oddelene (napr. rozdelením intervalu). V opačnom prípade máme problémov vyše hlavy. Samozrejme, že ak by sme mali dva procesory/jadrá tak nie je problém, aby na jednom bežalo KDE/GNOME/X a na druhom aplikácie, ale to je 'klasický' prístup.
    15.3.2006 14:19 zde | skóre: 9 | blog: Linuch | Brno
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    To je jen jedna část problému. Rozdělit algoritmus obvykle jde docela snadno, ovšem jeho zdroje (tj hlavně paměť) už tak dobře dělit nejde.

    Programovací techniky na úrovni procesu spoléhají na jednu sdílenou paměť. Jde to částečně vyřešit- samostatná cache u SMP, triky s virtuální pamětí u clusterů apod, ale není to koncepční řešení. Defaultně se stále uvažuje sdílený prostor, kde každý thread může číst a zapisovat co chce, a různými technikami se to cachuje a optimalizuje aby to nějak běželo.

    Správně by paralelizace měla být explicitní, tj překladač a OS by vždy měl přehled který kus paměti patří kterému threadu, který je třeba RO a měl by se replikovat, a který je RW a s kterým (hardwarově implementovaným) zámkem je spojen.
    Táto, ty de byl? V práci, já debil.
    15.3.2006 15:13 Marek 'marx' Grác | skóre: 21 | blog: Paralelný blog | Brno / Bratislava
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Medzi problémy vyše hlavy som myslel práve tú pamäť. S tým jediným mám skúsenosti, ono to je vidno pre laika aj na tom ako naposledy hrali ten Doom s obrazom roztiahnutým na nejakých 10 000 pixlov, kde bol vždy jeden komp na dva monitory a malo to nejakých 15-30fps (tuším). A IMHO aj to bol celkom úspech :)
    15.3.2006 14:21 barney
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    v prvom rade na to nie sú pripravení programátori :-) a o pseudoprogramátoroch ani nevravím
    15.3.2006 14:23 pzad | skóre: 30 | blog: pzad
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Paralelny program sa hodne zle ladi a pripadne chyby v sinchronizacii sa strasne zle hladaju a obcas sa aj velmi divne prejavuju.
    vencour avatar 15.3.2006 15:17 vencour | skóre: 55 | blog: Tady je Vencourovo | Praha+západní Čechy
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování

    V Quantianu je openMossix, clusterKnoppix atd., ale zatim se mi je síťově nepodařilo zprovoznit (a tolik jsem si s tim nehrál). Prostě jsem dva procesory v openMossixView neviděl. Časem se k tomu snad dostanu.

    Ty nejhlubší objevy nečekají nutně za příští hvězdou. Jsou uvnitř nás utkány do vláken, která nás spojují, nás všechny.
    stativ avatar 15.3.2006 17:40 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování

    Mozna budu placat blbosti, ale myslim, ze tohle OpenMosix prave bohuzel nepodporuje. OpenMosix se i musi kompilovat bez podpory SMP v jadre.

    Pokud to bylo ale mysleno jako ze se pocitace njepropojily pres sit, tak se afaik v openmosixview nezobrazuji procesory ale pocitace. Navic se musi v takovem klikatku propojit 'linkami' aby o sobe vedeli.

    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    15.3.2006 15:52 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Nevím jak ostatní, ale mě v drtivé většině případů zpomaluje disk a paměť. Procesor považuji za úplně poslední věc, která by mě v tomto ohledu trápila.

    Ostatně ty to taky sám říkáš:
    Procesory většinu doby zahálejí - lidé výkon nepotřebují. Co potřebují, je rychlá odezva.
    Ale rychlejší odezvu při startu office nezískáš přidáním dalšího procesoru, který se bude taky většinu času nudit. Ale právě rychlejším diskem/pamětí.

    Ad: paralelní zpracování ... nic není tak hezké jak to vypadá. Pro paralelní zpracování se hodí jen některé úlohy. Typickým příkladem je zpracování obrazu, vědecké výpočty. U spousty úloh začne být synchronizační režie tak vysoká, že překryje veškerý zisk z vlastního paralelismu. A to vůbec nemluvím o tom, že paralelní programy bývají náročnější na kódování a vůbec se hůř ladí.
    When your hammer is C++, everything begins to look like a thumb.
    15.3.2006 16:59 dad
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    [...] jak ten excel zase dneska dlouho startuje. Mají pravdu - pusťte si na nejrychlejším počítači ve svém okolí třeba office (koffice, openoffice, msoffice [...]

    u jednoho zakaznika se resila problematika, ze prodejni oddeleni nedokaze vyprodukovat za mesic pozadovany pocet nabidek. Sef dusil zamestnance a ti v ramci workshopu pozadovali v prenesenem slova smyslu "turbopropisky", aby mohli praci stacit.

    Podarilo se nam zakaznika presvedcit, ze bude vyhodnejsi nabidky nepsat jako doposud za pomoci predpotopnich nastroju (word, openoffice apod), ale ze by to mel delat za ne pocitac. Naprogramoval se inteligentni nabidkovy system a pocet nabidek vzrost 20 x.

    Proto si myslim, ze viceprocesorove systemy nepomohou...
    15.3.2006 18:59 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Každý, kdo zkusil naprogramovat několik složitějších paralelních aplikací ví, že paralelní programování není žádná sranda.

    Zásadní problém je dvojí. První je ten, že vlastní paralelní algoritmus běží v prostředí, které není paralelní. Sdílí se až příliš mnoho věcí. Od paměti počínaje až bůhvíkam konče. Druhý problém je ten, že jen málo problémů lze efektivně řešit paralelně. Naprostá většina algoritmů je maximálně pseudoparalelní, kdy se udělá malý kousek a pak nastává synchronizace s jinými paralelními větvemi a dochází k předávání dat mezi větvemi. To se neobejde bez synchronizačních akcí, které dost často bývají dost náročné a mnohdy pošlou celý výkonnostní i jiný zisk z paralelního algoritmu do kopru.

    Problém paralelních algoritmů je cena vývoje, která je mnohem výše, než při obvyklém sériovém programování. Připočtěte si zvýšenou možnost chyb při synchronizaci a v podstatě fakt, že najít chybu v paralelním algoritmu je podstatně obtížnější, než v obyčejném sériovém programu.

    Kromě toho dnes již prakticky neexistuje program, který by se částečně paralelně nevykonával. Dnes každý moderní procesor obsahuje několik různých jednotek, které běží dost nezávisle a úkolem kompilátorů je vytvořit takový kód, který umožňuje maximalizovat paralelní běh kódu na daném procesoru. Některé kompilátory, třeba Intel dokonce aktivně vyhledávají v programu kousky, které lze paralelizovat.

    Závěr: Problém paralelních algoritmů je více ekonomický, než jiný. Paralelní algoritmy se programují déle (= větší náklady na vývoj), vyžadují kvalitnější programátory (= větší náklady) a problém chyb v paralelních algoritmech má poněkud fatálnější následky (= větší náklady). Problém rychlosti programů a paralelních algoritmů z ekonomické stránky je ve stejné rovině, jako proč se dnesw píší méně efektivní programy, než kdysi. Pokud zaplatíte programátory, udělají vám rychlejší a kvalitnější program i dnes. Pokud zaplatíte programátory, udělají vám i kvalitní paralelní program. Ale protože ekonomika vládne světem, tak se financuje jen to, co je nezbytně nutné a paralelní programování jen málokdy přináší zisk, který ospravedlňuje podstatně vyšší náklady (samozřejmě kromě nekolika specifických oblastí).
    Petr Bravenec avatar 15.3.2006 21:20 Petr Bravenec | skóre: 43 | blog: Bravenec
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Dobře. Rozumím tomu. Ekonomické důvody jsou jasné. Ale já zkusím přiblížit svoje představy. V dobách šlapacích počítačů se používal jazyk C a v něm bylo možné definovat některé proměnné jako registrové. Dělalo se to snad proto, aby tehdejší jednoduché překladače netahaly například řídící proměnné v cyklech přes zásobník. Dneska se o to nestaráme a necháváme to na překladačích a spoléháme na to, že registrů je dost. I programování dnes vypadá jinak - typická aplikace je poskládaná z možství objektů se svými vlastnostmi a metodami. Objekty jsou od sebe oddělené a ideálně spolu komunikují pouze prostřednictvím veřejných metod. Každá instance objektu je samostatný element - proč tedy analogicky k registrovým proměnným nedeklarovat některé vybrané objekty jako typ cpu a nesvěřit zpracování takového objektu samostatnému procesoru? Samozřejmě, že jednotlivý procesor většinu času prozahálí - ale ono není účelem zaměstnat všechny procesory na sto procent. Programovat dnes pomocí vláken je nepříjemné a není tlak na vytvoření lepšího prostředí. V momentě, kdy bude k dispozici běžně několik procesorů, vývojáři budou chtít využít potenciálu takových procesorů. Budou volat po zjednodušeném vývojovém prostředí a tlak na jeho vytvoření bude vzrůstat. Se vznikem takových nástrojů se pak samozřejmě razantně sníží i cena vývoje a poptávka po mnohojádrových procesorech může vesele růst.
    Petr Bravenec - Hobrasoft s.r.o.
    Petr Bravenec avatar 15.3.2006 21:23 Petr Bravenec | skóre: 43 | blog: Bravenec
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Tedy... ééééé... věštit nechci, vizionářů má IT branže dost, jen by mě zajímala možnost takového vývoje.
    Petr Bravenec - Hobrasoft s.r.o.
    15.3.2006 21:37 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Já rozumím, ale přesto se domnívám, že skoro všechno je jinak.

    Dokonale optimalizující kompilátor označovat proměnné jako register nepotřebuje a slovo register ignoruje, což dnes každý dobrý kompilátor dělá.

    Objektové programování je jen jedna z metod programování. I když je jistou dobu v módě, není to jediný způsob.

    Pro mě bylo obrovskou zkušeností setkání s realtimovými a simulačními jazyky před cca 20 lety. Studoval jsem technickou kybernetiku - v zásadě teorii řízení systémů a tam jsem se seznámil s jazyky, které dodnes považuji za poklad, mnohá jména už jsem zapomněl. Paralelní a pseudoparalelní programování se tam už tehdy řešilo na sto a jeden způsob a seznamoval jsem se s nejrůznějšími způsoby, jak je zabudovat do jazyků, aby to bylo pro programátora co nejjednodušší. Progamování pomocí vláken je spíše v měnšině, a používá se u jazyků, které v podstatě nedělají nic jiného, než wrapper nad operační systém, jako je třeba C, Java, a další. Jestli chcete poznat skutečná řešení paralelního programování, musíte pryč z mainstreamových programovacích jazyků, ty na to nejsou určeny. Pro začátek doporučuji podívat se na řešení, které nabízí jazyk Ada, ale pozor! Budete překvapen, jak je to odlišné od "běžného pracího prášku", ehm chtěl jsem říci od běžného řešení v mainstreamových programovacích jazycích.

    Já stále vzpomínám na technologie a programovací jazyky, které jsem před těmi 20 až 25 lety zkoušel a byly geniální! V podstatě celý dnešní tzv. moderní vývoj sw nedělá nic jiného, než se k nim vrací a postupně se k nim přibližuje. Je to strašná sranda. Třeba za nějakých 50 let se objeví nějaký super hyper moderní styl programování a super programovací jazyk, abych si jenom řekl tak paráda, zase o krůček blíž tomu, co jsem poznal tehdy. :-) Jak říkám, je to opravdu sranda :-)
    Petr Bravenec avatar 15.3.2006 22:01 Petr Bravenec | skóre: 43 | blog: Bravenec
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Hmmm. Přiznám se, že s žádným prostředkem pro paralelizaci aplikace jsem se dosud nesetkal. Vždy jen ten dnešní mainstream. Nemohla by ale snadná dostupnost víceprocesorových počítačů udělat mainstream z postupů, které jsou dnes vyložené okrajové a mimo kuriozní situace se nevyužívají?

    Registrové proměnné v C jsem používal naposledy na počítačích SMEP :-) a vzpomínal jsem je proto, že v tehdejší době to byl jeden z prostředků, jak usnadnit překladači (vývojovému prostředí) seskládání celé aplikace.
    Petr Bravenec - Hobrasoft s.r.o.
    15.3.2006 22:37 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Nesetkal jste se tím jednoduše proto, že na nabouchání databázové aplikace, nebo na pár jednoduchých matematických algoritmů to nepotřebujete. A na škole i v běžné praxi se tím pádem běžně nesetkáte s ničím jiným, než s tímto. A je to v pořádku - nástroj se musí vybírat podle toho, co chcete dělat.

    Dnešní doba má tu trochu protivnou vlastnost, že vyrábí monokultury. Prostě cokoli, co nemá 80% trhu a na čem se okamžitě nedá zbohatnout, to se zapomíná, nikdo o tom nepíše.

    Příliš nevěřím tomu, že by snadná dostupnost víceprocesorových počítačů mohla udělat mainstream z postupů, které jsou dnes na okraji. Proč taky? Dnešní postupy vyhovují, obchodní a ekonomický svět je přijal. Nepotřebujete v zásadě nic jiného.

    Spíše očekávám to, že programátoři budou bouchat komponenty jako dnes, jen bude pár komponent, které v sobě mají určité paralelní prvky. Ty naprogramuje speciální firma a 99,999% programátorů nebude ani vědět, že se něco děje paralelně.

    Mezi námi, chcete-li se něco zajímavého o programování dozvědět, musíte přestat být "monokulturním programátorem".
    15.3.2006 22:44 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Registrové proměnné v C jsem používal naposledy na počítačích SMEP :-) a vzpomínal jsem je proto, že v tehdejší době to byl jeden z prostředků, jak usnadnit překladači (vývojovému prostředí) seskládání celé aplikace.

    Takže taky máte své zkušenosti. :-) Rád na tu dobu vzpomínám, i když vrátit bych jí nechtěl.
    16.3.2006 15:12 zde | skóre: 9 | blog: Linuch | Brno
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Pro mě bylo obrovskou zkušeností setkání s realtimovými a simulačními jazyky před cca 20 lety. Studoval jsem technickou kybernetiku - v zásadě teorii řízení systémů a tam jsem se seznámil s jazyky, které dodnes považuji za poklad, mnohá jména už jsem zapomněl. Paralelní a pseudoparalelní programování se tam už tehdy řešilo na sto a jeden způsob a seznamoval jsem se s nejrůznějšími způsoby, jak je zabudovat do jazyků, aby to bylo pro programátora co nejjednodušší.
    INMOS Transputer? Minimalisticky CPU kontext? Hardwarový message passing? Bezelo to na par megahertzech, ale task switch byl hluboko pod mikrosekundu.. Occam? Otazniky a vykricniky? :)

    http://en.wikipedia.org/wiki/Transputer
    Táto, ty de byl? V práci, já debil.
    Věroš avatar 15.3.2006 22:53 Věroš | skóre: 24 | blog: Co není v hlavě | 49.29 s.š., 16.54. v.d.
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Dnes se víceprocesorové stroje používají (a využívají) zejména pro relativně nezávislé úlohy - pěknou aplikací jsou webové aplikace, kde jednotlivé požadavky jsou relativně nezávislé a každá běží dlouho samostatně bez závislosti na ostatních a nemusí se synchronizovat.

    Časem se v tomto duchu můžeme dočkat třeba toho, že vykreslování ovládacích prvků (widgetů) bude mít na svědomí jedno vlákno a druhé bude řešit aplikační logiku. Konec konců, Windows k něčemu podobnému směřují, každá vlastnost už dnes tam má vlastní vlákno.

    --Věroš
    Školím Ansible
    16.3.2006 15:16 zde | skóre: 9 | blog: Linuch | Brno
    Rozbalit Rozbalit vše Re: Budoucnost paralelního programování
    Šak tohle se v praxi často a relativně bezbolestně distribuuje.. udělá se serverová farma, vepředu požadavky podle IP adres klientů rozhazuje nějaká proxy, nebo rovnou udělají rr dns. Ale normální desktop nebo interaktivní aplikaci (rozuměj s jedním uživatlem) paralelně obsluhovat nejde.
    Táto, ty de byl? V práci, já debil.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.