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

[Radek Miček]

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.

Jak říkám, nejde jen o cache, ale i o množství využité paměti a nápor na GC. V Javě se to pak řeší tak, že se dávají data mimo heap - což je ale těžší a dražší na vývoj.

Kromě toho, nikdo nepsal, že to nejde, ale že je to méně šetrné ke zdrojům.

tak prostě pořád není konkurence v něčem jiném

Alternativy existují, ale jsou méně podporované než Hadoop MR.

[Reklama]

[Filip Jirsák]

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).

Takže těch pár kB dat, která je problém přenést z hlavní paměti do cache procesoru, raději budete posílat po síti. Jo, to je úžasná optimalizace.

[Radek Miček]

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).

Takže těch pár kB dat, která je problém přenést z hlavní paměti do cache procesoru, raději budete posílat po síti.

Ano, pokud to nejde spočítat v db (db nestíhá nebo to neumí). Navíc v tom svém řešení mohu výsledky z db cachovat - těch pár kb (vektor obsahující id produktů a skóre) se po určitou dobu nemění a dále jako bonus nemusím pokaždé aktualizovat tabulku v db, kolikrát byl uživateli určitý produkt nabídnut.

[Filip Jirsák]

Ano, pokud to nejde spočítat v db (db nestíhá nebo to neumí).

Pokud to nejde spočítat v db, nemá smysl řešit procesorovou cache, ale zařídit, aby to v db spočítat šlo – rozdíl ve zlepšení je několik řádů.

[Radek Miček]

Ano, pokud to nejde spočítat v db (db nestíhá nebo to neumí).

Pokud to nejde spočítat v db, nemá smysl řešit procesorovou cache, ale zařídit, aby to v db spočítat šlo – rozdíl ve zlepšení je několik řádů.

Aby to šlo, musel byste třeba vyměnit databázi, jenže, jak jsem psal výše, jiná databáze (např. relační) už nemusí zvládnout zátěž při aktualizaci těch vektorů.

Pak je tu otázka, zda naopak nedojde ke zhoršení, když ten výpočet bude trošku složitější (v db nebudou přímo vektory se skóre, ale budou tam jiná data, z nichž se tyto vektory počítají (např. každá složka vektoru bude spočtena jako skalární součin jiných vektorů v databázi - přičemž v aplikaci můžete na výpočet použít specializovanou matematickou knihovnu, v SQL máte smůlu)).

[Reklama]

[NooN]

Aby to šlo, musel byste třeba vyměnit databázi, jenže, jak jsem psal výše, jiná databáze (např. relační) už nemusí zvládnout zátěž při aktualizaci těch vektorů.

Pak je tu otázka, zda naopak nedojde ke zhoršení, když ten výpočet bude trošku složitější (v db nebudou přímo vektory se skóre, ale budou tam jiná data, z nichž se tyto vektory počítají (např. každá složka vektoru bude spočtena jako skalární součin jiných vektorů v databázi - přičemž v aplikaci můžete na výpočet použít specializovanou matematickou knihovnu, v SQL máte smůlu)).

Zasa jeden co si mysli, ze to zoptimalizuje lepsie ako SQL server.
Staci viac porozumiet SQL serveru a garantujem ti ze mas po probleme...

[Radek Miček]

Aby to šlo, musel byste třeba vyměnit databázi, jenže, jak jsem psal výše, jiná databáze (např. relační) už nemusí zvládnout zátěž při aktualizaci těch vektorů.

Pak je tu otázka, zda naopak nedojde ke zhoršení, když ten výpočet bude trošku složitější (v db nebudou přímo vektory se skóre, ale budou tam jiná data, z nichž se tyto vektory počítají (např. každá složka vektoru bude spočtena jako skalární součin jiných vektorů v databázi - přičemž v aplikaci můžete na výpočet použít specializovanou matematickou knihovnu, v SQL máte smůlu)).

Zasa jeden co si mysli, ze to zoptimalizuje lepsie ako SQL server.
Staci viac porozumiet SQL serveru a garantujem ti ze mas po probleme...

Celkem o tom pochybuji - máte např. nějaká měření, kde SQL Server počítá skalární součiny rychleji než aplikace v C#?

[borekz]

Celkem o tom pochybuji - máte např. nějaká měření, kde SQL Server počítá skalární součiny rychleji než aplikace v C#?

Pokud např. v MySQL bude skalární součin počítat UDF v C++, bude to rychlé jako C++. Vsadím se, že databáze s podporou GIS budou mít takové funkce vestavěné. Jde hlavně o to, že na moderním HW je výpočet součinu záležitostí několika strojových cyklů, narozdíl od režie na poslání vektoru přes soket do aplikace v C#. V Javě má navíc překvapivě vysokou režii ovladač JDBC. Mám změřeno, že načtení velkého objemu z MySQL je výrazně rychlejší v C přes libmysqlclient než v Javě přes Connector/J a navíc se nejprve vše načítá do RAM, než lze z Resultsetu načíst první záznam. Pokud je výstup výpočtu menší než vstup, je obvykle výhodnější provést výpočet v db serveru.

[Radek Miček]

Celkem o tom pochybuji - máte např. nějaká měření, kde SQL Server počítá skalární součiny rychleji než aplikace v C#?

Pokud např. v MySQL bude skalární součin počítat UDF v C++, bude to rychlé jako C++.

Ano, to je pravda. V SQL Serveru se používají CLR funkce - tj. tímto trikem byste dosáhl podobné rychlosti, pokud by data byla uložena ve formátu, jenž je vhodný pro násobení.

Jde hlavně o to, že na moderním HW je výpočet součinu záležitostí několika strojových cyklů, narozdíl od režie na poslání vektoru přes soket do aplikace v C#.

