Příspěvky

4246

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 18. 09. 2016, 10:33:04 »

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.

4247

Software / Re:Jak ověřit podepsaný PDF soubor?

« kdy: 18. 09. 2016, 09:54:13 »

Pro podepisování PDF používám již uvedený http://jsignpdf.sourceforge.net/, někdy jsem s ním neměl problém.

4248

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 18. 09. 2016, 09:52:08 »

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.

4249

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 17:15:53 »

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

4250

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 16:42:51 »

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.

4251

Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET

« kdy: 17. 09. 2016, 15:44:25 »

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.

4252

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 15:21:02 »

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.

4253

Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET

« kdy: 17. 09. 2016, 13:50:01 »

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.

4254

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 13:48:04 »

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

4255

Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET

« kdy: 17. 09. 2016, 13:21:14 »

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.

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

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.

4256

Vývoj / Re:Souborová databáze pro Windows/Linux (JAVA, Survival Boy)

« kdy: 17. 09. 2016, 11:23:30 »

Pokud to má být SQL databáze, pak Apache Derby (je jako JavaDB součástí Oracle JDK od verze 7), H2 nebo HSQLDB.

Ale záleží na tom, jak databázi používáte, možná by byly lepší nějaké NoSQL databáze, třeba ModeShape, MapDB , Xodus nebo Neo4j.

4257

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 11:05:59 »

A je opravdu pole malých věcí něco tak vzácného? Já mám pocit, že se s ním setkávám skoro furt.

Jenže tady řešíme něco mnohem vzácnějšího – častou iteraci přes pole malých struktur (tj. ne primitivních typů), která ovšem programátorovi nestojí za optimalizaci.

4258

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 11:01:22 »

Situací, kdy potřebujete pracovat s dvojicemi id a číslo je celá řada. Např. obyčejný e-shop chce nabízet produkty, které by se zákazníkovi mohly líbit - tj. pro každého zákazníka tam může mít seznam (id produktu, skóre) a z něj chce vždy vybrat např. 5 nejoblíbenějších produktů (s nejvyšším skóre), které zákazníkovi nebyly ukázány více než 4x (na to mj. potřebuje i mapu, id produktu -> kolikrát byl ukázán; pro níž byste v Javě opět nemohl použít standardní kolekci, pokud vám jde o alokaci paměti a výkon).

Obyčejný e-shop data o všech produktech, o všech objednávkách zákazníka a statistiky zákaznického chování drží v paměti webového serveru. Aha. Proto se nemůžeme domluvit, protože v mém světě má e-shop tahle data v SQL databázi, případně něco v NoSQL.

Takže to, že se dá prasit v každém jazyce a spousta lidí to dělá nějak vyplývá, že je to OK?

Ne, z toho vyplývá, že když to někdo naprasí v nějakém jazyce, není to nutně chyba toho jazyka.

Samozřejmě že to má vliv. Ale není to na první pohled vidět, protože ten vliv je rozprostřený po celém programu. Profiler neukáže, že to někde drhne, protože to drhne +- všude.

Jestli procesor stráví v idle 40 % nebo 50 % času je úplně jedno.

Pokud to nemá žádný vliv, tak proč se v současné době tolik řeší Data-Oriented-Design?

Protože se tolik neřeší. Řeší se pouze ve specifických případech.

Jinak původně se tazatel ptal na porovnání webhostingů pro Javu a .NET z hlediska využití zdrojů. Pořád se bavím tou představou, jak webhoster chce poskytnout hosting pro WAR aplikace, ale pak si uvědomí, že ty aplikace určitě budou neefektivně využívat CPU cache, tak radši zvolí .NET.

Obzvláště použití streamů na běžné pořád opakované úkony kód zkracuje a zpřehledňuje. Pokud to interně v JVM pojede jako pole intu, jedině dobře.

Myslíte rozhraní java.util.stream.IntStream?

4259

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 17. 09. 2016, 10:48:01 »

Ale pokud ten seznam dává smysl

Ano, to je to klíčové. Porovnávat programovací jazyky podle jedné miliardtiny způsobu jejich využití je nesmysl.

4260

Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET

« kdy: 17. 09. 2016, 10:29:37 »

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

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

Víte, proč výsledná rychlost programu obecně nezávisí na zvoleném programovacím jazyce? Protože Java programátoři nemají přístup k nízkoúrovňovým věcem a neznají detaily fungování JVM, takže tohle neřeší; zatímco C++ programátoři si myslí, že používají jazyk, který optimalizuje sám od sebe, takže to taky neřeší.

Tím, že Java nemá hodnotové typy a všechno je reference, úplně brutálně mrhá tím nejomezenějším zdrojem dnešních PC - velikostí cache a propustností sběrnice.

Vzhledem k tomu, že to na výkon programů nemá žádný vliv, tak je to jedno.