Příspěvky

3931

Vývoj / Re:Částicový filtr na Raspberry Pi v Javě

« kdy: 27. 05. 2017, 13:21:11 »

V kódu nemáte třídu Complex, takže můžeme spíš jen hádat.

Matici máte uloženou jako jedno velké pole, takže v paměťovém prostoru JVM to musí být uložené jako jeden velký souvislý kus paměti. Ušetříte tím reference a mohlo by to být výhodné, pokud by se ta paměť alokovala jednou a efektivně a pak už se s tím nemuselo hýbat. Vy to pole ale při volání exp() alokujete pokaždé znova. Takže bych zvážil, zda nemůžete použít pool objektů Matrix, možná dokonce můžete pole modifikovat na místě a stačí vám jediná instance. Také bych zvážil změnit matici na pole polí.

A pak je tu ten tajemný typ Complex. Každý prvek matice je objekt, tedy v poli je jen reference, která ukazuje bůhvíkam do paměti. V nejhorším případě musí procesor v každé iteraci toho dvojitého cyklu čekat, až mu dorazí data z hlavní paměti. Tipoval bych, že typ Complex bude ve skutečnosti něco velmi jednoduchého, třeba dva inty. Ty by pak bylo mnohem lepší uložit přímo do pole, bez referencí – procesor pak bude mít všechny hodnoty pěkně vedle sebe a pojede po řádku cache. Sice to pak nebude hezké objektové, ale to už nemáte stejně, když tam používáte to pole a cyklus přes všechny prvky.

Když už to budete „deobjektovat“, odstranil bych i ta volání funkcí compa setComp, a pokud matici necháte jako jedno velké pole, pak bych i ten dvojitý cyklus přepsal na jednoduchý. Co jsem slyšel, runtime optimalizace v JVM na ARMech nejsou žádná sláva, takže bych nespoléhal, že to inlinuje JVM a udělal bych to ručně. Stejně už teď ten kód není objektový a hezký :-)

A samozřejmě, jak napsal předřečník, nejvíc ušetříte tím, pokud správně popíšete problém, který řešíte – a zjistíte třeba, že ta vaše matice není úplně obecná matice, ale má některé speciální vlastnosti, které můžete s výhodou použít pro optimalizaci.

Jinak RPi a Java je pro řízení robota zajímavá kombinace, ani RPi (předpokládám s Linuxem) ani obecná Java nejsou realtimeové systémy, není tam garantovaná odezva. Všechno může dlouho krásně fungovat, a pak Java spustí GC nebo něco naplánuje Linux a váš program se najednou zastaví na mnohem delší dobu, než obvykle. Rozmyslete si, co to s robotem udělá.

3932

Vývoj / Re:Přepsání serveru v Javě

« kdy: 26. 05. 2017, 16:04:15 »

čili obecné nástroje byly vytvořeny již dokonalé a nové/lepší nevznikají

Nikoli. Ale to, že je něco nového, ještě neznamená, že je to lepší a obecné. Navíc i spousta těch „starých“ nástrojů se pořád vyvíjí, vyvíjí se i způsob práce s nimi.

Aby to někdo špatně nepochopil, já vůbec nejsem proti novým jazykům nebo nástrojům. Pokud někdo má nějaké zadání a rozumí mu natolik, že podle něj napsal program, a teď má čas a chuť to naprogramovat znova, je to ideální příležitost pro vyzkoušení si nového nástroje nebo jazyka (a zároveň trochu past, protože se nejspíš bude pokoušet některé věci řešit stejně, jako by je řešil v tom původním nástroji – opravdový programátor v Cobolu je schopen v Cobolu programovat v jakémkoli jazyce).

Ale mírnil bych to nadšení pro přepis a pro „moderní“ jazyky. Tím, že se něco jenom přepíše, se nic nezíská (kromě nových chyb v kódu). Nic se nezíská ani tím, že se to jen přepíše do „něčeho modernějšího“. Získá se například tím, že se změní architektura – a když už se bude přepisovat architektura, může se jako vedlejší efekt zvolit i jiný jazyk.

