Paměťová a výpočetní náročnost JVM vs .NET

[Radek Miček]

Nic takového jsem nenapsal: Např. slovo objednávka jsem nezmínil ani jednou. A rozhodně jsem neříkal, kde se ta data drží. Mluvil jsem o vektoru dvojic (id produktu, skóre), který si načtete třeba z databáze nebo si ho spočítáte, pokud již nebyl spočten a uložen v cachi.

Normální program si z databáze nenačte pět dvojic (id produktu, skóre), ale načte si pět záznamů (název produktu, odkaz na produkt, odkaz na obrázek produktu, skóre). Optimalizovat uložení těch pěti záznamů v paměti aplikace tak, aby se vešly do cache procesoru, je nesmysl na entou. Ale pokud si někdo chce hrát se strukturami proměnlivé délky (minimálně ten název produktu bude text s různou délkou), ať si to užije. Drobným problémem bude, že dotyčný autor sice bude mít optimalizovaný výpis (ne získání) 5 doporučených produktů, akorát mu k tomu bude chybět ten e-shop (který by za tu dobu napsal ten, kdo neřeší nesmyslné optimalizace).

Ne, to jste mne špatně pochopil. Z databáze si načtete třeba 100 nebo 1000 dvojic (id produktu, skóre) (případně těch 100 nebo 1000 dvojic spočtete na základě jiných dat, která máte v databázi). Pokud jste ty dvojice počítal, tak je setřídíte sestupně dle skóre (předpokládám, že do databáze je již ukládáte setříděné). A pak vyberete id 5 produktů s nejvyšším skóre, které uživatel viděl 4x nebo méně. A takto vybrané produktu mu ukážete, protože si myslíte, že by o ně mohl mít zájem.

Co možná není zřejmé je, že ten vektor je pro každého uživatele jiný.

[Reklama]

[andy]

Ak mam web aplikaciu (o ktorych je rec) ktora je tak vytazena, ze riesim cache CPU, tak zivotnost dat v CPU je tak tazko predpovedatelna, ze to nema zmysel riesit (to nie je graficka aplikacia ze si alokujem pole a to pole tam ostane ako dlho potrebujem..). Ak je zataz mala, tak to tiez nema zmysel riesit, lebo IO je radovo pomalsie ako cache cpu. Moj nazor je, ze je lepsie mat vsetky data klienta ako objekty a najlepsie alokovane kratko za sebou. Tak je pravdepodobnost, ze pri nacitani hodnoty sa natiahnu do cache aj suvisiace hodnoty daneho usera (ktoreho request prave obsluhujem), pretoze v eden space sa data alokuju za sebou a navyse jvm vklada prefetch instrukcie. Obcas sa da prechytracit JVM, ale vacsinou je to strata casu a je lepsie sa sustredit na lepsi algoritmus.

Okrem toho ked si chcem cachovat data v pamati, tak dnes uz v jave existuju kniznice, ktore vedia cachovat objekty priamo do offheap pamate bez zbytocnej vaty. Je to skaredy hack, ale funguje to.

Ze su hostingy pre .net je podla mojho nazoru jednoducho preto, ze IIS ma na to nejake pasivacne ficurky (s ktorymi sa da dosiahnut dost vysoka hustota appiek/server pri beznych=90% casu idle apkach) a java servery ziadne take ficurky nemaju. S modernymi java frameworkami ktore sa nestartuju minuty ale sekundy sa to da urobit aj s javou (napr google app engine myslim pasivuje idle java aplikacie), ale kto by to robil pri cene VPS pod 5 eur/mesiac?

[JSH]

To je ale v rozporu s tím, co psal JSH, že ke správnému využití cache stačí použít správný programovací jazyk. Přečíst by si to tedy měl JSH.

Kde jsem něco takového psal?

Pro efektivní využití cache bohatě stačí aby jazyk zbytečně nevkládal zbytečné skákání po pointerech.

Jo tohle. Měl jsem za to, že je z kontextu jasné, co tím myslím. Moje chyba
gl vystihl dobře, co jsem se snažil říct.

[gl]

CPU výkon má smysl řešit například při párování nabídek podle nějakých složitějších kriterií, nebo v map a reduce funkcích u různých nosql databází, hadoopu apod. Těch případů je určitě spousta.