Souhlasím - nepočítal jsem s použitím UDF. Tj. už věřím, že byste celý výpočet, i když je ve skutečnosti složitější, mohl přesunout do SQL Serveru aniž by došlo ke zpomalení.

[Filip Jirsák]

Celkem o tom pochybuji - máte např. nějaká měření, kde SQL Server počítá skalární součiny rychleji než aplikace v C#?

Máte vy nějaká měření, že načíst všechna data z disku, přenést je po síti a pak je možná spočítat rychleji v C# je rychlejší, než načíst z disku jenom potřebná data, spočítat to možná pomaleji na SQL serveru a pak přenést po síti jenom výsledek? Je pozoruhodné, jak se pořád snažíte optimalizovat práci procesoru, ale zbytečné načítání z disku nebo přenosy po síti vám vůbec nevadí. Přitom disk a síť jsou ty hlavní brzdy, ty vaše výpočty vám procesoru udělá v době, kdy bude čekat na další síťový paket, a ještě se u toho bude flákat.

[Radek Miček]

Celkem o tom pochybuji - máte např. nějaká měření, kde SQL Server počítá skalární součiny rychleji než aplikace v C#?

Máte vy nějaká měření, že načíst všechna data z disku, přenést je po síti a pak je možná spočítat rychleji v C# je rychlejší, než načíst z disku jenom potřebná data, spočítat to možná pomaleji na SQL serveru a pak přenést po síti jenom výsledek? Je pozoruhodné, jak se pořád snažíte optimalizovat práci procesoru, ale zbytečné načítání z disku nebo přenosy po síti vám vůbec nevadí. Přitom disk a síť jsou ty hlavní brzdy, ty vaše výpočty vám procesoru udělá v době, kdy bude čekat na další síťový paket, a ještě se u toho bude flákat.

Nedělám, to, co popisujete.

Do aplikace v C# se posílá nejvýše 1 vektor (pro uživatele) vektory, s nimiž se budou dělat skalární součiny (pro produkty) tam již jsou. Někdy tam dokonce je i ten vektor pro uživatele. Navíc, pokud máte pouze jeden výdejový server (ta aplikace v C# běží na 1 serveru), tak nemusíte na SQL Server pokaždé posílat, kolikrát uživatel daný produkt viděl (zatímco, když to budete počítat na SQL Serveru, tak to musíte posílat po každé), díky čemu síťový i diskový provoz naopak ušetříte.

Pokud jste malý e-shop na sdíleném hostingu, tak v db ani nemusíte mít povolené UDF, takže to nespočítáte tak rychle. Pokud jste velký e-shop, tak relační databáze nemusí ustát aktualizaci těch vektorů - tj. budete používat nějakou NoSQL databázi, ve které to ovšem ani nemusí jít spočítat.

[Filip Jirsák]

tak nemusíte na SQL Server pokaždé posílat, kolikrát uživatel daný produkt viděl

Bývá zvykem data, která chcete uložit, ukládat do nějaké databáze – ať už SQL nebo NoSQL. Držet je jenom v paměti webového serveru není dobrý nápad, protože o ně přijdete při prvním ukončení serveru (třeba kvůli aktualizaci).

Pokud jste malý e-shop na sdíleném hostingu, tak v db ani nemusíte mít povolené UDF, takže to nespočítáte tak rychle.

Jenže rychlé počítání nikoho nezajímá, protože i to nejpomalejší počítání bude pořád o několik řádů rychlejší, než zbytečné načítání dat z  disku nebo jejich zbytečné posílání po síti.

Pokud jste velký e-shop, tak relační databáze nemusí ustát aktualizaci těch vektorů - tj. budete používat nějakou NoSQL databázi, ve které to ovšem ani nemusí jít spočítat.

Pokud to v té NoSQL databázi nepůjde spočítat, budu řešit, jak použít lepší NoSQL databázi a ušetřit tím desítky nebo stovky milisekund. Nebudu řešit výkon CPU, abych ušetřil mikrosekundy.

[Radek Miček]

tak nemusíte na SQL Server pokaždé posílat, kolikrát uživatel daný produkt viděl

Bývá zvykem data, která chcete uložit, ukládat do nějaké databáze – ať už SQL nebo NoSQL. Držet je jenom v paměti webového serveru není dobrý nápad, protože o ně přijdete při prvním ukončení serveru (třeba kvůli aktualizaci).

Když dojde k normálnímu ukončení, tak aplikace dostane zprávu předem - tj. data může uložit.

Neuložení dat však příliš nevadí - při nejhorším nějakým uživatelům ukážeme nějaké produkty vícekrát, než chceme.

i to nejpomalejší počítání bude pořád o několik řádů rychlejší, než zbytečné načítání dat z  disku nebo jejich zbytečné posílání po síti.

Nemusí být pravda - zvláště na sdíleném hostingu, kde je databáze vytížená. Krom toho, když neposíláte do databáze vše ihned, nějaký provoz po síti ušetříte.

Pokud to v té NoSQL databázi nepůjde spočítat, budu řešit, jak použít lepší NoSQL databázi a ušetřit tím desítky nebo stovky milisekund. Nebudu řešit výkon CPU, abych ušetřil mikrosekundy.

Máme to takto implementované a odpověď z databáze trvá méně než 10 ms (tj. nemůžeme ušetřit desítky nebo stovky ms).

[alfonzo]

je sranda, ako tu niektori porovnavaju narocnost JVM s .NETom. Nakolko vacsina z vas tu s .NETom ani nerobi, lebo windows, lebo microsoft, hlavne ze sa vyjadruju.

[javaman ((]

Přesně. .Net je shit pro hloupé lidi z Windows světa a není žádný důvod to využívat na pořádných systémech. Stejně to o moc lepší být nemůže. JVM a Java je prostě nejlepší.