3933

Vývoj / Re:Přepsání serveru v Javě

« kdy: 26. 05. 2017, 11:33:57 »

Než řešit výběr JVM, GC a nevím co ještě, to je fakt lepší to přepsat do něčeho moderního.

Aha, takže je lepší nejdřív řešit výběr něčeho moderního, pak se naučit něco moderního, přepsat to, a teprve pak řešit výběr VM, GC a nevím co ještě. To se opravdu vyplatí.

Víte, ono to „moderní“ buď bude specializované na tenhle typ úlohy – jenže pak musíte nejprve najít ten správný specializovaný jazyk/nástroj. Pak hrozí, že bude tak úzce specializovaný, že v něm nikdo nic nebude psát a zanikne. Nebo „jenom“ to, že už v něm vy nikdy nenapíšete nic jiného. Nebo prostě jen zůstanete v daném jazyce amatérem. Nebo to „moderní“ bude obecný nástroj, a pak jej zase budete muset nakonfigurovat pro konkrétní použití. Ono totiž vůbec nejde o to, jestli je to „moderní“ nebo „nemoderní“, ale o to, že obecné nástroje jsou prostě obecné, takže je pro konkrétní použití musíte přizpůsobit.

3934

Vývoj / Re:Přepsání serveru v Javě

« kdy: 26. 05. 2017, 07:13:28 »

Takže pokud by se to přepisovalo tak jako tak

Upravit aplikaci tak, aby nepoužívala nové vlákno pro každý požadavek, ale aby se používal pool vláken nebo asynchronní IO, přece neznamená přepsat celou aplikaci.

3935

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 18:09:01 »

Většina objektů žije jen krátce a neescapují, takže nemá smysl dávat je na haldu a pak likvidovat GC.

Což je ale něco úplně jiného, než co jste psal předtím. Jinak ty různé GC v JVM se liší mimo jiné tím, jak zacházejí s objekty, které mají krátkou životnost. Třeba se jednou dočkáte i v JVM GC, který umožní používat i zásobník.

problém Javy, resp. tedy JVM

Možná byste si měl ujasnit rozdíl mezi programovacím jazykem a virtuálním strojem – místo poučování, co by si kdo měl přečíst. Aspoň že jste to dal na dvouapůltý pokus.

3936

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 17:39:36 »

Javu jinde než nad JVM nespustím, že?

Existovaly nějaké překladače Javy, nevím, v jakém jsou stavu.

Problém Javy je, že neumožňuje nějakou aspoň pseudotransparentní alokaci dat na zásobníku.

Ne, to problém Javy není.

Kdyby tomu tak bylo, nemusel by nikdo vyvíjet kvanta různých GC a ladit je pro každou aplikaci zvlášť.

Kvanta různých GC nikdo nevyvíjí, nikdo je neladí pro každou aplikaci zvlášť, a GC nepoužívá ani zdaleka jenom Java. Vlastně bude jednodušší vyjmenovat jazyky, které běžně GC nepoužívají (ale kam se občas GC dodává jako knihovna) – C, C++, Pascal.

3937

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 16:52:44 »

Ano, ale tu funkcionalitu, o které se bavíme, mám v Erlangu přímo v runtimu.

Pořád nevidím ten rozdíl. Když na to máte funkcionalitu přímo v runtime Erlangu, tak nevadí, že v tom runtime máte také spoustu funkcionalit, které nepoužijete. Ale když tu funkcionalitu máte v knihovně, tak to najednou vadí, že je v té knihovně i něco, co vůbec nepoužijete.

Vadí to v případě, že ten balast se například musí natahovat při startu

To pak nevadí ten balast, ale to, že se natahuje při startu.

že v něm bývají chyby

Když jsou to části, které nepoužívám, může mi být úplně jedno, že jsou tam nějaké chyby.

že je to děsivý moloch, který nikdo neví, jak funguje atd. atd.

