Java, Python, node.js, memcached – rychlost a pomalost

8.12.2013 13:48 | Přečteno: 4717× | Softwarové inženýrství | poslední úprava: 8.12.2013 14:15

Java je hrozně pomalá a těžkopádná, zejména ta EE (cokoli enterprise je navíc fuj), proto píšeme v Pythonu nebo v Node.js – to ví přece každý zkušený internetový diskutér. Dále víme, že SQL a XML jsou pomalé a proto si do aplikací přidáváme NoSQL databáze jako memcached – no přece aby to bylo rychlejší, to dá rozum. Navíc se zbavíme otravných datových typů a středníků na koncích řádků a náš program bude mnohem přehlednější a bude se lépe udržovat. Tak si pojďme něco vyzkoušet…

Inspirací k tomuto pokusu byl Mirecův zápisek Non blocking IO vs kooperatívny multitasking na webe, takže pokud jste ho ještě nečetli, přečtěte si ho.

Vsuvka: životní cyklus aplikace v Javě

Webové aplikace psané v Javě EE se liší od těch psaných na platformách jako PHP mj. svým životním cyklem – javovskou aplikaci nasadíme (deploy) na server a tam potom dlouhodobě žije – může si tedy držet stav a to na několika úrovních:

• aplikace – společný kontext pro všechny uživatele a požadavky
• relace – relace jednoho uživatele (typicky propojená přes cookies)
• požadavek – jeden HTTP požadavek/odpověď

(kromě toho tu máme další vychytávky jako EJBčka a jiné objekty, u kterých řídí vytváření a počet instancí kontejner, ale tím se teď zabývat nebudeme)

Díky tomu si informace o stavu můžeme držet na patřičné úrovni a nemusíme stav s každým HTTP požadavkem inicializovat a pak zase zahazovat. Díky tomu ani nepotřebujeme věci typu memcached – které jsou navíc pomalé, protože to znamená vyměňovat si data s jiným procesem, typicky pomocí TCP nebo UDP (byť v rámci localhostu) a provádět serializaci a deserializaci těchto dat. Místo toho pracujeme nativně s objekty našeho programovacího jazyka.

Navíc nemusíme řešit, zda se k memcached nepřipojí někdo cizí a nebude nám tam číst nebo dokonce zapisovat naše data. Smysl by to mělo jen tehdy, když bychom potřebovali sdílet data mezi více aplikacemi různých platforem – ale to není typický případ užití – většinou jde jen o workaround, který má vyřešit problém toho, že aplikace/platforma neumí sama držet stav a musí si ho někam externě uložit a pak zase načíst.

Náš servlet

Napsal jsem javovský servlet se stejnou funkcionalitou – posílá klientovi citát dne:

package cz.frantovo.blog.servlet;

import java.io.IOException;
import java.util.Collections;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * @author Ing. František Kučera (frantovo.cz)
 */
@WebServlet(name = "pokus", urlPatterns = {"/pokus/*"})
public class CitátDne extends HttpServlet {

	public static final String MSG_VAR = "msg_var";
	private final Map<String, String> citát = new ConcurrentHashMap<>();

	@Override
	public void init() throws ServletException {
		citát.put(MSG_VAR, "vyrok_2013-07-12");
		citát.put("vyrok_2013-07-12", "vyrok pre dnesok");
	}

	@Override
	protected void doGet(HttpServletRequest požadavek, HttpServletResponse odpověď) throws ServletException, IOException {
		String aktuálníKlíč = citát.get(MSG_VAR);
		String data = citát.get(aktuálníKlíč);
		odpověď.setContentType("text/plain");
		odpověď.getOutputStream().println(data);
	}
}

a pustil na něm test: ab -n 10000 -c 100 http://127.0.0.1:8080/pokus/

