Vytváření aplikačních systémů Unix-like metodou

[Kit]

300 ms je pomalá sračka, to je tak dobré u prototypu. Kdyby se takhle opravdu dělalo v Javě, tak to není nejpopulárnější jazyk.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

[Reklama]

[Franta <xkucf03/>]

300 ms je pomalá sračka, to je tak dobré u prototypu. Kdyby se takhle opravdu dělalo v Javě, tak to není nejpopulárnější jazyk.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Spustit se dá za cca 100 ms – zde např. ukázka mého programu, když vypisuje verzi:

$ time sql-dk --version
SQL-DK
Mercurial: eb1ca1395ab3+ tip
Compiled:  2016-11-09 00:15:39+01:00

Copyright © 2013 Ing. František Kučera a.k.a. <xkucf03/>
https://sql-dk.globalcode.info/ https://frantovo.cz/
SQL-DK is free softare. You may redistribute copies of SQL-DK
under the terms of the GNU General Public License v3+.
For more information about these matters, run with option: --license

real    0m0.111s
user    0m0.108s
sys     0m0.028s


$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

$ cat /proc/cpuinfo |  grep "model name" | head -n1
model name      : AMD FX(tm)-8350 Eight-Core Processor

Jasně, oproti C je to pomalé a taky to takhle nebude chodit třeba na nějakém slabém ARMu, ale i tak jsou dnes ty rychlosti úplně někde jinde, než si myslí lidi, co na Javu obvykle nadávají a zasekli se někde v 90. letech.

[javaman ()]

300 ms je pomalá sračka, to je tak dobré u prototypu. Kdyby se takhle opravdu dělalo v Javě, tak to není nejpopulárnější jazyk.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.

[javaman ()]

Pořád nechápu, proč by někoho mělo spouštění zajímat. Java si natahuje hromady věcí, které potřebuješ a často ani nepotřebuješ za chodu. U velkých aplikací je ten poměr lepší a chceš mít hodně funkcionality.

Hlavně tenhle "problém" řeší i Java 9, takže pak už nevím, co hateři zase vymyslí

[JS]

Tohle provozuji v OOP zcela běžně a funguje to skvěle. Objekty se tak stávají virtuálními procesory, které se konfigurují v konstruktoru či jiném builderu a kterými data protékají v podobě strukturovaných či objektových zpráv.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Unixová filosofie je v dnešní době naopak výhodná, neboť každý dílčí proces může běžet v samostatném jádře. Lépe se tedy využije HW vícejádrových procesorů nebo i více serverů.

O tom moje namitka vubec neni. Paralelismus se da realizovat mnoha zpusoby, vertikalne i horizontalne.

[Reklama]

[Kit]

300 ms je pomalá sračka, to je tak dobré u prototypu. Kdyby se takhle opravdu dělalo v Javě, tak to není nejpopulárnější jazyk.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.

Nejprve jsi napsal, že 300 ms je pomalá sračka a teď píšeš, že čas spouštění nikoho nezajímá. Tak si to laskavě nejdřív srovnej a pak piš.

[gll]

P zjisti, ze z Pythonu muze mit pristup k mnoha jiz existujicim vytvorenym utilitkam, ktere mu muzou pomoct rychle zpracovat nektere vypocetne narocnejsi tasky.

To se už dávno používá, protože Python sám o sobě je hodně pomalý, jeden z nejpomalejších jazyků vůbec. Všechny ty "vědecké výpočty v Pythonu" spočívají v tom, že se pomocí Pythonu lepí dohromady céčkové knihovny, které dělají ten vlastní výkonově náročný výpočet. Je to docela dobrý přístup - v Pythonu se píše rychle a pohodlně a céčková implementace tomu dodá patřičný švih. Akorát ten GIL to trochu hatí

...ale přes roury s lidsky čitelnou serializací se to fakt nedělá, to by ses daleko nedostal...

Roury mohou být užitečné. Zejména při práci s velkými soubory. Ale určitě ne tak univerzální jak píše anonym.

V c api se dá pracovat s iterátory, ale je to dost komplikované. Jednodušší je použít oddělenou utilitu.

[javaman ()]

300 ms je pomalá sračka, to je tak dobré u prototypu. Kdyby se takhle opravdu dělalo v Javě, tak to není nejpopulárnější jazyk.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.

Nejprve jsi napsal, že 300 ms je pomalá sračka a teď píšeš, že čas spouštění nikoho nezajímá. Tak si to laskavě nejdřív srovnej a pak piš.

Někdo psal, že 300 ms čeká na odpověď. Odpověď by měla být v řádu milisekund a méně. Samozřejmě záleží na složitosti, ale stovky milisekund je hodně mimo reálné použití.

[gll]

Tohle provozuji v OOP zcela běžně a funguje to skvěle. Objekty se tak stávají virtuálními procesory, které se konfigurují v konstruktoru či jiném builderu a kterými data protékají v podobě strukturovaných či objektových zpráv.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Novější PHP má pro tohle generátory a coroutiny.