Pokud je to děsivý moloch, tak to nepoužívejte. A pokud použijete nějakou část, zbytek vás nemusí zajímat. Úplně stejně, jako když to máte implementované v runtime Erlangu.

Lidi nechtějí požadavky zahazovat. Lidi chtějí mít tak výkonné systémy, aby dokázaly všechny požadavky zpracovat - a mít i nějakou rezervu, popř. autoscaling. Zahazování by měla být nejzazší krizová možnost, není to něco, čím by kdokoli chtěl řešit problém.

Já jsem také psal o nejzazší krizové možnosti. Jenže když už k takové situaci dojde, je pořád lepší, když server zvládne obsloužit aspoň nějaké požadavky, než když je plně zaměstnán sám sebou a neodvede vůbec žádnou reálnou práci.

3938

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 16:45:16 »

Pokud v nějakém jazyce musím explicitně vybírat GC, aby mi program fungoval, tak je něco hodně špatně.

Nevím o jazyku, u kterého byste explicitně vybíral GC. Já jsem psal o JVM, což je běhové prostředí. Také vůbec nebyla řeč o tom, že by program nefungoval. Jenom bylo zmíněno podezření (v diskusi ničím nepodložené), že by GC mohl ovlivňovat výkon aplikace – pak je logické prozkoumat charakteristiku použitého GC a porovnat ji s charakteristikami jiných dostupných GC a případně GC změnit. Na tom, že je v jednom běhovém prostředí dostupných více implementací GC, není nic špatného – každý se chová trochu jinak a hodí se tak pro jiný typ úloh. Například Linux má několik implementací plánovačů procesů, několik implementací plánovačů IO, několik implementací souborových systémů – obecně je to považováno za plus, protože si každý může vybrat, co zrovna on potřebuje, a není odkázán na jedno one size fits all řešení, které bude ve všech případech stejně špatné.

3939

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 15:55:00 »

Jo, může být. Akorát frameworky a knihovny (obzvlášť "enterprise" v Javě) vždycky hrozí dalším bobtnáním a hromadou balastu, kterou člověk nevyužije...

To ale platí skoro o všech knihovnách a nástrojích – i s Erlangem nebo i s glibc dostanete spoustu balastu, který váš program nevyužije. Ale vadí to něčemu? Tohle budete řešit maximálně u mikrokontrolerů s omezenou pamětí, a to je evidentně jiný typ úloh, než jaký se tu řeší.

Tím, že můžu stanovit horní limit počtu obsloužených requestů? To většinou pochopitelně nikdo nechce.

Chce a fronty to právě řeší. Pokud zvládnete zpracovat 1 požadavek za sekundu, můžete začít zpracovávat první požadavek, dalších třeba 5 může čekat ve frontě a další přicházející požadavky můžete odmítat. Tím zajistíte, že se bude zpracovávat aspoň ten 1 požadavek za sekundu, a když se jich náhodou sejde o něco víc, tak si chvíli počkají, ale nakonec se to tím tempem 1 požadavek/s zpracuje. Což je pořád podstatně lepší situace, než když přijmete 50 požadavků, veškeré zdroje vyčerpáte jenom na jejich příjem a už vám nezbydou zdroje na zpracování ani jediného požadavku.

Rozdíl je v paměťové náročnosti.

„Procesy“ v Erlangu jsou velmi lehké, nejsou to skutečné procesy OS – nemyslím, že by byly paměťově nějak náročné.

3940

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 13:40:48 »

Čili má člověk optimalitu poolu zadarmo, aniž by nějaký pool, fronty, zamykání atd. musel řešit.

To samé platí i při použití vhodných frameworků nebo knihoven.

3941

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 12:48:57 »

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

tak by Erlang rozhodně pomohl

Podstatné bylo to „pokud ta vlákna skutečně něco dělají“. Pokud je ten server přetížený tím, že má moc práce, nepomůže to, že budete práci jiným způsobem přerozdělovat. Tam je řešením jedině řadit požadavky do fronty a nepřijímat další požadavky, pokud je fronta moc dlouhá.