Concurrency Level:      100
Time taken for tests:   3.345 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2700000 bytes
HTML transferred:       180000 bytes
Requests per second:    2989.80 [#/sec] (mean)
Time per request:       33.447 [ms] (mean)
Time per request:       0.334 [ms] (mean, across all concurrent requests)
Transfer rate:          788.33 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   2.7      1      27
Processing:     5   31  11.0     30     100
Waiting:        2   30  10.8     29     100
Total:         12   33  10.2     32     100

Percentage of the requests served within a certain time (ms)
  50%     32
  66%     34
  75%     36
  80%     37
  90%     43
  95%     52
  98%     71
  99%     75
 100%    100 (longest request)

Zapomněl jsem do svého programu přidat nějaké kurvítko? Nebo mám o tolik rychlejší HW než Mirec?        

Anketa

Komentáře

[elemint]

Vypovídací hodnota vzhledem k odlišnému prostředí = 0.00

[xkucf03]

Jestli myslíš HW, tak to je virtuální server (KVM) s dvěma jádry a 2 GB RAM. Skutečný HW pod tím je Intel i7-920 Nehalem na 2.66 GHz z roku 2008.

[elemint]

Dokud vedle toho nespustíš Mirecův test, tak si tím můžeš tak akorát utřít, prostě to nemá žádnou vypovídající hodnotu.

[Mrkva]

Já to snad napíšu v C....

[xkucf03]

Napiš

(myslím to vážně, rád bych to viděl, jak z hlediska výkonu, tak čitelnosti a délky programu)

[Luk]

C nemusí být vždycky výhra, Java může být rychlejší.

[lister]

Když už někdo vkládá odkaz nebo citaci, tak bych očekával nějaký důkaz podporující tvrzení. Ale asi jsem příliš naivní.

Podle microbenchmarku na tom posledni verze implementace Javy od Oraclu je jenom cca 2x pomalejsi oproti GCC, ale v reálných aplikacích a javovských frameworcích se to moc neprojevuje. Pár diskusí jsem na tohle téma četl a podle všeho je důvodem dobrá optimalizace bytecodu a běhu v JVM u konstrukcí typu "tight loops", ale u víc strukturovaných a nehomogenních úseků kódu jsou ty výsledky podstatně horší.

Jako každej nástroj je to jen o vhodným použití. Nasazovat Javu na AAA herní tituly, kde záleží na každém fps je asi nesmysl. A není to jen o rychlosti běhu a paměťových nárocích, ale třeba i o dostupnosti knihoven nebo kvalifikované pracovní síly. Škoda že třeba za Haskellem nestála komerční síla jakou byl Sun, který javu do korporátní sféry tvrdě protlačil. Historii ale nezměním, přesto mi psaní javovských aplikací nepřestane připadat jako drbání se levou rukou za pravým uchem kolem celé hlavy

[mirec]

Neviem, či haskell by bol vhodný pre priemerných javistov. V každom prípade typový systém haskellu je jedna z najkrajších vecí, ktorá ma v IT stretla (a to počítam aj sekretárku od vedľa).

[lister]

Možná proto se protlačovala Java, protože je větší pravděpodobnost že ji zvládne i průměrný dělník - programátor. U Haskellu je potřeba uvažovat nad implementací víc dopředu a komplexně, možná proto je "odsouzený" pro horní menšinu

[xkucf03]

Možná proto se protlačovala Java, protože je větší pravděpodobnost že ji zvládne i průměrný dělník - programátor.

A o tom to právě je – cílem je dodat kvalitní software (splňující požadavky zákazníka) a vejít se při tom do rozpočtu a termínů. Ne si hrát na nějaké elitářské programování pro geniální programátory.

Java trefila ten správný poměr mezi možnostmi jazyka a jednoduchostí, proto je tak úspěšná – ne že by ji násilím někdo někam tlačil.

[lister]

Java trefila ten správný poměr mezi možnostmi jazyka a jednoduchostí, proto je tak úspěšná – ne že by ji násilím někdo někam tlačil.

Vzpomínám si celkem dobře na to množství konferencí, přednášek a školení (většinou vstup i raut grátis, pro IT manžery firem byly zdarma i letenky), reklam i placených článků v časopisech jako CHIP, Byte a dalších forem propagace, které musely stát nemalé prostředky. To rozhodně nebylo o skromné nabídce, po které jim trh urval ruce.

[Miloslav Ponkrác]

„Java trefila ten správný poměr mezi možnostmi jazyka a jednoduchostí, proto je tak úspěšná – ne že by ji násilím někdo někam tlačil.“

A ten neuvěřitelný a štědrý balík peněz, kterým byste umlátili velrybu a neustálý proud obrovských dolarů, které si běžný smrtelník ani neumí představit – od Suny pro protlačení Javy, to pomíjíte?

Kdyby se nacpalo tolik peněz do libovolného jazyka, jako se nacpalo do reklamy, propagace Javy, její protlačování na možná i nemožná místa, včetně evidentních lží velkého formátu, výsměchů jiným jazykům a nevím čeho – tak ten jiný jazyk už je dávno mainstream číslo jedna. Jen Java není tak dobrá, jako tvrdila reklama, ale i tak jsou těch mnoho miliard dolarů (a to jsem nemístně mnoho ubral) do její reklamy znát.

Takže Java byla tlačena násilím pomalu víc, než Brusel tlačí Evropskou unii.

Nejsme nejmladší a bylo to kolikrát až na zvracení, co Sun byl schopen všechno uplatit, aby protlačil Javu. A to velkou řadu let v kuse, v podstatě až do pádu Sunu.

Java je ohledně prosazení čistá korupce.

Píšu si: František Kučera strašně lže, když se mu to hodí. Protože napsat o Javě, že jí nikdo nikam netlačil, to chce totálního barona Prášila v extrémním vydání. Jen vrozená zdvořilost mi brání toto tvrzení neokomentovat značně šťavňatěji, protože toto chce totální ztrátu úsudku.

Miloslav Ponkrác

[xkucf03]

Byly a jsou tu i bohatší firmy než Sun (IBM, HP, Dell, Microsoft, Google…), vlastní jazyk mohl protlačit kdokoli z nich, ale kdyby nebyl tak dobrý jako Java, tak by mu sebelepší reklama nepomohla. Microsoft se zase snaží tlačit svůj .NET a jeho jazyky a jemu v tom pomáhá ještě obrovský vendor-lock-in z minulosti a rozsáhlá síť zkorumpovaných (nebo vydíraných) „subdodavatelů“ a politiků – a přesto se ty důležité věci píší v Javě a ne .NETu.

[Miloslav Ponkrác]

Ty jiné firmy neměly potřebu tlačit svůj vlastní jazyk. Tak to nedělaly.

Ostatně právě proto, že se nevyčerpávaly mnoha miliardami investic do tak nevýdělečné věci, jako je reklama a prosazování vlastního jazyka, proto ty firmy – na rozdíl od Sunu – dodnes existují.

V zásadě firmy, které svou existenci založily na prosazování vlastního jazyka – ty krachují.

Sun – Java.

Borland – Object Pascal.

Znovu, v Javě se píše, protože miliardy dolarů do reklamy mají svůj výsledek.

Můžete tvrdit co chcete, ale Java by se neprosadila nikdy, nebýt těch mnoha miliard Sunu.

A tím končím. Váš matrix a vaše růžové vidění o tom, jak se Java prosadila bez násilného cpaní a protlačování a bez reklamy jsou jen lhaní si do vlastní kapsy.

[xkucf03]

Ještě k tomu lhaní – neříkal jsem, že Sun neinvestoval do reklamy, ale že Java je úspěšná díky svým vlastnostem, ne díky reklamě – kdyby ten správný poměr možností a jednoduchosti neměla, tak se ani s tou reklamou neujme.

[Miloslav Ponkrác]

Díky reklamě se ujaly i větší sračky, než je Java. Miliardy nacpané do reklamy těžko zůstanou bez odezvy.

[Miloslav Ponkrác]

Já zase tvrdím, že Java je úspěšná z 99,9 % kvůli reklamě a prachům do reklamy. Ne kvůli svým vlastnostem.

[JS1]

U Haskellu je potřeba uvažovat nad implementací víc dopředu a komplexně

I kdyz se mi Haskell celkem libi (jako matematicky konstrukt, ne jako jazyk na programovani), nejsem si jisty, ze je to az takova vyhoda.

Jazyk je nastroj, takove GUI pro programatora. Cim vic se plete do cesty normalni praci, tim hur. Pokud musim vic uvazovat pri jeho pouzivani, zbyde mi mene cyklu na uvazovani nad resenou ulohou.

[lister]

Pokud musim vic uvazovat pri jeho pouzivani, zbyde mi mene cyklu na uvazovani nad resenou ulohou.

To je možný dojem, daný zřejmě neznalostí. Ve skutečnosti to naopak obvykle čas ušetří, když induktivní řešení může vést do slepé uličky a zpětně se kód opravuje a přepisuje. V haskellu ta deklarativnost a typový systém nutí napsat to rovnou správně, jen je nutné si to v hlavě nejdřív urovnat

[JS1]

Ve skutečnosti to naopak obvykle čas ušetří, když induktivní řešení může vést do slepé uličky a zpětně se kód opravuje a přepisuje.

Mas na to nejakou studii, nebo je to jen zase dalsi pocit? Ja bych rekl, ze zrada je prave v tom "mozna". Mozna se dostanes do slepe ulicky, a mozna to bude pro danou aplikaci stacit. Software se prepisuje co chvili a predstava, ze neco napises napoprve spravne, zda se mi spise scestna, prestoze bych ji sam tak rad veril!

(A mimochodem, co je vlastne spravne?)

Elegance Haskellu se mi libi, ale nekdy je to holt pres ruku. Stejne tak, psat programy v dostatecne silnem typovem systemu v podstate znamena psat je dvakrat. Opravdu bychom je nemohli psat jen jednou? O jazyce, ktery ma (silne) typy jen uplne minimalne, chci o tom napsat svuj druhy blogpost, btw, ale zatim to nemam moc rozmyslene.

Libi se mi pristup Paula Grahama - programovaci jazyk by mel poskytovat dostatecnou tvarnost na to, aby se v nem dalo experimentovat s prototypem, a teprve pozdeji ten vysledek "nechat ztuhnout" do konkretnejsi a efektivnejsi podoby. Hypoteticky jazyk, o kterem jsem psal ve svem prvnim blogpostu, se o tohle pokousi take.

Nicmene, jak pisu niz, typovy system neni to, co mi na Haskellu vadi asi nejvic. Haskell beru jako urcity, velice zajimavy pokus. Ale jako smer.. asi uplne ne.

[xkucf03]

Opravdu bychom je nemohli psat jen jednou?

A který z těch dvou konců by měl být primární a který z něj odvozený? A co když budu potřebovat zorganizovat práci v týmu tak, že nejdřív se bude dělat ta odvozená část programu a pak teprve ta, ve které se měly definovat typy? A co programování stylem kdy jeden navrhne rozhraní (nebo napíše kostru třídy se signaturami metod) a další doplní ten zbytek?

To „psát dvakrát“ může vypadat hloupě, ale myslím, že někdy to může práci i šetřit. Navíc nemusí to být dvakrát to samé – na jednom konci můžou být konkrétnější typy a na druhém obecnější.

Rozumný kompromis podle mého je na rozhraních metod/funkcí deklarovat typy pořádně a uvnitř mít možnost typy odvozovat + k tomu mít slušné IDE, které mi hned ukáže typ. Tzn. mít možnost napsat uvnitř metody.

var proměnná1 = new Třída();
var proměnná2 = "ahoj";

nebo alespoň:

Map<Integer,String> mapa = new HashMap<>(); // místo new HashMap<Integer,String>();

[JS1]

A který z těch dvou konců by měl být primární a který z něj odvozený?

Existuje ona Curry-Howard korespondence, o ktere tu tak pekne psal Radek Micek, takze na tehle urovni je to asi jako ptat se, kterou stranou si navlect tkanicku do bot.

Z dostatecne silneho typoveho systemu lze chovani programu odvodit. Ze ho nemate, nu, to je jiny problem. Pak se to samozrejme nepise uplne dvakrat, moje tvrzeni odkazuje prave na tuto extremni situaci. (Stejne tak si myslim, ze automaticke testovani znamena napsat program dvakrat, ale to je na jinou diskusi.)

A co když budu potřebovat zorganizovat práci v týmu tak, že nejdřív se bude dělat ta odvozená část programu a pak teprve ta, ve které se měly definovat typy? A co programování stylem kdy jeden navrhne rozhraní (nebo napíše kostru třídy se signaturami metod) a další doplní ten zbytek?

Oboji mi zni jako recept na prusvih. Ale proti gustu.. (A dikybohu delam ve firme, ktera to druhe nepraktikuje.)

Jinak pro poradek - adhoc typy neznamenaji, ze typy nejsou. Jen se nezapisuji. Ale porad se na nich musite nejak dohodnout. Samozrejme, musite vedet, s jakymi daty pracujete. Jen tomu nedavate nazev, to je cele.

To „psát dvakrát“ může vypadat hloupě, ale myslím, že někdy to může práci i šetřit. Navíc nemusí to být dvakrát to samé – na jednom konci můžou být konkrétnější typy a na druhém obecnější.

Na tohle uz jsem myslim reagoval.

Rikam, chci o tom napsat blogpost, eventualne.

[Josef Kufner]

Jak chceš vytvářet velké věci, kdy jeden člověk nemá šanci stihnout udělat obě strany rozhranní? Tedy dělá věc, která má něco používat, ví jaký interface by ta věc měla mít, ale samotné vytvoření je nutné delegovat na jiného člověka?

[xkucf03]

Jak chceš vytvářet velké věci, kdy jeden člověk nemá šanci stihnout udělat obě strany rozhranní?

O tom to je – odvozování je IMHO výhodné jen někdy.

• jeden soubor nebo lépe vnitřek jedné metody psaný jedním člověkem
• jeden projekt psaný jedním člověkem
• software psaný jedním týmem a celý verzovaný v jednom systému (jednom úložišti)
• software nebo části systému vytvářené více týmy, verzované v oddělených úložištích, kompilované každé zvlášť
• totéž vyvíjené v různých firmách/organizacích, které o sobě navzájem ani nevědí

V prvním případě ano – zatímco v posledním vůbec. Tam je potřeba mít předem dohodnutá rozhraní a poctivě deklarovat typy – i za cenu toho, že se budou psát 2× nebo 3×. Odvozovat se pak dá od toho rozhraní – v rámci dané komponenty nebo metody/funkce.

[JS1]

Velke veci - proste se to rozdeli jinak. Rozhrani modulu jsou dobra vec, ale aby jeden psal signatury metod a druhy implementaci je hloupy micromanagement.

Asi me tu za to lide nebudou mit radi, ale koukal jsem na prednasku "What we really know about SW development" - rika tam mimo jine, ze projekty proste maji tolik modu u, kolik je autoru. Mozna bychom se tomu nemuseli snazit branit a vzit to jako prirozeny stav, a delit praci podle toho.

[xkucf03]

Jinak pro poradek - adhoc typy neznamenaji, ze typy nejsou. Jen se nezapisuji.

Vím, viz ten můj příklad var proměnná1 = … – myslíš to takhle, ne? Proměnná má typ, i když jsem ho tam explicitně nezapsal.

Ale porad se na nich musite nejak dohodnout. Samozrejme, musite vedet, s jakymi daty pracujete. Jen tomu nedavate nazev, to je cele.

A ta dohoda typicky vypadá tak, že deklaruji, jaké typy očekávám na vstupu a jaké mohou ostatní očekávat na výstupu. Dá se samozřejmě říct: „na vstupu očekávám to, co leze z tamhleté části programu“ – jenže co když právě „tamhleta část“ ještě neexistuje, ještě ji nikdo nenapsal a já teď chci dělat na téhle části, která by z té neexistující měla být teoreticky odvozená?

Odvozování typů používám např. v SQL – když dělám funkci, která má pracovat s daty z určité tabulky, tak tam nepíšu např. INTEGER ale tabulka.sloupeček%TYPE. Jenže tady mám jistotu, že vždycky budu mít nejdřív tabulky a pak teprve budu dělat funkce – je jasné, co se má z čeho odvozovat.

Dovedu si ale představit situaci, že tabulky ještě nemám hotové nebo nemám úplně jasno o datových typech (vím, že to bude číslo, ale nevím např. jaké) nebo se např. můžou ještě přejmenovat tabulky a sloupečky… a budu chtít někomu zadat práci „napiš funkci, která počítá to a to“ – aby na tom mohl dělat už teď a nemusel čekat, až budou hotové tabulky. Tak mu buď pošlu kostru té tabulky (kde bude třeba jen ten jeden sloupeček, který ho zajímá), aby z ní mohl odvodit ten typ, nebo mu zadám dostatečně obecné¹ typy, aby to nakonec na výslednou tabulku pasovalo. A můžeme dospět i k tomu, že ta jeho funkce nebude použitelná jen s tou mojí tabulkou, ale bude univerzálnější, znovupoužitelnější. A to je přesně ten případ, kdy na jednom konci máme konkrétnější typy a na druhém obecnější – nejsou od sebe odvozené.

P.S. Šikovné by mi přišlo něco jako „typedef“ – vlastní pojmenování typů, které odráží sémantiku, a pak vůbec nepoužívat primitivní datové typy, ale jen ty vlastní pojmenované – a kompilátor by pak kontroloval, jestli sedí i ta sémantika (ne jen ten skutečný typ pod tím).

_{[1] což je jednoduché u vstupů funkce – u výstupu je to horší}

[JS1]

Vím, viz ten můj příklad var proměnná1 = … – myslíš to takhle, ne? Proměnná má typ, i když jsem ho tam explicitně nezapsal.

Nejsem si ted uplne jisty - zalezi od semantiky. Charakteristickym rysem dynamickeho typovani je fakt, ze hodnoty maji typy, ale nikoli promenne. Takze pokud to var znamena jen "odvod zde typovou signaturu, jsem liny se s tim psat", pak je to neco jineho, nez dynamicke typovani (a neco jineho nez mam na mysli ja, coz je v podstate dynamicke typovani dovedene jeste trochu dal).

Šikovné by mi přišlo něco jako „typedef“ – vlastní pojmenování typů, které odráží sémantiku, a pak vůbec nepoužívat primitivní datové typy, ale jen ty vlastní pojmenované – a kompilátor by pak kontroloval, jestli sedí i ta sémantika (ne jen ten skutečný typ pod tím).

To je sice teoreticky hezke, ale neresi to ten zakladni problem. Ten spociva v tom, ze cim explicitnejsi typy jsou, tim vic kontrol dostanes, ale na druhou stranu to znamena mensi flexibilitu (a vetsi sance, ze se to bude muset predelavat). Muj jazyk se snazi oddelit obe veci (flexibilitu jako default, kontroly do anotaci) a tim vyresit toto dilema.

Tohle vsechno podrobneji rozeberu ve svem blogpostu - stay tuned.

[Josef Kufner]

Největším přínosem deklarování proměnných je detekce překlepů a možnost definování jejich viditelnosti (scope). Docela mi to v PHP chybí, tam se jen ohlašuje čtení neinicializovaný proměnných.

Samotné typy jsou často víc nutné pro překladač než užitečné pro programátora. Alespoň v současných mainstreamových jazycích.

[xkucf03]

Největším přínosem deklarování proměnných je detekce překlepů a možnost definování jejich viditelnosti (scope).

Souhlas. Ale na to by mohl stačit ten var proměnná = …, kde se ten typ odvodí z hodnoty. Ale přiznám se, že i v rámci těla metody deklaruji někdy jiný (obecnější) typ, než jaký má hodnota.

[Josef Kufner]

Však jo, var na tohle bohatě stačí.

[JS1]

Neboli: detekujes preklepy tim, ze to efektivne zapisujes dvakrat (nebo ne docela dvakrat, ale proste dodavas dodatecnou informaci, z ktere se usoudi, ze jde o preklep - neco jako redundantni kod). Rekl bych, ze existuji i efektivnejsi metody detekce preklepu..

Samozrejme, ze typy jsou v mainstreamovych jazycich nutne, protoze, jak uz jsem rekl, tam maji typ promenne, a pak se tomu nevyhnes. Coz je ovsem dle meho soudu spatny pristup.

[JS1]

Myslim, ze i kdyby za Haskellem stala komercni sila, tak ho neprosadi - ono totiz jak Java, tak C++, tak i C# bylo na zacatku prodavane jako "velmi jednoduchy jazyk, podobny tomu co uz mate", a ta slozitost a odlisnost prisla az mnohem pozdeji. To uz mel vetsi sanci Common Lisp v dobach sve nejvetsi komercni slavy.

Jinak i Haskell ma sva proti..

[lister]

Mě je celkem jasné, proč by ho bylo těžké prosadit. Dokonce i dnes, kdy je čím dál větší tlak na paralelní zpracování, které je v něm tak relativně snadné oproti těm rozšířenějším imperativním jazykům. Spíš to byl povzdech, jak by to bylo fajn, kdyby to bylo obráceně. Když něco dělám v jazyku a prostředí a zároveň vím, že v jiném by to šlo daleko elegantněji, ale nikdo mi za to nezaplatí :-/

[lister]

Jinak i Haskell ma sva proti..

Jistě, ale kromě nároků na IQ programátora a vyzrálost některých knihoven jich moc neshledávám, ale třeba mám jen malou představivost No možná ještě vynucování líného vyhodnocování a deaktivace GC pro specifické případy.

[JS1]

Line vyhodnocovani je spis plus, i kdyz muze to prinest ruzne zrady.

Ale problem vidim prave v tech monadach. Prijde mi, ze rozbijeji modularitu. Ptal jsem se na to HN a nemyslim, ze jsem dostal rozumnou odpoved. Muzes zkusit reagovat na me argumenty sam. (Nikdy jsem v tom velky program nepsal. Jen rikam, jak mi to pripada.)

Proste, jestli je to budoucnost programovani, tak to potes.. Citim se byt pragmatikem, nemyslim, ze je jeden spravny zpusob, jak programovat (at uz OOP nebo funkcionalni). K tomu mi otevrela oci zejmena knizka On Lisp.

[x]

Ale problem vidim prave v tech monadach. Prijde mi, ze rozbijeji modularitu.

Někteří jdou ještě dál: http://gbracha.blogspot.cz/2011/06/types-are-anti-modular.html

[JS1]

Ano, to jsem cetl. Do jiste miry s tim i souhlasim (nebo to mozna ovlivnilo muj nazor), a proto jsem zastancem adhoc polymorfismu.

[Miloslav Ponkrác]

„Myslim, ze i kdyby za Haskellem stala komercni sila, tak ho neprosadi - ono totiz jak Java, tak C++, tak i C# bylo na zacatku prodavane jako "velmi jednoduchy jazyk, podobny tomu co uz mate", a ta slozitost a odlisnost prisla az mnohem pozdeji. To uz mel vetsi sanci Common Lisp v dobach sve nejvetsi komercni slavy.“

Java se prosadila silou mnoha miliard dolarů, které tam nalil Sun.

Navíc je otázkou, co se s Javou v delší budoucnosti stane, protože Oracle.

C++ se prosadil jako jazyk, který neměl a dodnes nemá v určitých oblastech konkurenci, není takový jazyk s takovými vlasnostmi. Proto se začal lavinovitě šířit, a to i přesto, že propagace byla malá. A od začátku se proti němu spíše štvalo, jednak z unixové komunity, jednak Sun šířil proti němu nenávistné pomluvy. Ale jednoduše jsou niky, kde nic jiného, než C++ rozumně použít nejde.

C# je jazyk, který v zásadě časem IMHO zhasne. Je protlačován MS jako základní jazyk .NETu.

Haskell, stejně jako jakýkoli jiný funkcionální jazyk, nemá šanci se v této době masově prosadit. Doba si žádá blbé jazyky a hloupé jazyky, které zvládne za dopoledne i retardovaná přeučená uklízečka. Funkcionální jazyky to rozhodně nesplňují. Právě tento požadavek na vykostěnost jazyka vyzvedl trochu Javu. Aby jí pak později zatlačil zpět spíše do enterprise, byť ne výhradně.

To znamená dnes se může prosadit pouze jazyk, který 1) je buď pro určitou niku nenahraditelný a extrémně vhodný, nebo jazyk, 2) který je až blbě vykostěný, že nic neumí, nebo jazyk, 3) který má miliardy na propagaci. V Javě se sešel 2. a 3. bod. V C# mnohem méně také 2. a 3. bod. V C++ se sešel 1. bod.