[javaman ((]

Jak to teda třeba ten Hadoop dělá, když je psaný v Javě? Nebo jen na rootu mají problém s cachí, která je sice asi důležitá, ale ne moc? Jako jestli třeba Hadoop není rozbitý a neměli by ho předělat podle vás.

[Reklama]

[gl]

Jasně. Takže libovolná implementace radix tree, spojového seznamu nebo HTML parseru bude efektivně využívat cache procesoru, pokud bude napsaná v C++.

Spojové struktury jako seznamy a stromy se právě z důvodu využití cache dnes moc nepoužívají. Přečti si něco o cache obvious algoritmech.

To je ale v rozporu s tím, co psal JSH, že ke správnému využití cache stačí použít správný programovací jazyk. Přečíst by si to tedy měl JSH.

On nic takového nepsal.

Jakou optimalizaci? V jiných jazycích je to triviální.

Asi byste si měl přečíst něco o cache obvious algoritmech. Dozvěděl byste se třeba, že se spojové seznamy a stromy nepoužívají, a to bez ohledu na programovací jazyk – protože ten to nijak magicky nezachrání.

Na tom se shodneme. Myslel jsem tím pole struktur, to je v jiných jazycích triviální.

Volbu správné datové struktury bych optimalizací nenazýval.

Tak to byste si měl něco přečíst i o datových strukturách. Protože jedna datová struktura může být vhodná z hlediska paměťové náročnosti, obvykle jiná bývá vhodná z hlediska rychlosti (a to je ještě různé pro čtení a pro zápis), jiná datová struktura může být vhodná z hlediska snadnosti použití nebo složitosti implementace. Která z nich je ta správná? Obvykle ta, co se nejsnáz používá, ale někdy je potřeba optimalizovat – a pak je často nutné změnit datovou strukturu.

Pokud se používají obě možnosti stejně snadno, vyberu tu efektivnější.

[gl]

Jak to teda třeba ten Hadoop dělá, když je psaný v Javě? Nebo jen na rootu mají problém s cachí, která je sice asi důležitá, ale ne moc? Jako jestli třeba Hadoop není rozbitý a neměli by ho předělat podle vás.

Pokud redukční funkce provádí něco složitějšího, tak je každé její zrychlení sakra znát.

[Radek Miček]

Jak to teda třeba ten Hadoop dělá, když je psaný v Javě? Nebo jen na rootu mají problém s cachí, která je sice asi důležitá, ale ne moc? Jako jestli třeba Hadoop není rozbitý a neměli by ho předělat podle vás.

Distribuce od Cloudery má tyto problémy také. Proto distribuce od MapR převedla některé části do C++.

Jinak je to přesně, jak říká gl - v MR jobech nebo Spark jobech často pracujete s velkými kolekcemi dat a např. tím, že někde přestanete zbytečně boxovat ušetříte stovky MB paměti ==> díky čemuž může na jednom nodu běžet více jobů.

[Filip Jirsák]

Ne, to jste mne špatně pochopil. Z databáze si načtete třeba 100 nebo 1000 dvojic (id produktu, skóre) (případně těch 100 nebo 1000 dvojic spočtete na základě jiných dat, která máte v databázi). Pokud jste ty dvojice počítal, tak je setřídíte sestupně dle skóre (předpokládám, že do databáze je již ukládáte setříděné). A pak vyberete id 5 produktů s nejvyšším skóre, které uživatel viděl 4x nebo méně. A takto vybrané produktu mu ukážete, protože si myslíte, že by o ně mohl mít zájem.

Nikoli, nepochopil jsem vás špatně. Akorát jsem doufal, že alespoň tušíte, jak se nějaká data zpracovávají. Ale je to typické. O optimalizaci pro cache procesoru píše někdo, kdo netuší, že SELECT z databáze má také podmínkovou část WHERE a část ORDER BY pro řazení dat. Když nebudete tahat všechna data z databáze do aplikace a třídit a řadit je tam, ale místo toho se naučíte používat databázi, budete to oproti hrátkami s cache procesoru milionkrát účinnější optimalizace.

CPU výkon má smysl řešit například při párování nabídek podle nějakých složitějších kriterií, nebo v map a reduce funkcích u různých nosql databází, hadoopu apod. Těch případů je určitě spousta.

Přičemž nic z toho se nebude řešit ve webové aplikaci, ale v databázi.

[andy]

Nikoli, nepochopil jsem vás špatně. Akorát jsem doufal, že alespoň tušíte, jak se nějaká data zpracovávají. Ale je to typické. O optimalizaci pro cache procesoru píše někdo, kdo netuší, že SELECT z databáze má také podmínkovou část WHERE a část ORDER BY pro řazení dat. Když nebudete tahat všechna data z databáze do aplikace a třídit a řadit je tam, ale místo toho se naučíte používat databázi, budete to oproti hrátkami s cache procesoru milionkrát účinnější optimalizace.

Na toto som celkom zabudol. Uz som riesil viac takychto aplikacii, kde pristup "ja to urobim lepsie len co si stiahnem polku db" sposobil, ze pri 30 req/s sa zahltila siet (iba 1Gbit) a cpu mohlo ist na dovolenku.

[javaman ((]

Pořád mi to nějak nesedí. Máme luxusní SW psaný v Javě (Hadoop, Cassandra, atd.), který se používá na největší věci a i když to podle rootu nejde kvůli cachi, tak prostě pořád není konkurence v něčem jiném. Takže buď máte pravdu a je to strašný problém, ale pak žijeme každý v jiném světě a nebo to není až takový problém, protože jsou daleko důležitější věci po cestě, než zarovnávání objektů do paměti.

Nebo je to úplně jinak a dozvím se to tady!

[gl]

Ne, to jste mne špatně pochopil. Z databáze si načtete třeba 100 nebo 1000 dvojic (id produktu, skóre) (případně těch 100 nebo 1000 dvojic spočtete na základě jiných dat, která máte v databázi). Pokud jste ty dvojice počítal, tak je setřídíte sestupně dle skóre (předpokládám, že do databáze je již ukládáte setříděné). A pak vyberete id 5 produktů s nejvyšším skóre, které uživatel viděl 4x nebo méně. A takto vybrané produktu mu ukážete, protože si myslíte, že by o ně mohl mít zájem.

Nikoli, nepochopil jsem vás špatně. Akorát jsem doufal, že alespoň tušíte, jak se nějaká data zpracovávají. Ale je to typické. O optimalizaci pro cache procesoru píše někdo, kdo netuší, že SELECT z databáze má také podmínkovou část WHERE a část ORDER BY pro řazení dat. Když nebudete tahat všechna data z databáze do aplikace a třídit a řadit je tam, ale místo toho se naučíte používat databázi, budete to oproti hrátkami s cache procesoru milionkrát účinnější optimalizace.

CPU výkon má smysl řešit například při párování nabídek podle nějakých složitějších kriterií, nebo v map a reduce funkcích u různých nosql databází, hadoopu apod. Těch případů je určitě spousta.

Přičemž nic z toho se nebude řešit ve webové aplikaci, ale v databázi.

Psal jsem spíš o nějakém předpočítávání dat pro sql databázi, případně o nosql, databázích.

[Filip Jirsák]

Pořád mi to nějak nesedí. Máme luxusní SW psaný v Javě (Hadoop, Cassandra, atd.), který se používá na největší věci a i když to podle rootu nejde kvůli cachi, tak prostě pořád není konkurence v něčem jiném. Takže buď máte pravdu a je to strašný problém, ale pak žijeme každý v jiném světě a nebo to není až takový problém, protože jsou daleko důležitější věci po cestě, než zarovnávání objektů do paměti.

Nebo je to úplně jinak a dozvím se to tady!

Samozřejmě jsou daleko důležitější věci, než je zarovnání objektů v paměti. A tam, kde by tyhle projekty narážely na problém se zarovnáním objektů v paměti, tak to jejich vývojáři prostě vyřeší prostředky Javy – pro autory Hadoop nebo Cassandy určitě není nepřekonatelný problém, že IntArrayList není součástí standardní knihovny.

[gl]

Pořád mi to nějak nesedí. Máme luxusní SW psaný v Javě (Hadoop, Cassandra, atd.), který se používá na největší věci a i když to podle rootu nejde kvůli cachi, tak prostě pořád není konkurence v něčem jiném. Takže buď máte pravdu a je to strašný problém, ale pak žijeme každý v jiném světě a nebo to není až takový problém, protože jsou daleko důležitější věci po cestě, než zarovnávání objektů do paměti.

Nebo je to úplně jinak a dozvím se to tady!

Je úplně jedno v čem je to napsané. Hadoop pouze předává data programům, které jsi napsal ty.

[Radek Miček]

Ne, to jste mne špatně pochopil. Z databáze si načtete třeba 100 nebo 1000 dvojic (id produktu, skóre) (případně těch 100 nebo 1000 dvojic spočtete na základě jiných dat, která máte v databázi). Pokud jste ty dvojice počítal, tak je setřídíte sestupně dle skóre (předpokládám, že do databáze je již ukládáte setříděné). A pak vyberete id 5 produktů s nejvyšším skóre, které uživatel viděl 4x nebo méně. A takto vybrané produktu mu ukážete, protože si myslíte, že by o ně mohl mít zájem.

kdo netuší, že SELECT z databáze má také podmínkovou část WHERE a část ORDER BY pro řazení dat.

To nemusí být možné, protože ne každá databáze to dokáže (BTW potřebujete navíc ještě JOIN s tabulkou statistik, kolikrát byl produkt uživateli zobrazen).

Když nebudete tahat všechna data z databáze do aplikace a třídit a řadit je tam, ale místo toho se naučíte používat databázi, budete to oproti hrátkami s cache procesoru milionkrát účinnější optimalizace.

Stahujete max pár kb dat. A to jestli se vyplatí výpočet provést na straně db záleží na konkrétní db (běžné relační db například nemusí unést zápis při aktualizaci skóre; pokud navíc vektory se skóre nemáte uloženy v db, ale počítáte z jiných dat, výpočet je o něco složitější - menší pravděpodobnost, že se vyplatí provádět ho uvnitř db).