V poslední době se hodně mluví o Erlangu. No a protože jsem slaměný vdovec a u žehlení se nudím, pustil jsem si přednášku od otce Erlangu Joe Armstronga. V tomto zápisku se chci o své dojmy z této přednášky podělit s vámi, mými oddanými fanoušky. Chci předem upozornit, že to jsou jen dojmy, pořádně ještě nemám na věc ujasněný názor.
Začátek přednášky je relativně zajímavý. Už jsem nejméně stokrát slyšel, že se programátoři musí začít chovat jinak, protože se objevily vícejádrové procesory. Ale vždy jsem si říkal, že tu máme přeci víceprocesorové stroje už hodně dlouho, tak jakápak změna. Až díky této přednášce jsem mi došlo, že změna není v tom, že máme více jader. Změna je v tom, že se sekvenční zpracování procesorů nezrychluje tak, jak jsme byli zvyklí. Od jisté doby roste rychlost hlavně díky paralelizaci. Všimněte si, že taktovací frekvence procesorů se v poslední době zas tak zásadně nemění. Naopak se objevují X jádrové procesory. Už prý existuje 1000 jádrový procesor, pokud bude růst počet jader exponenciálně, můžeme se v nedaleké budoucnosti dostat na zajímavá čísla. Předpokládejme, že je takový nárůst počtu jader možný. Dosud jsme byly zvyklí, že naše programy automaticky s novým procesorem zrychlí. Od příště už to tak být nemusí. To že klient můj sekvenční program nasadí na procesor s miliónem jader, neznamená, že bude milionkrát rychlejší. Spíš bude pomalejší než na jednojádrovém.
Tak a teď mé dojmy. Jak to ovlivňuje programátory? Protože jsem zvyklý na serverovou Javu, budu psát hlavně o ní. Představme si, že máme 1000 jádrový procesor. Jak budeme muset změnit svůj kód, aby běžel efektivně? Představme si pro začátek, že mám jednoduchou aplikaci založenou na servletech. Přijde dotaz, já ho v jenom vlákně zpracuji a v tom samém vlákně pošlu odpověď. Abych si to zkomplikoval, budu předpokládat, že ne všechna práce je výpočetně náročná, občas budu čekat na disk, databázi na jiném stroji atp. To znamená, že potřebuji mít víc vláken než procesorů (jader), abych byl schopen je vytížit. To znamená, že potřebuji víc než tisíc současných požadavků, aby ta vlákna měla co dělat (tady to trochu moc zjednodušuji, ale snad mi to prominete). Pokud je tento předpoklad splněn, nemusím svoji aplikaci měnit vůbec. Tedy za předpokladu, že JVM zvládne 1000 jádrový procesor.
Pokud mám méně než několik tisíc současných dotazů, procesor plně nevyužiji. Musím práci rozsekat na víc kousků. Jde to v Javě vůbec? Pan Armstrong tvrdí, že ne. Tvrdí, že Java je staromódní jazyk, který se spoléhá na sdílenou paměť, sdílený stav, zámky, transakce a podobná zvěrstva. Naproti tomu je Erlang moderní jazyk, který je navržen s tím, aby skvěle fungoval paralelně, který nemá problém s miliónem běžících pidiprocesů, které žádný stav nesdílejí, jenom si předávají zprávy. Tvrdí navíc, že problém Javy a podobných jazyků je přímo v jejich pojetí. Že jsou to jazyky sekvenční, kdežto Erlang je jazyk paralelní. Tvrdí navíc, že svět jako takový, je paralelní, tudíž je těžké ho popsat sekvenčním jazykem. Abych pravdu řekl, nevím jestli je svět paralelní nebo sekvenční. Na jednu stranu se každý člověk stará sám o sebe a rozhodně nesdílí svůj stav s ostatními. Jenom jim posílá všelijaké zprávy. To by nahrávalo paralelnímu pohledu. Jen ovšem do té doby, než se octnete v dopravní zácpě, která je podle mě silně sekvenční.
A v tom je právě zakopaný pes. Potíž není v jazyku, ale v řešeném problému. V Javě také nemusím sdílet žádný stav. Každé vlákno může mít svoji logicky oddělenou paměť. Když se nad tím zamyslím, tak už se to dávno děje. Proto jsou tak populární řešení založená na JMS. Jednotlivé oddělené procesy si jenom předávají zprávy. To je přesně to, co mi poskytuje Erlang. V Javě to jenom není zakomponováno přímo v jazyku. Je to v ní na logicky vyšší úrovni. A tedy i s mnohem vyšší režií.
Ano je to tak, pokud mám problém, který se dá rozseknout na hodně malých úkolů, je snadné ho paralelizovat. Ale na to není nutné měnit jazyk. Mohu použít JMS, JINI nebo jiné jednodušší mechanizmy. Stále tu ale ještě máme spoustu aplikací, které prostě vyžadují sdílený stav, jejichž doména je sekvenční, které se paralelizovat nedají. Jsem rád, že mohu používat jazyk, který mi to umožňuje.
Bylo by samozřejmě pěkné, kdyby Java umožňovala snazší spouštění paralelních úloh. Na druhou stranu k tomu už spěje. V Javě 5 byly zavedeny executory (spouštěče?), Futures a datové struktury, které nevyžadují synchronizaci. Možná není paralelní programování v Javě tak přímočaré jako v Erlangu, ale relativně jednoduché je. Takže můj závěr je následující – pokud máte problém, který je principiálně podobný telefonní ústředně, zkuste Erlang. Pokud píšete obecnou aplikaci, zůstaňte u Javy.
1) Zatím jsem nenabyl dojmu, že řešení postavená na JMS jsou nějak extrémně oblíbená, ale třeba jsem neměl jen štěstí (setkal jsem se s pravým opakem, kde to šlo, tak se všichni JMS vyhýbali)
2) Lidé fungují sekvenčně, přesto, že žijí v paralelním světě. Ženy fungují o chlup paralelněji než muži 🙂 A obvykle se nám daří dělat jednu věc lépe a pořádněji než stejný pokus se 2 současně. Tak to je, z toho plyne i hromada věcí a chyb, které lidi dělají (čistě jen proto, že přemýšlí sekvenčně a tedy nedomyslí paralelní souběhy). A protože i programátoři jsou lidé a SW je lidský výtvor, je podstatně snadnější programovat sekvenčně, protože se to lidem jednodušeji chápe. Lépe programuje, lépe testuje (!), lépe debuguje. Poprvní eufórii z paralelismu se přešlo v Javě k servletům, které fungují jednovláknově, neparalelně, došlo na zjednodušování, které podle mě bylo krokem správným směrem.
Myslím, že lidé mohou trochu pomoct strojům v rozdělení úloh tak, aby se lépe paralelizovaly na úrovni procesorů, nicméně by vlastní programování mělo i nadále zůstat sekvenční, protože mi běhá márz po zádech, že lovím nějaké paralelní chyby v informačním systému banky, které tam nasekal nějaký “programátor”, který se pokoušel optimalizovat na jádrový výkon 🙂
Jinak hezký výcuc z přednášky. A věz, že o tuhle krásnou možnost sledovat/poslouchat přednášky během žehlení nepřijdeš ani v budoucnu, i pleny se dají žehlit u přednášek… 🙂 (vyzkoušeno)
Maple: Právě proto, že lidi přemýšlejí sekvenčně, vznikl Erlang. General purpose jazyky jako Java mají přesně ten problém, že nutí programátora přemýšlet paralelně. Naproti tomu stojí ty specializované funkcionální jazyky, které člověku umožní paralelismus ignorovat. Možná že říkám to samé, co si napsal ty, ale z tvého příspěvku mi přišlo, že říkáš opak 🙂
No říkal jsem spíš opak 🙂 Erlang bohužel neznám. Nicméně, už to, že je funkcionální bude asi pro mnoho lidí překážkou 🙂
Já proti tomu nic nemám. V “běžných” aplikacích a “běžném” životě zatim vidím spíš problém programátorů než toho, že by chybělo pochopení jader pro jazyk. I to sekvenční programování je leckdy (pro někoho) zapeklité a složitost n ^ 3 nám nic neříká, out of memory řešíme přikoupením paměti a podobně… 🙁
Jinak kdo má půl hodinky nazbyt, doporučuju přečíst článek Functional Programming For The Rest of Us: http://www.defmacro.org/ramblings/fp.html
Je to fakt dobrý úvod do funkcionálních jazyků, a hlavně vysvětluje, proč jsou funkcionální jazyky v podstatě jediná možnost, jak stavět masivně paralelní systémy.
Musim souhlasit s autorem clanku. Objevil se dalsi zazrak pro zmenu s nazvem “Erlang” resici problemy paralelizace. Pro Javu nebo jako nadstavba vznika spousta kniven a reseni (paralelizace, GUI, …). Maji jeden zasadni problem – vzdy se narazi na jejich limity a kdyz je chcete skutecne vyuzit zjistite ze se musite podridit stejne jako v Jave nebo jinem programovacim jazyku. Vzdy se objevila bublina s nazvem Groovy, Scala, JavaFX ktera se nafoukne a pak zacne zit svym zivotem. Najde si sve privrzence a sve odpurce. Java se prosadila tim ze je univerzalnejsi nez ostatni. Pridanim concurent java zareagovala na nove technologie. Jenze jiz ted se vi ze implementace treba ConcurrentHashMap ma default limit maximalne do 16-32 threadu aby byla efektivni (necha se ridit parametrem).
Nejlepsi zpusob je asi se priblizovat malymi skoky a zkoumat co se osvedci toho se drzet. V soucasnosti je nejvetsi problem (alespon z meho hlediska) hojne vyuzivana synchronizace. Kdy se bloky navzajem blokuji a snizuji vykon systemu.
Na SW bude vzdy co vylepsovat a zalezi zejmena na programatorovi co umi a jak je sikovny pri reseni problemu.
Kdo neveri asi si prostuduje materialy o paralelnich systemech a algoritmech. Pak zjisti ze neexistuje lek co bi umel vse. Ani HW ani SW.
To bady: Dík za odkaz na super článek. Funkcionální programování vypadá zajímavě, ale docela bych se ho bál. Prostě už jsem si moc zvykl na objekty. Tady bych nevěděl, jak ten program rozčlenit. Připadá mi, že jde o krok zpět. Na druhou stranu je opravdu těžší ve funkcionálních programech udělat chybu. Jenom se bojím, že cena za to je moc vysoká.
Ten článek vypadá zajímavě, ještě na něj kouknu, i když nevím, jestli je v něm něco, co není v SICP 🙂
Každopádně mne zarazilo už tohle: … why they chose to use JMS instead of Erlang they’ll say they can’t use academic languages for industrial strength applications …
Každé malé děcko přece ví, že Erlang vymysleli u Ericssonu pro telekomunikační průmysl 🙂
“Každé malé děcko přece ví, že Erlang vymysleli u Ericssonu pro telekomunikační průmysl”
Však to tam taky píšou o pár paragrafů dál 😉 Myslím, že autor chtěl hlavně říct, že funkcionální jazyky mají stigma “akademických” jazyků, a proto je firmy šmahem odmítají pro komerční nasazení, aniž by vůbec věděly, o co jde.
Že bych také zkusil žehlit …
Jinak srovnávat actorový model posílání zpráv s JMS je podle mě jako srovnávat webové služby s voláním metod.
Řekl bych, že velkou chybu na nás zanechalo naše školství, protože nás nikdo funkcionální programování neučil a teď to musíme težko dohánět, umíme jenom imperativní přístup a vše ostatní nechápeme. Nemáte někdo typ na nějakou dobrou knihu o funkcionálním programování?
Jinak se obávám, že problém psát paralelní programy v Javě je, a řešení nebude jen tak, proč se objevují všechny ty event-oriented frameworky, které jsou přesně o tom. Zajímavé počtení http://www.ibm.com/developerworks/web/library/wa-aj-web2jee/
Takže to nakonec vypadá na to, že si nejsme jisti, že celé to objektově orientované programování byl dobrý nápad. I to je možné. Když se nad tím člověk tak zamyslí tak spousta doporučených návrhových vzorů a technik je skoro funkcionální (REST, JMS, DAO, Facade, Singleton, …). Obávám se, že to je natolik filozofická debata, že jsem příliš střízliv.
Ja bych ji uzavřel slovy pragmatika, jak kdy? A alespoň u mě je problém, že funkcionální programování neznám a proto, nedokážu poznat kdy je vhodné. Jít na všechno Javou, to je jako mít univerzální dopravní prostředek do vzduchu, na vodu a na silnici …