[Josef Kufner]

Haskell, stejně jako jakýkoli jiný funkcionální jazyk, nemá šanci se v této době masově prosadit.

Například Javascript. Kdyby i Haskell měl kudrnaté závorky, tak už se dávno prosadil.

[JS1]

JS je myslim hezky protipriklad nazoru pana Ponkrace o tom, ze za rozsirenim Javy muze primarne propaganda. Myslim, ze to tak uplne neni, a ze Java mela znacne vyhody, i pres radu nevyhod.

[Samo]

Dávat JS jako příklad funkcionálního jazyka a dokonce srovnávat s haskellem je nesmysl. Jistě, obsahuje prvky vlastní funkcionálním jazykům jako funkce první třídy nebo uzávěry, ale to z něj ještě představitele funkcionální paradigmatu nedělá. Naopak, v JS se píše převážně imperativně, mění stav i v globálním prostoru, nedodržuje referenční transparentnost, postrádá částečnou aplikaci atd.

[JS1]

Dávat JS jako příklad funkcionálního jazyka a dokonce srovnávat s haskellem je nesmysl.

Ale to prece nedelam. Ja mluvil zcela jasne o tom, ze je to protipriklad teorii o rozsireni jazyka v dusledku propagandy. O tom jestli je funkcionalni nebyla vubec rec.