Přerozdělení pomůže jedině tehdy pokud ta vlákna ve skutečnosti nic moc nedělají a většinu času tráví čekáním. Pak může pomoci koncepce procesů použitá v Erlangu, a nebo třeba asynchronní zpracování v Javě – když se vlákno dostane do bodu, kde má na něco čekat, vlákno se uvolní a začne zpracovávat něco jiného. A teprve když je ten požadavek, který způsobil čekání, vyřízen, nějaké vlákno dostane ke zpracování odpověď.

3942

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 11:43:34 »

Prvotní "chyba" je v návrhu, protože každý požadavek se řeší v samostatném vlákně

To by vyřešilo použití běžného serveru nebo frameworku, které mají pool vláken, která zpracovávají spojení. Případně, pokud zpracování tráví hodně času nějakým čekáním, můžete využít asynchronní zpracování – nativně s Netty, podporu pro to má i Spring.

ale stejně bych čekal, že GC si s tím poradí lépe

Jste si jistý, že to souvisí s GC? Nebylo by pak řešením použít jiný GC?

Jinak problém asi taky může být, že implementace SSL nad ARM je relativně pomalá.

To je to, co jsem psal na začátku – nejprve zjistit, v čem je problém. Jestli je to velké množství vláken, GC nebo pomalé SSL jsou diametrálně odlišné věci.

Myšlenka v pozadí je opustit Javu, nemyslím, že tady přináší nějaké výhody.

Taky nepřináší žádné nevýhody. A výhodou je podle mne velké množství knihoven a frameworků, které můžete jenom vzít a použít – a můžete se soustředit na to, co je specifické pro vaši aplikaci.

3943

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 10:40:56 »

Začněte tím, že zjistíte, co způsobuje ty problémy. A pak tu danou věc buď opravte (pokud je to chyba), nebo vymyslete jiný způsob řešení (pokud je to věc návrhu). Pokud jenom současnou aplikaci přepíšete do jiného jazyka, skončíte (v lepším případě) s aplikací, která bude mít úplně ten samý problém.

Pokud to chcete přepisovat, můžete použít např. Spring (a Spring Boot), kde už máte podporu pro webové služby, JSON i přístup k databázím, IPC záleží na implementaci. Nebudete se pak muset věnovat infrastruktuře aplikace a budete se moci soustředit na její jádro. Případně, pokud byste chtěl optimalizovat síťovou vrstvu, doporučuju použít framework Netty, který je postavený nad NIO a odstíní vás od komplikací síťové komunikace.

To, že to máte napsané přímo nad standardní knihovnou a nepoužíváte žádný framework ani knihovny, je podle mne největší slabina, protože pak se vysilujete na řešení něčeho, co už dávno před vámi vyřešil někdo jiný (a nejspíš lépe).

Pokud si jenom chcete vyzkoušet přepsat to do něčeho jiného a je vám jedno, do čeho, zaměřil bych se na jazyky, které míří tímhle směrem, jak napsal „v“, do výčtu bych přidal třeba ještě Rust. Node.js na to podle mne není vhodný, ten je vhodný pro prototypování nebo izomorfní aplikace, ale není orientován na výkon pod zátěží. V čistém C bych to nepsal – to byste se opět vysiloval nad něčím, co je už dávno vyřešené. A než to řešit nějakým frameworkem v C, spíš bych zvolil jiný jazyk, protože tím získáte podporu nejen ze strany knihovny, ale i ze strany jazyka a překladače.

3944

Windows a jiné systémy / Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.

« kdy: 21. 05. 2017, 19:48:37 »

melo by to byt utazeno pokud mozno co nejvice

Zkuste být konkrétnější. A taky napište, kdo by pak takovou službu kupoval.

Nelze se spolehat na bezpecnost aplikace. To bysme potom mohli rici, ze aplikace se postara o veskerou bezpecnost.