[Kit]

300 ms je pomalá sračka, to je tak dobré u prototypu. Kdyby se takhle opravdu dělalo v Javě, tak to není nejpopulárnější jazyk.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.

Nejprve jsi napsal, že 300 ms je pomalá sračka a teď píšeš, že čas spouštění nikoho nezajímá. Tak si to laskavě nejdřív srovnej a pak piš.

Někdo psal, že 300 ms čeká na odpověď. Odpověď by měla být v řádu milisekund a méně. Samozřejmě záleží na složitosti, ale stovky milisekund je hodně mimo reálné použití.

Z Vimu spustím program napsaný v Javě a na jeho výsledek, který se vrací zpět do Vimu, jsem nejprve čekal 300 ms od povelu ke spuštění. Proto jsem to překompiloval v gcj, aby se to spouštění urychlilo. Teď je to o něco rychlejší, to čekání už není tak hrozné.

Je jasné, že kdyby ten javovský program byl už v paměti jako démon, bylo by to rychlejší.

[javaman ()]

Z Vimu spustím program napsaný v Javě a na jeho výsledek, který se vrací zpět do Vimu, jsem nejprve čekal 300 ms od povelu ke spuštění. Proto jsem to překompiloval v gcj, aby se to spouštění urychlilo. Teď je to o něco rychlejší, to čekání už není tak hrozné.

Je jasné, že kdyby ten javovský program byl už v paměti jako démon, bylo by to rychlejší.

Tyhle píčoviny nikoho nezajímaj. Řešilo se úplně něco jiného, pokud se nepletu. A pokud se pletu, tak je to jedno, protože jen retard bude pouštět program pořád dokola, který má několik mega závislostí pro spuštění.

[Kit]

Tohle provozuji v OOP zcela běžně a funguje to skvěle. Objekty se tak stávají virtuálními procesory, které se konfigurují v konstruktoru či jiném builderu a kterými data protékají v podobě strukturovaných či objektových zpráv.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Ve FP se těm "virtuálním procesorům" spíš říká closures nebo currying, ne? Nezapomeň, že se ten virtuální procesor musí nejprve nakonfigurovat (nejlépe konstruktorem) a pak teprve je možné ho používat.

V OOP se těm "strukturovaným zprávám" také říká argumenty. Napsal jsem to takhle, aby sis nemyslel, že objektům jako argumenty posílám nějaké primitivní datové typy (jak je dnes bohužel běžné u *etterů). Jsou to prostě zprávy, na kterých je OOP založeno.

[Kit]

Z Vimu spustím program napsaný v Javě a na jeho výsledek, který se vrací zpět do Vimu, jsem nejprve čekal 300 ms od povelu ke spuštění. Proto jsem to překompiloval v gcj, aby se to spouštění urychlilo. Teď je to o něco rychlejší, to čekání už není tak hrozné.

Je jasné, že kdyby ten javovský program byl už v paměti jako démon, bylo by to rychlejší.

Tyhle píčoviny nikoho nezajímaj. Řešilo se úplně něco jiného, pokud se nepletu. A pokud se pletu, tak je to jedno, protože jen retard bude pouštět program pořád dokola, který má několik mega závislostí pro spuštění.

Aha, zřejmě jsi ještě nepoužil Javu jako CLI. Prostě se spustí JRE s nějakým JARem, předají se mu pípou nějaká vstupní data a ve výstupní pípě dostaneš výsledek. Tohle mi za normálních okolností zabere těch 300 ms a program končí. S gcj se to zkrátilo na přijatelný čas.

O jakém mega závislostí to píšeš?

[Kit]

Tohle provozuji v OOP zcela běžně a funguje to skvěle. Objekty se tak stávají virtuálními procesory, které se konfigurují v konstruktoru či jiném builderu a kterými data protékají v podobě strukturovaných či objektových zpráv.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Novější PHP má pro tohle generátory a coroutiny.

To sice ano, ale pro vlastní virtuální procesor se specifickými vlastnostmi si ten generátor musíš napsat sám. Říká se tomu třída

[Mirek Prýmek]

Roury mohou být užitečné.

Roury jsou užitečné - ale na to, na co se používají, ne v té znásilněné podobě, kterou navrhuje anonym.

Pokud chci, aby něco bylo rychlé, nesmím data často převádět z jedné reprezentace na jinou. Častá serializace a následná deserializace je spolehlivý zabiják výkonu (to je i slabé místo těch microservices, zvlášť pokud se použije http a json, což je teď móda). A úplně ideální je s datama ani nehejbat - radši pamět sdílím než kopíruju.

Čili anonym to možná myslí dobře, ale vymýšlí prostě hranaté kolo. Lepší by bylo si nastudovat existující používané architektury a případně přemýšlet nad tím, jak je vylepšit, než si myslet, že všichni na světě jsou pitomci, všechno dělají blbě a já teď vyřeším všechny problémy světa zcela geniálním způsobem, kterej ještě nikdy nikoho nenapadl