[Samo]

To byla síš reakce tohle vlákno, ktere odstartoval p. Ponkrác názorem, že Doba si žádá blbé jazyky a hloupé jazyky, které zvládne za dopoledne i retardovaná přeučená uklízečka. Funkcionální jazyky to rozhodně nesplňují. a přímé reakce p. Kufnera. Zamotal jste do toho otázku propagace, ale to není moje odchýlení od tématu. Mimochodem dávat jako argument rozšířenost Javascriptu a posuzovat to izolovaně jen s ohledem na objem investic do marketingu a nebrat v úvahu historické okolnosti jako podobost s tehdy nejrozšířenějším C nebo zadrátováním do Netscapu je přinejmenším nefér. V té době moc na výběr pro aktivní webový obsah nebylo a pomohl tomu i Microsoft, když ho akceptoval a stal se tak po celou dobu součástí dominantního prohlížeče.

A že je javascript zvládnutelnější pro cvičenou opici než funkcionální jazyky by jen potvrdilo tezi p. Ponkráce a že to mělo vliv na jeho popularitu.

[JS1]

Ok, pak jste to mel ale napsat pod jeho reakci, pokud jste se nechtel odchylit. Nevim, proc to svadite na me.

Jinak Java mela podobnou vyhodu jako Javascript - take byla podobna C a take se prosazovala pro webovy obsah.

Jinak trochu pochybuji, ze Javascript je jednodussi jazyk nez funkcionalni programovani (asi by to chtelo nejak dolozit - myslim, ze jsem nekde videl studii, ktera ukazovala, ze funkcionalni pristup je jednodussi na pochopeni pro neprogramatory). To jen zastanci funkcionalniho programovani si trochu lzou do kapsy, kdyz o tech prekomplikovanych vecech (monady) rikaji, ze je to vlastne lepsi, i kdyz neni.

[Michal Vyskočil]

Škoda že třeba za Haskellem nestála komerční síla jakou byl Sun, který javu do korporátní sféry tvrdě protlačil.

Simon Peyton-Jones adding the IO Monad to Haskell - ne, že bych něco proti Haskellu měl, chraň bůh, ale drtivá většina programů je o IO, takže ani Sun blahé paměti, by si na Haskellu vylámal zuby.

[lister]

Do standardu Haskell byla přidána IO monáda v roce '95, což je +/- v době vzniku Javy. Faktem je, že ultimátní implementace GHC vyzrála až o cca dekádu později.
Je to takový Urban myth™, že haskell má slabinu v IO. Opak je pravdou, programování a oddělení IO kódu od zbytku funkcionálního kódu je luxus a komfort, kterého se obtížně zříká v jiných jazycích. GtkHS vs. nativní C knihovny budiž příkladem.

Btw. haskell se stále učím, živí mě ruby/rails/python/django/numpy/C. Jen vidím ten obrovský potenciál, který v sobě jak jazyk (Haskell98, Haskell2010), tak špičková implementace GHC skrývá. Bez ohledu na rozšířenost a bandwagon-bias.

[JS1]

Jen vidím ten obrovský potenciál, který v sobě jak jazyk (Haskell98, Haskell2010), tak špičková implementace GHC skrývá.

Potencial tam jiste je, ale ma jeden velky hacek, a to je ten, ze staticka analyza ma svoje limity. Napr. nepocita s tim, na jaka data aplikaci realne pustite. Pozadavky se muzou menit s zivotem aplikace.. bude nekdo ochoten prepisovat typove signatury? Proto staticke typove systemy - podle meho nazoru - nejsou a nebudou konecne slovo. Leda ze bys vsechno stavel na typovych tridach, ale i to ma sva proti.

Jinak taky pises o paralelnich aplikacich. Prijde mi, ze realne aplikace se paralelizuji jen dost obtizne, a ty casti, kde to jde dobre, se vetsinou schovavaji do knihoven, u kterych uz si nekdo tu praci dal. Takze je otazka, jestli jsou "lepsi paralelni primitivy" skutecne az takove lakadlo.

[Luk]

Když už někdo vkládá odkaz nebo citaci, tak bych očekával nějaký důkaz podporující tvrzení. Ale asi jsem příliš naivní.

Vložil jsem odkaz na svůj mnoho let starý blogpost, kde ten důkaz je. A netvrdil jsem nic o reálných aplikacích ani javových frameworcích.

[Martin Mareš]

Jen odkaz na testovací programy nikam nevede, takže těžko posoudit, jaký ten test dával smysl.

[Luk]

Ty testovací programy jsou bohužel pryč, nikde je nemám. Ale v textu je poměrně podrobně popsáno, co dělaly, takže to nevidím jako zásadní problém.

[Jardík]

Z nedávna stejná zkušenost. Napsal jsem si CRC, parametrické. Nejdříve v D, kde jsem použil šablony a věci typu "static if", kde to šlo. Výsledek při 5000000 update() volání nad 256B polem jsem dopadl nejdříve 11s. Kód je tu. Nad tím jsem provedl stupidní úpravy typu, že před cyklem uložím členskou proměnnou do lokální a po cyklu zpět. D je tak hloupé, že to vůbec nezoptimalizuje a pokaždé šahá do paměti tam a zpět. Po té úpravě jsem se dostal na 6s. Pak sem posun a xor rozdělil na dva řádky, abych mu poradil, jak nějak by to šlo zoptimalizovat, protože generoval prasárnu. Bum a mám 5s. Pak jsem místo DMD zkusil LDC a mám 4.2s. ("dmd -O -release" a "ldc2 -O2", dmd nemá -O2)

Pak jsem to splácal do C++, opět parametry je známo během kompilace, takže kód by měl vylézt hezký... GCC s O2 a unroll loop 4.8s, clang - stejné parametry - 4.2s. Tady je vidět, že LDC i CLANG generují více méně stejně díky llvm.

Další pokusy v C# a javě. V obou je skoro stejný parametrický kód, oproti D a C jsou tam virtuální fce, pro "šablony" nelze používat číselné parametry, takže jsou známy až za běhu. JIT v javě docela hezky zoptimalizoval, dostávám se 3.8-4s, jak kdy. Za to mono je docela katastrofa, nejprve s 12s, po stejném hacku jako v D jsem se dostal na 7.2s, mono moc dobře neoptimalizuje.