Ano, aplikace se musí postarat o veškerou bezpečnost. Nelze nebezpečnou aplikaci obecně zabezpečit zvenčí – vždycky někdo vymyslí nějaký nový způsob, jak udělat aplikaci nebezpečnou. Ostatně, kdyby to šlo udělat z venčí, proč by operační systém vůbec umožňoval něco jiného? Napište ten váš operační systém, ve kterém nepůjde provozovat aplikace nebezpečným způsobem, a bude z vás miliardář.

mnou uvadena zranitelnost, protoze je to konfiguracni chyba

Povolený zápis do databáze, který může mít úplně stejné důsledky, také považujete za konfigurační chybu?

3945

Windows a jiné systémy / Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.

« kdy: 21. 05. 2017, 18:28:38 »

Vždy je předpoklad, že zapisuje na lokální filesystém (jinak bych tam nemohl jako útočník nic nahrát, že

To je chybný předpoklad. Pokud ta aplikace bude zapisovat do databáze, může vzniknout úplně stejný problém. Typický příklad je script injection – třeba diskusní fórum, kde bude moci útočník vložit do svého příspěvku javascriptový kód, který se následně provede v kontextu diskusního fóra všem, kteří se na příslušnou webovou stránku podívají. A samozřejmě – v závislosti na aplikaci – v té databázi může být uložen i kód, který může provádět server. Doufám, že nebudete dál hájit svůj přístup a tvrdit, že v tom případě nemá Azure AppService povolit ani zápis do databáze.

a) aplikace je děravá, tzn. nějakým způsobem, třeba pomocí get/post parametrů jsem ji schopen manipulovat

Pak je potřeba tuhle chybu opravit.

b) aplikace má úmyslně nějaký interface ke správě souborů, třeba fotek a spoléhá se, že OS zajistí práva na složky (je to nejjednodušší, jak to napsat a bude to typicky problém, když použiju knihovnu třetí strany, o které nic nevím)
c) v administračním rozhraní aplikace je úmyslně nejaký filebrowser pro adminy aplikace, aby mohli něco dělat na filesystému - tady pozor, admin interface běží třeba i na jiném portu a nemá k němi nikdo jiný než aplikační admin přístup.
d) není nijak omezen typ souboru, který můžu na filesystém uložit

Buď k tomu mají přístup jen důvěryhodní lidé, a u těch se předpokládá, že škodit nebudou. A samozřejmě je nutné zabezpečit, že se k tomu rozhraní nedostane nikdo nepovolaný. Naopak, kdyby web server nepovoloval zápis souborů, budou tyhle funkce b) až d) úplně k ničemu.

tyhle požadavky se dají velmi snadno splnit. Ještě 5 let zpátky je splňovala každá druhá apka.

Což je problém těch aplikací a je nutné jej opravit v té aplikaci. Na úrovní webového serveru to není řešitelné – jak jsem psal výše, když aplikaci zakážete zapisovat do souborového systému, upraví to programátor tak, aby to zapisoval do databáze, a udělá tam úplně tu stejnou chybu.

nemít zápis práva na www root

To není ochrana, je to pojistka pro případ, kdy primární ochrana (v aplikaci) selže. A často tahle pojistka není použitelná. Např. byste asi marně hledal veřejný PHP webhosting, kde web server nemá právo zápisu do adresářů, odkud se servíruje obsah – protože by si uživatelé stěžovali, že jim tam nefunguje spousta aplikací.

tohle je léta uznávaný "security best practice" a každý web server, když ho vydeplojuji, má dnes takto práva nastavená.

Tohle si můžete nastavit na svém serveru, když víte, jaké požadavky má aplikace, kterou tam budete instalovat. Na veřejném hostingu je to neprůchozí.

Vy co updatujete Wordpress automaticky, že jste to museli nějak prasit, aby vám to fungovalo?

Vždyť to máte napsané v závěru toho vašeho blogového zápisku. Standardní právo write pro vlastníka, tedy pro webový server. Funguje to tak na každém veřejném PHP webhostingu. Takové ty vaše větičky o tom, jak byste se měl dovzdělávat, už si jistě doplníte sám.