[pavlix]

C nemusí být vždycky výhra, Java může být rychlejší.

A já si vždycky myslel, že Java nemůže být rychlejší než C, když je v C. Tím samozřejmě nemám namysli, že by jednotlivý program rychlejší být nemohl, když se v C udělá dostatečně pomalý.

[fubar]

A může jeden překladač Céčka generovat rychlejší kód než jiný překladač Céčka?

[pavlix]

Jistě. Lze z toho odvodit, že céčko je rychlejší než céčko a se vší vážností to prezentovat jako převratný fakt?

[Luk]

Rozdíl není v jazycích jako takových. Rozdíl je v tom, že u C se obvykle používá statický kompilátor (který to zkompiluje jednou a udělá jen optimalizace na základě poskytnutých parametrů; nadměrná "optimalizace" může ve skutečnosti rychlosti snížit), kdežto u Javy se kompiluje z bytecode do strojového kódu dynamicky až na konkrétním stroji a lze tedy optimalizovat dynamicky, v závislosti na daném stroji.

[pavlix]

nadměrná "optimalizace" může ve skutečnosti rychlosti snížit)

Vidím, že si hraješ s pojmy jak s legem, ta nadměrná optimalizace se mi moc líbí.

kdežto u Javy se kompiluje z bytecode do strojového kódu dynamicky až na konkrétním stroji a lze tedy optimalizovat dynamicky, v závislosti na daném stroji.

Tenhle argument se docela hojně používal pro buildování na konkrétní stroj na Gentoo. Změny v rychlosti se ovšem obvykle neukazovaly jako závratné, až na nějaké speciální úlohy. To je ovšem spíše dané tím, co se na ty počítače distribuuje, zda zdrojový kód, bajtkód nebo architekturně závislý kód.

[xkucf03]

Ono nejde jen o konkrétní stroj/CPU, ale o to, že JIT má k dispozici data, která proudí skrze program (množství, četnosti…). Někdy proto můžeš pozorovat zrychlení po určité době běhu programu.

[pavlix]

Jsem si toho vědom, i když to Luk nezmínil. To dává této technice šanci být ve speciálních případech rychlejší než statický program. Otázkou je, zda je to dobrý podklad pro tvrzení:

C nemusí být vždycky výhra, Java může být rychlejší.

Lze vycházet z toho, že obvyklé užití C je kompilace do statického programu. Naproti tomu asi nebudeš chtít postavit to, že při obvyklém užití je Java oproti C nehorázně pomalá.

Tedy přijdeš s nápadem, že při velmi speciálním užití a za patřičné opatrnosti by teoreticky mohlo dojít k tomu, že bude javovský program díky JITu rychlejší než odpovídající program v C. A teď pokud se budeš pohybovat na čistě teoretické rovině, tak stejně musí přijít ten argument, že k JIT ve skutečnosti Javu nepotřebuješ.

No a pokud se vrátíš na zem a budeš chtít argumentovat běžnou praxí namísto teoretických konstrukcí, tak bys musel přijít s nějakou třídou běžně řešených úloh, kde se overhead Javy neprojeví a naopak ho přebije JIT. A na to bych byl docela dost zvědavý.

[Michal Vyskočil]

Ono to není černobílé - JIT sice (teoreticky) dokáže optimalizovat až dřeň pomocí analýzy dat, nicméně samotná kompilace, profiling a všechny věci kolem nejsou zadarmo, čili stojí spoustu času CPU a nakonec i paměti. Například pypy ve 2.0 zrychlilo dlouho běžící programy prostě tak, že se JIT týká mnohem méně kódu, než předtím. Nebo třeba Android ART.

[Luk]

Vidím, že si hraješ s pojmy jak s legem, ta nadměrná optimalizace se mi moc líbí.

Tady jsem to zjednodušil, ale v tom blogpostu to popisuji přesně - tedy ve smyslu zapnutí optimalizací v GCC (nejhorší výsledky byly pro -O3).

[Miloslav Ponkrác]

Už delší dobu pozoruji, že mnoho jedinců zaměňuje termín „jazyk C“ a „GCC kompilátor“.

Dělají závěry pro GCC kompilátor, ale z nějakého neznámého důvodu, který mi dosud ušel, tvrdí, že to platí pro celý „jazyk C“.

A zrovna tady na abclinuxu je záměna kompilátoru s jazykem neuvěřitelně častá.

[Agent]

Je to podobné, jako se zcela běžně zaměňují termíny kodek, formát, typ komprese. Každý říká "mám to v Divxu" i když je to nesmysl. Ale všichni tomu rozumí (doufám), tak vo co go?

[pavlix]

Erm, zjednodušil, budu hodný a nebudu na to více reagovat.

[Miloslav Ponkrác]

„C nemusí být vždycky výhra, Java může být rychlejší.“

Pokud je Java rychlejší než C znamená to jediné: Mizerný C programátor.

S dobrým C programátorem to Java nikdy rychlostně vyhrát nemůže.

Miloslav Ponkrác

[xkucf03]

Stejně jako C nemůže nikdy rychlostně vyhrát nad dobrým programátorem v assembleru, ne?

[Miloslav Ponkrác]

„Stejně jako C nemůže nikdy rychlostně vyhrát nad dobrým programátorem v assembleru, ne?“

To už musí být sakra dobrý programátor v asm, a navíc musí mít velmi mnoho času.

Navíc se naráží na limity mozku v množství zapamatovaných identifikátorů a vazeb (pro běžnou velikost programů), se kterými se soupeří s optimalizátorem kompilátoru C, kterému je množství optimalizovaných entit v zásadě jedno.

Ale teoreticky to tak je.

[pavlix]

Transport Tycoon a jeho mladší bratříček...

[Miloslav Ponkrác]

Rok 1994 je středověk. Pochopte, že za 20 let se toho v počítačích událo velmi mnoho.

[pavlix]

To asi nebyla úplně reakce k tématu, že?

[Kvakor]

Tipuju na výkon zhruba stejný (většinu výkonu stejně sežere režie navazování spojení), čitelnost horší a délka o dost větší (BSD sokety v C jsou docela hustá magie), leda že by se použila nějaká už hotová zjednodušovací knihovna (ale o takových nemám přehled, nepoužívám je). Nicméně by existoval zásadní rozdíl ve spotřebě paměti, ale ten by měl smysl jen na embedded systémech nebo někde, kde je paměti málo.

[Miloslav Ponkrác]

BSD sokety v C nejsou nijak šílené. Ani nečitelné.

Jsou daleko horší věci.

V BSD soketech pod C/C++ jsem několikrát psal přímo – i když pravda, nikdy jsem si to nezvolil dobrovolně, ale bylo mi to nařízeno.

Ale rozhraní BSD soketů je přímočaré a nijak komplikované.

[Kvakor]

Neříkám, že jsou šílené, jsou jen poněkud komplikovanější během inicilalizace (ve srovnání např. se soubory), kdy se musí vhodně naplnit příslušné struktury a zavolat příslušná volání, ale jak se dostane výsledný deskriptor otevřeného TCP soketu, tak už je to jednoduchá záležitost, která se moc neliší např. od práce se souborem nebo rourou (tedy až na to, že narozdíl od roury je soket obousměrný). Kdfyž už něco šíleného, tak například komunikace s ovladači skrz ioctl() . A zhoršená čitelnost (ve srovnání s Javou) je hlavně v důsledku nutnosti explicitní kontroly na všemožné chyby (u věcí komunikujícíh s vnějším světem nutnost), nicméně pokud je to napsané dobře, tak to o tolik horší není.

[pavlix]

Inicializace je daná jednak tím, že resolving síťových jmen je řádově komplikovanější a nepodařilo se na něj standardizovat vhodné API, jednak tím, že je potřeba podporovat i connection-less protokoly jako je UDP a nakonec tím, že je potřeba podporovat listening sockety ze kterých se odvozují sockety serverových spojení.

[pavlix]

BSD sockety jsou easy, potřebuješ jen žít s tím, že máš přístup k holému read() a write().

Pokud jde o proces, který vede k tomu, že dostaneš správně nakonfigurovaný TCP/UDP socket, tak tomu se snažím pomoct mimo jiné i knihovnou uvedenou v patičce.

[Josef Kufner]

Od holého read() a write() se lze snadno vzdálit zavoláním fdopen() po inicializaci socketu.

[pavlix]

Spíš jsem tím chtěl říct, že to není zase ta strašné. Já osobně nemám ANSI IO moc rád. Vnímám je jako takového chudého bratránka těch POSIXových.

[mirec]

A jeje tak niekto je tu expert na výkon. Tak teda OK, v tomto prípade sa vôbec nekontaktuje memcached čo bolo vlastne nosnou časťou môjho blogu. Takže keď už sme teda pri porovnávaní penisu ... môj stroj je staručký thinkpad R61i s core2duo.

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 Duo CPU     T5250  @ 1.50GHz
stepping	: 13
microcode	: 0xa3
cpu MHz		: 1000.000
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm
bogomips	: 2993.06
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Takže som podľa vzoru javy vyhodil memcached a pekne krásne si čítam lokálnu premennú aby to bolo spravodlivé a po vzore javy som zapol jit kompilátor čím som dosiahol 5-20 násobný výkon (podľa druhu úlohy).

Requests per second:    3976.82 [#/sec] (mean)
Time per request:       25.146 [ms] (mean)
Time per request:       0.251 [ms] (mean, across all concurrent requests)
Transfer rate:          454.38 [Kbytes/sec] received

A ešte zodpovedajúci python kód:

from eventlet import wsgi
import eventlet

MSG_VAR = "msg_var"
citat = {MSG_VAR: "vyrok_2013-07-12", "vyrok_2013-07-12": "vyrok pre dnesok"}

def application(environ, start_response):
	start_response("200 OK", [('Content-Type', 'text/plain')])
	yield citat[citat[MSG_VAR]]

wsgi.server(eventlet.listen(('127.0.0.1', 8888)), application, debug=False)

[xkucf03]

Pointa byla v tom, že memcached se často používá jako nouzové řešení v případech, kdy aplikace nedokáže držet stavové informace – typicky v PHP. Z principu je to ale neefektivní řešení protože data je potřeba serializovat/deserializovat a předávat si je s jiným procesem přes TCP soket.

Když už chci držet data v RAM, tak je můžu mít v tom samém procesu a jako objekty daného programovacího jazyka, včetně pohodlí datových typů. Držet je v jiném procesu a přistupovat k nim přes síť dává smysl, když s tím chci pracovat z víc aplikací současně (což ale není typické – většinou jde o cache pro jednu aplikaci).

Konkrétní čísla se těžko porovnávají, v tvém programu zase nevidím žádné směrování podle URL¹ na jednotlivé „servlety“² a další věci.

_{[1] asi to posílá na libovolný požadavek pořád tu samou odpověď – v té Javě je to řešené přes anotace (@WebServlet(urlPatterns = {"/pokus/*"})) nebo web.xml
[2] nevím, jak se tomu říká v Pythonu}

[mirec]

import tornado.ioloop
import tornado.web

class MainHandler(tornado.web.RequestHandler):
	MSG_VAR = "msg_var"
	citat = {MSG_VAR: "vyrok_2013-07-12", "vyrok_2013-07-12": "vyrok pre dnesok"}

	def get(self):
		self.write(self.citat[self.citat[self.MSG_VAR]])

application = tornado.web.Application([
	(r"/", MainHandler),
])
application.listen(8888)
tornado.ioloop.IOLoop.instance().start()

Server Software:        TornadoServer/3.1.1
Server Hostname:        127.0.0.1
Server Port:            8888

Document Path:          /
Document Length:        16 bytes

Concurrency Level:      100
Time taken for tests:   2.519 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2110000 bytes
HTML transferred:       160000 bytes
Requests per second:    3969.88 [#/sec] (mean)
Time per request:       25.190 [ms] (mean)
Time per request:       0.252 [ms] (mean, across all concurrent requests)
Transfer rate:          818.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.3      1      19
Processing:     5   24  14.2     19     111
Waiting:        4   24  14.2     19     111
Total:         17   25  14.0     20     111

Percentage of the requests served within a certain time (ms)
  50%     20
  66%     21
  75%     22
  80%     23
  90%     41
  95%     49
  98%     77
  99%    104
 100%    111 (longest request)

Tu je to aj s korektným url routingom.

[mirec]

A ešte aby som bol sviňa tak na core i5 v práci (povolený jediný worker, takže pracuje fakt s jediným jadrom) ...

Concurrency Level:      100
Time taken for tests:   0.562 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2110000 bytes
HTML transferred:       160000 bytes
Requests per second:    17778.13 [#/sec] (mean)
Time per request:       5.625 [ms] (mean)
Time per request:       0.056 [ms] (mean, across all concurrent requests)
Transfer rate:          3663.27 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1    6   3.3      5      24
Waiting:        1    6   3.3      5      24
Total:          3    6   3.3      5      24

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      5
  75%      5
  80%      5
  90%      6
  95%      8
  98%     20
  99%     24
 100%     24 (longest request)

Áno skutočne je python výrazne rýchlejší pretože sa interpretuje (ak keď v podstate s jitom sa to už interpretáciou nedá nazvať) jeden riadok kódu. Zvyšok je surovo vykonávaný c-čkovými knižnicami. Python je skutočne dobrý v zliepaní kusov vysoko optimalizovaného kódu a je teda vhodný aj na veľmi výkonnostne háklivé weby. Rozdiel vo výkone oproti jave je prakticky zanedbateľný lebo väčinu času sa čaká na databázu a sockety (tam je to riešené natívnymi knižnicami). Renderovanie šablón sa tiež rieši natívnymi knižnicami v C/C++, takže tam tiež nie je žiaden výrazný rozdiel oproti jave.

[xkucf03]

Zvyšok je surovo vykonávaný c-čkovými knižnicami. … Rozdiel vo výkone oproti jave je prakticky zanedbateľný lebo väčinu času sa čaká na databázu a sockety (tam je to riešené natívnymi knižnicami). Renderovanie šablón sa tiež rieši natívnymi knižnicami v C/C++, takže tam tiež nie je žiaden výrazný rozdiel oproti jave.

Takže tam zase bude velký rozdíl v přenositelnosti…

[Saljack]

Tohle je ale u vseho.

[mirec]

C/C++ je multiplatformové. Aký je tam problém?

[sigma]

Když už chci držet data v RAM, tak je můžu mít v tom samém procesu a jako objekty daného programovacího jazyka, včetně pohodlí datových typů. Držet je v jiném procesu a přistupovat k nim přes síť dává smysl, když s tím chci pracovat z víc aplikací současně (což ale není typické – většinou jde o cache pro jednu aplikaci).

Nebo když mám aplikaci pod takovou zátěží, že jeden fyzický stroj na to už nestačí, nebo by jeho cena na jednotku výpočetního výkonu byla výrazně vyšší než cluster z více kusů "běžného" HW.

[podlesh]

No já nevím, porovnávat PHP s Pythonem není zrovna fér...

[xkucf03]

Ani když někdo programuje v Pythonu stylem, jako by to bylo PHP? (uskladňuje si objekty v nějakém externím procesu, ke kterému se připojuje po síti, místo aby si je jednoduše uložil do proměnné ve svém jazyce a přistupoval k nim – patřičně synchronizovaně – z více vláken)

[hutrad]

A jéje, no true Scotman dorazil přes celou Evropu, ten tu ještě chyběl...

[mirec]

Ešte zopár komentárov k zvyšným záležitostiam v blogu:

Java je hrozně pomalá a těžkopádná, zejména ta EE (cokoli enterprise je navíc fuj), proto píšeme v Pythonu nebo v Node.js

Neviem ako ostatní, ja píšem v interpretovaných jazykoch pretože mi stačí napísať 1/4 kódu čo v Jave. Som lenivý a hardvér je lacný.

Dále víme, že SQL a XML jsou pomalé a proto si do aplikací přidáváme NoSQL

Ta diky, ja som jedným z najväčších odporcov NoSQL, možno to z mojich blogov nevyplýva pretože nenadávam na všetko, čo nepoužívam. Nech mi nikto nekecá, že join nepotrebujem, fakt si radšej poriadne navrhnem db a hodím všetko do postgresql a v prípade špecialít použijem hstore.

databáze jako memcached

Mmecached je generický key/data storage server. Používam ho na ukladanie rôznych predžúvaných dát, session ... Umožňuje mi to pohodlne pristupovať k týmto dátam z iných procesov (napr jabber server).

Webové aplikace psané v Javě EE se liší od těch psaných na platformách jako PHP mj. svým životním cyklem – javovskou aplikaci nasadíme (deploy) na server a tam potom dlouhodobě žije – může si tedy držet stav a to na několika úrovních

Líši sa tým v niečom oproti bežným python / node webovým aplikáciám? Python sa zvyčajne nepoužíval ako cgi skript a node už vôbec nie. Nič sa nenačítava znovu pri requeste, dáta sa dajú medzi requestmi sharovať, ale nie je to považované za dobrý zvyk (minimálne to zabije flexibilitu prístupu z iných procesov).

---

Na záver môj blog vôbec nebol o performance, ale spôsobu zápisu I/O, elegancii, správe kódu. Benchmark bol použitý len na demonštráciu, že oba prípady (gevent aj nodejs) dokážu bez zablokovania spracovať veľké množstvo požiadaviek aj napriek úplne rozdielnemu spôsobu zápisu programu.

[xkucf03]

Som lenivý a hardvér je lacný.

Vidím to podobně – a právě proto píšu většinu v té Javě.

Neviem ako ostatní, ja píšem v interpretovaných jazykoch pretože mi stačí napísať 1/4 kódu čo v Jave.

Jak by v Pythonu vypadal následující kus aplikace?

package cz.frantovo.blog.servlet.správa;

import cz.frantovo.blog.Soubory;
import cz.frantovo.blog.entity.Soubor;
import java.math.BigInteger;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.mail.MessagingException;
import javax.ws.rs.Consumes;
import javax.ws.rs.GET;
import javax.ws.rs.HeaderParam;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;

/**
 *
 * @author Ing. František Kučera (frantovo.cz)
 */
@Path("autor/soubory")
@Stateless
public class SouboryAPI {

	@EJB
	Soubory ejb;

	@POST
	@Path("/")
	@Consumes("application/octet-stream")
	@Produces("text/plain")
	public String uložSoubor(
			byte[] data,
			@HeaderParam("X-Clanek") Integer článek,
			@HeaderParam("X-Nazev") String názevSouboru,
			@HeaderParam("X-Popis") String popisSouboru,
			@HeaderParam("X-Vypis") boolean výpis) {

		Soubor soubor = new Soubor();
		soubor.setNázev(názevSouboru);
		soubor.setPopis(popisSouboru);
		soubor.setVýpis(výpis);
		soubor.setČlánek(článek);

		soubor = ejb.uložSoubor(soubor, data);

		return "Soubor byl uložen pod číslem: " + soubor.getId() + "\n";
	}

	@GET
	@Path("{článek}")
	@Produces("text/plain")
	public String vypišSouboryČlánku(@PathParam("článek") BigInteger článek) {
		return "Na GET požadavky odpovíme nějak jinak…";
	}
}

• Pomocí @Path("autor/soubory") deklaruji, URL cestu, na které bude tenhle kus aplikace naslouchat
• EJBčko Soubory je injektované kontejnerem, nemusím se o něj starat
• jednotlivé metody jsou namapované na „podadresáře“ pod tou základní cestou ("autor/soubory") – @Path("/") nebo @Path("{článek}") (→ "autor/soubory/" nebo "autor/soubory/něco")
• HTTP požadavky se směrují na konkrétní metody nejen podle URL, ale i podle MIME typů
• části URL (@PathParam("článek")), HTTP hlavičky (@HeaderParam("X-Nazev")) nebo parametry (@QueryParam("…"), @FormParam("…")…) se mapují na argumenty metody a převádějí na konkrétní datové typy (pokud se někdo pokusí např. místo čísla podstrčit text, tak dojde k chybě a ani se to k tomu mému kódu nedostane)
• Kdybych použil XML místo HTTP hlaviček a parametrů, tak se to mohlo namapovat celé na jednom řádku hned na objekt typu Soubor.

Jde tam psát podobně deklarativně, nebo budu potřebovat hromadu IFů, porovnávání textových řetězců nebo regulárních výrazů a přetypování nebo ručních kontrol?

Nech mi nikto nekecá, že join nepotrebujem, fakt si radšej poriadne navrhnem db a hodím všetko do postgresql

Tak v tomhle se shodneme

dáta sa dajú medzi requestmi sharovať, ale nie je to považované za dobrý zvyk (minimálne to zabije flexibilitu prístupu z iných procesov).

Proč bych měl k interním datům aplikace přistupovat z jiných procesů? Chápu ten případ použití memcached, jak jsi psal, že k tomu přistupuješ z webu i z jabber serveru – to je dobrý příklad. Ale jinak to opravdu smysl nedává.

Na záver môj blog vôbec nebol o performance, ale spôsobu zápisu I/O, elegancii, správe kódu.

To považuji za důležité – a právě proto se mi nelíbí, když se vedle sebe míchají věci typu na jaké IP a portu naslouchat a samotná byznys logika aplikace.

[mirec]

Jak by v Pythonu vypadal následující kus aplikace?

Záleží od frameworku ale v zásade rovnako.

Proč bych měl k interním datům aplikace přistupovat z jiných procesů? Chápu ten případ použití memcached, jak jsi psal, že k tomu přistupuješ z webu i z jabber serveru – to je dobrý příklad. Ale jinak to opravdu smysl nedává.

To bol príklad ktorým som demonštroval ako blokovanie I/O funguje, kedy je užitočné a kedy je škodlivé. Kľudne som mohol hrabnúť na SQL databázu, ale ruku na srdce komu by sa chcelo v node.js hrabať do postgresql? Mne nie, takže som použil niečo iné, čo aj tak musí bežať cez tcp/ip - memcached. Inak ho používal len na session (kvôli autentifikácii iných služieb) a predžúvané šablóny.

[Poirot]

Hnusnější věc než ten tvůj kus kódu jsem nikdy neviděl, kudos.

[xkucf03]

Napiš to líp

[Poirot]

Není problém, stačí vyhodit ty deklarativní netransparentní srágory

[mirec]

Proč bych měl k interním datům aplikace přistupovat z jiných procesů?

Príkladov je veľa, minimálne session by som tam dával a to z rôznych dôvodov. Uvádzal som autorizáciu z iných služieb (robil som jabber, ale môže byť prakticky čokoľvek). Zaujímavým použitím je napr. pri deployi spustiť nový aplikačný server a nechať priamo webserver podľa session routovať všetky práve existujúce sessiony na starú inštanciu. Po vypršaní session užívateľa, alebo odhlásení automaticky prejde na novšiu verziu webovej aplikácie. Ďalej je tu samozrejme distribuovanosť, možnosť aplikačný server v noci keď prebieha záloha úplne vypnúť čím sa ušetrí RAM (python aplikačný server dokáže v prípade požiadavky nabehnúť do sekundy, takže vypínanie po pár minútach nečinnosti nie je v zásade žiaden problém a na zdieľanom serveri je to fakt na nezaplatenie). Nad aplikačným serverom stojí správca procesov, ktorý spúšťa skutočné separátne procesy. V managovaných jazykoch nevyzerá ako veľká výhoda, ale aj java má jni a občas sú knižnice na špecializované veci (opencv) len natívne a môžu v nich zniknúť chyby čo buď spôsobí leak, alebo kľudne aj niečo horšie. Ja si v takom prípade môžem bez problémov pri prekročení RAM, alebo procesorového času nechať aplikačný server zabiť a o žiadne dáta neprídem.

[deda.jabko]

Nechapu, jak nekdo muze pouzivat diakritiku v nazvech promennych, metod a trid a jeste se pod to (vlastne nad to) podepsat.

[xkucf03]

Viz tenhle starší článek. Záleží na projektu, někdy píšu česky, někdy anglicky, zrovna tahle aplikace slouží jen pro mě a ani jsem to neplánoval dávat nikomu číst – akorát se to zrovna hodilo jako příklad k tomuto tématu.

BTW: diakritika a různé další unicode znaky jsou v Javě legální identifikátory – někdy je dobré otestovat, že všechno funguje tak dobře, jak je to popsané ve specifikaci Mj. jsem tím otestoval, že v Pygmentize¹ je chyba – nepočítá s jinými znaky než ASCII, i když tam (v Javě a jinde) být můžou. Pro XML to už opravili, pro Javu tam myslím mají chybu i v poslední verzi.

_{[1] zvýrazňovač syntaxe, není součást Javy, je psaný v Pythonu}

[deda.jabko]

někdy píšu česky

Ve skutecnosti pises nejakym hybridem, napr. soubor.setPopis(...)

[xkucf03]

get, set, is – jsou standardizované prefixy, je to v podstatě součást jazyka (Javy).

[m-a]

Coze?

[xkucf03]

Viz specifikace JavaBeans. Když si ty metody pojmenuješ třeba dejNěco() nebo nastavNěco(), tak je to sice zkompilovatelný zdroják, ale není to JavaBean a nemůžeš instance takové třídy použít tam, kde se JavaBean vyžaduje – např. v JSP (tam totiž přistupuješ k vlastnostem instance jako k instance.něco bez nějakých get a set).

[mirec]

Python sa zapisuje v rot13. Je to v špecifikácii. To že je tam nejaká kravina neznamená, že to hneď musím používať.

# -*- coding: rot13 -*-
cevag h"Uryyb nopyvahkh!"

[xkucf03]

Ta čeština ve zdrojácích je ale otázka znakové sady (resp. povolené podmnožiny z ní) nikoli kódování znaků (i v Javě můžeš psát v různých kódováních a rot13 by tam šlo udělat taky).

[mirec]

Toto je zdroják kódovaný v rot13. Alebo si niekto myslí, že cevag je príkaz jazyka? Python umožňuje písať zdrojový kód v ľubovoľnom kódovaní, default ascii, ale kódovanie nie je pevne zadrátované.

[lister]

Tak ono je možný leccos, včetně psaní identifikátorů v ne-ASCII znacích, ale pokud to nekódíte jen jako hobby projekt pro sebe, tak je to prasárna, která zbytečně přináší komplikace. Tohle udělat někdo u nás v práci, tak poprvé ho to nechaj obratem přepsat a podruhé už to je na vykopnutí z místa. However, your mileage may vary.

[Ivorne]

Spíše by se měl řešit skutečně ten styl programování, než použité technologie. Pokud vím, tak i PHP umožňuje uložit libovolné datové struktury do session.

[xkucf03]

V jedné konkrétní session je ti to ale na nic, pokud k těm samým datům¹ chceš přistupovat ze všech relací a všech HTTP požadavků.

_{[1] resp. objektům, které spojují data a chování, ne jen k nějakým neživým serializovaným strukturám}

[dementni.lojzik]

IMHO je postata memcached v tom, ze je to distribuovana cache, coz neni ani v jave out of the box (ze to nekdo ppuziva blbe, je asi problem dotycneho, jak moc je to caste nemam tuseni). Jinak srovnani, kde se vola jen get, ktery u ConcurrentHashMap neni synchornizovany (tj. je to opravdu jako cteni z lokalni promenne), mi neprijde uplne fer

[xkucf03]

Ano, zkoušel jsem i Collections.synchronizedMap() a výsledky byly horší. Ale proč to zpomalovat synchronizací na místě, kde být nemusí?

[dementni.lojzik]

Ale proč to zpomalovat synchronizací na místě, kde být nemusí?

nemyslel jsem to tak, ze by se to melo nekde zamerne zpomalovat, jen ze by se melo srovnavat srovnatelne. Pokud node.js a vsechno pod nim pri cteni nic nesynchronizuje, nezamyka atd.(*), pak ok, ale pokud ne, tak se porovnaji hrusky s jabkama (framework, ktery nekde uvnitr synchronizuje s kodem, ktery nikde nic nesynchronizuje)
(*) coz mi prijde dost nepravdepodobne, ale to je jen muj tip, netusim, jak je node.js implementovany

[mirec]

Sockety musia byť samozrejme synchronizované, memcache protokol striktne vyžaduje poradie dotaz - odpoveď (nie je možné prerušiť medzi dotazom a odpoveďou a vykonať ďalší dotaz, musia byť skutočne vykonané sekvenčne).

[dementni.lojzik]

to je vcelku jasne, IMHO tim zapiskem xkucf03 prave chtel rict, ze jeho implementace bude rychlejsi, protoze se v JEE obejde bez memcache (nechme ted stranou, ze v PHP se pochopitelne bez toho jde taky obejit a ukladat treba do session). Ja chtel rict, ze se domnivam, ze ani tak to srovnani neni uplne ok, protoze ta implementace v jave vubec nesynchronizuje, kdezto u node.js bych predpokladal, ze je tam navic nejaka rezie navic diky asynchronnimu volani (a asynchtonni volani je neco uplne jineho nez normalni volani - proto to srovnani hruek a jablek). Jako prvni priblizeni bych to asi pouzil asynchronni zpracovani pozadavku (v JEE od servlet 3.0)

[Josef Kufner]

V PHP je k dispozici APC, což je prakticky totéž jako memcached, ale mezi programem a cache není socket a data není nutné serializovat, takže to je mnohem rychlejší. A je to i přibalené v základu, takže odpadá jakákoliv instalace.

[Luk]

APC je něco jiného - cache pro kód, nikoli pro data. APC při prvním spuštění skript předkompiluje a uloží si tuto předkompilovanou verzi. S daty to nemá nic společného.

[Josef Kufner]

Kdepak. Opcode cache je jen jedním z možných use case. APC umí kešovat i uživatelská data – viz apc_store a apc_fetch.

[Luk]

Aha, jak na to koukám, tak to umí i tohle. V dokumentaci o APC píší:

The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code.

Z toho vyplývá, jaký je účel. Cachování dat je zjevně vedlejší využití části jeho schopností (toho, že mj. umožňuje držet část dat v paměti a sdílet je mezi relacemi).

[Josef Kufner]

A vzhledem k tomu, že opcode cache je odnedávna součástí PHP, tak to zbylo jako primární účel.

[Kozzi]

Tusim ze APC neni soucasti PHP, ale je to rozsireni, takze je treba instalovat. Nehlede na to ze od nove verze PHP bylo APC zruseno a neni dale kompatibilni. Misto nej lze ale vyuzit APCu + zend opcache

[Saljack]

Me nejvic na Java EE sere, ze vetsinu casu clovek stravi na tom, ze hleda jak to nastavit aby to fungovalo, potom je to super. Docela jsem si ted Java EE oblibil, hlavne se mi libi JAX-RS.

[Bedňa]

Java really?

[xkucf03]

the Java language as such is no longer a trap

[Bedňa]

Ten koment som chcel zavesiť inde Java to je past vedle pasti. So slobodným implementáciami, mám veľmi, veľmi zlé skúsenosti.

[foldy]

Obdivuju programátory, že dokážou řešit takto složité problémy. Mě nikdy tyhle věci nešli, resp. nesžil jsem se s OOP nebo interpretem, pokud nejde o bash. Dělám si weby v C a ASM, resp začínám už delší dobu a myslím si, že je jedno co použijete, v každé aplikaci narazíte na problém, který je nutno správně algoritmicky a technologicky vyřešit. Je jedno jakými prostředky(čím více prostředků, tím více možností) důležitý je vždy výsledek.

Pro konkrétní diskuzi. Přikláním se k javě, pokud vytváří ty objekty a hodnoty v paměti, má k nim i přímí přístup, dají se vracet adresy, přičítat odečítat hodnoty přímo v paměti atd. Pokud se data proženou nějakým TCP/IP,SQL apod. ztratí se tento přímí přístup, což může zamezit nebo znesnadnit aplikaci různách řešení optimalizací a geniálních algoritmických výmyslů(což je možná někdy dobře :)).

[JS1]

Nevim, jestli je tento prispevek minen vazne nebo ne, ale pokud ano, nechci na vas byt moc zly: Opravdu si nechte poradit ohledne technologii, ktere pouzivate. Hlavne radeji snad nic algoritmickeho nevymyslejte. Usnadni vam to zivot.

[foldy]

V pohodě, svoji technologii docela zvládám a svoje algoritmy taky, a že už jsem jich vymyslel hodně.. Dělám si svoje implementace a těm ostatním moc nerozumím. Proto jsem to v textu zmínil, že pokud je ta komplexita moc velká, (objekty, předání, dědičnosti, workaroundy) apod.tak se v tom ztrácím. Proto zůstávám u země a hraju si s bity, adresami a jednoduchými funkcemi, ze kterých skládám o pár úrovní větši komplexy, kterým ještě rozumím. Chtěl jsem jen zmínit, že přímé přístupy k datům někdy usnadní řešení různých problémů. Mluvím však jen ze zkušenosti.

[Josef Kufner]

[...] a svoje algoritmy taky, a že už jsem jich vymyslel hodně..

Podělíš se s námi o pár kousků?

[foldy]

Jo ted si dělám směrování pro validní url při proklikávání v menu a zobrazování obsahu. Dělám porovnání binárním stromem po písmenkách aby to nemuselo porovnávat celé stringy, tak to půjde po stromu, jak bude hotový web i se směrováním tak to hodím pod GNU/GPL. Časem bych chtěl do toho zaintegrovat nějakej lepší formální systém a dělat to směrování na základě fraktálních funkcí, ušetří se tam pár bitů a bude to rychlejší, za využití vnitřní logiky. Možná by stačilo sestavit nějaký jednoduchý formální systém, který by obsahoval rozhodovací formuly pro teorémy položek toho menu.

[Josef Kufner]

Hlavně nezapomeň na opačný směr – podle identifikátoru entity generovat její URI. Trii umí kde kdo.

[foldy]

Hehe jo... já si to většinou nejdřív napíšu na papír a dumám nad tím ze všech směrů aby to náhodou nedopadlo tak... jako když postavíš barák ale zapomeneš na dveře :D:D... Je mi jasné, že tyhle techniky ovládá každý programátor,.. já s programováním začínám už léta není na to tolik času, nemám to jako práci, takže si osvojuji pár technik které potřebuji, abych si mohl dělat větší projektíky :)

Btw, offtopic, nevíš co se dnes používá pro vektorové paralelní výpočty ? Cray nebo Nec pochybuju že seženu, takže POWER 7 nebo MIPS bys doporučil ?

[retro]

Memcached není nosql DB. Pokud se mýlím, pak poprosím o zdroj.

[xkucf03]

Není to zrovna autoritativní zdroj, ale např. na Wikipedii to tam řadí a odkazují u toho nějaký článek.

NoSQL je to určitě, otázka je, jestli je to i databáze – záleží jak ji definuješ a jaké budeš mít minimální nároky na SW, aby se mu dalo říkat databáze. IMHO se to tam klidně řadit může – ostatně taková PostgreSQL nebo MySQL ve které si vytvoříš tabulku, která je jen v paměti, tak je taky pořád databáze.

[podlesh]

Těžko říct jak přesně definujeme pojem databáze, ale myslím že cache která nejenom že není perzistentní ale dokonce vyhazuje nepoužívané záznamy když je potřeba uvolnit místo (LRU) si myslím toto označení opravdu nezaslouží.

[__dark__]

How replacing Java with JavaScript is paying off for PayPal

[mirec]

K tomu si požičiam jeden príspevok z môjho blogu:

> [1, 2, 3, 10].sort()
[1, 10, 2, 3]

Toľko logických vecí v iných jazykoch nenájdete ;)

[Michal Vyskočil]

JavaScript, the good parts