Příspěvky

706

Hardware / Re:Vyvojarska pracovna stanica i5 vs i7 z pohladu vykonu

« kdy: 04. 12. 2016, 14:04:54 »

Som programator

Ne, nejsi. Pořiď si Raspberry Pi a naprogramuj to tam. Až ti to na něm bude běhat stejně dobře jako jiným na i5, budeš programátor!

Hezky napsáno Je třeba to brát s nadsázkou, ale obecně platí, že software by měl psát maximální efektivně, bez ohledu na výkon hardwaru. Mnozí utrpěli šok, když si po uvedení prvního iPhonu museli vystačit s minimem RAM a pomalým procesorem. Výkonný HW rozmazluje. I když telefony to teď už dohnaly...

707

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu

« kdy: 24. 11. 2016, 00:41:23 »

Aneb opět jsme u monád a potažmo FP

Spíš u algebraických datových typů. IMO by tohle klidně do non-FP jazyků přijít časem mohlo...

Ono to už v mnohých částečně je, ale průměrný javacaveman to stejně nepochopí, takže to tam je na nic...

708

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu

« kdy: 23. 11. 2016, 23:29:03 »

Pokud je v dokumentaci, že nějaká funkce null nevrací, pak ji z té funkce nejspíš nedostanu. Ale jisté to není. Jisté je, že jestli ji náhodou dostanu, tak mě chytne naprosto nepřipraveného.

Takze radsej riadite svoje rozhodovanie default hodnotami, ako by ste mali vediet, ze nedosla hodnota?  Taketo pocinanie sposobilo kopec drahych chyb. Napriklad vyskomery, co ukazovali priemernu vysku, ked boli pokazene. Alebo default booleany co spustili procesy, ked nemali. Alebo napr. sonda nasa, co zistila prebytok ozonu, miesto ozonovej diery lebo mala nastavenu default hodnotu na vysoku, a senzory nic nenamerali, lebo vrstva bola pod ich rozlisovaciu schopnosti.

Jsou jazyky, které umožňují říct "v téhle proměnné je číslo nebo null" a "v téhle proměnné je číslo". Takže například zavolám funkci "zjistiVýšku", pak zavolám funkci "otestujJestliNeníNull", která mi převede proměnnou z typu "může obsahovat null" na "vždycky obsahuje číslo" (a když obsahuje null, tak třeba vyvolá výjimku) a tuhle proměnnou následně používám. A když ji pak třeba pošlu do nějaké funkce "mámVysunoutPodvozek", tak ta funkce ví, že prostě dostane číslo a že to nikdy nebude null. Protože proměnná, která může obsahovat null je jiného typu a překladač na tom zařve.

A když pak píšeš v takovém jazyku, tak to sice trvá malinko déle (ne zas tak moc), ale když už to konečně napíšeš a přeložíš, tak máš produkční kód, který má velmi dobře ošetřené krajní případy - a to tak, že hodně věcí není potřeba testovat, protože se nemůžou stát. A stav, kdy po několika hodinách psaní kódu to konečně přeložíš, spustíš - a ono to funguje, je poměrně běžná záležitost - a když to nefunguje, tak je to spíš výjimka.

A tohle třeba Java neumí.

Aneb opět jsme u monád a potažmo FP

709

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu

« kdy: 22. 11. 2016, 21:09:45 »

Největší fór na tom je, že celá tahle tlupa pseudoodborníků je absolutněna závislá na lidech, kteří ten moloch tvoří v céčku a částečně v assembleru.

Myslim, ze doba nazrala tomu, aby soudruzi z Oracle dokazali svetu, jak je Java dobra a prepsali Javu do Javy. :-D Koneckoncu takto vznikl prvni kompilator C, tedy presne receno asi jeho druha verze, ta prvni byla asi v asembleru.

C# to už má, Java je jako vždy pozadu...

710

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu

« kdy: 22. 11. 2016, 20:14:53 »

Ono se tak trochu zapomíná, že v době vzniku Javy, každý programátor ovládal nejméně jeden assembler a běžně programoval v C, kde kritické části kódu psal v in-line assembleru. A proto vznikla Java. Aby se toto odstranilo, protože to bránilo přenositelnosti programů.

...aneb jak vylít s vaničkou i dítě

Nikoliv, jen aplikace narostly co do funkcí. C už na to nestačilo.

Ale byly jiné možnosti než vypustit do světa monstrum typu Java.

711

Studium a uplatnění / Re:Nejžádanější programátorské znalosti na českém pracovním trhu

« kdy: 22. 11. 2016, 15:08:22 »

Ono se tak trochu zapomíná, že v době vzniku Javy, každý programátor ovládal nejméně jeden assembler a běžně programoval v C, kde kritické části kódu psal v in-line assembleru. A proto vznikla Java. Aby se toto odstranilo, protože to bránilo přenositelnosti programů.

...aneb jak vylít s vaničkou i dítě

712

Vývoj / Re:Co zpomaluje Javu? A co překlad do nativního kódu?

« kdy: 14. 11. 2016, 22:53:36 »

jen me ale u javy (nejen, podobnych je vic) zarazi nedostatek kvalitnich veci v ni

Problém je, že nějak nevíme, co považujete za „kvalitní“. Chtěl jste desktopové aplikace, dostalo se vám příkladu IDE, která v té nejvyšší kategorii existují čtyři, z toho tři jsou napsaná v Javě a čtvrté v C#. A že zrovna na IDE jsou jejich uživatelé myslím dost nároční. Nezaráží vás, že v té kategorii není žádné IDE napsané v C++, že jsou jen o kategorii níž v rámci takových těch odlehčených IDE? A vypovídá to snad o něčem jiném, než jenom o tom, že C++ není jazyk vhodný pro tak komplexní aplikace, jakými IDE jsou?

Tak třeba Xcode je napsané v ObjC, což je jen preprocesor C, byť nyní zabudovaný do clangu (viz ObjC runtime). A běží o dost svižněji než Visual Studio nebo javovské bazmeky.

713

Vývoj / Re:Co zpomaluje Javu? A co překlad do nativního kódu?

« kdy: 14. 11. 2016, 20:02:30 »

Proc je Java priblizne 3x pomalejsi nez C++, cim je ta aplikace tak bzdena? A jde Javovska aplikace prelozit do nativniho kodu s rozumnymi vykonostnimi vysledky?

Pokud Javu brzdi nejvic garbage c., je mozne psat aplikaci s manualnim uvolnovanim zdroju jako v c++? Je k tomu nejaka dobra literatura?

Ještě tu v podstatě nezazněl jeden triviální důvod - záleží na kvalitě implementace JVM. Například na ARM některé i velice jednoduché benchmarky ani neproběhnout, protože buď je běh o několik řádů pomalejší, nebo jsou nepřiměřeně větší nároky na paměť. Na ARM v mnoha případech kolabuje jak OpenJDK, tak verze od Oraclu. Na ARM64 je kvalita implementace (ne)překvapivě podstatně vyšší, nicméně opravdu bez problémů je běh jen na AMD64 (pochopitelně).

714

Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?

« kdy: 13. 11. 2016, 12:54:56 »

Co když potřebuju třeba GPGPU?

JOCL?

Znám, nicméně kód využívající OpenCL bude vždy záviset na nativním kódu. A zrovna v nyní se rozmáhajícím machine learning (a obecně v AI) se GPGPU používá hodně, čímž je Java z této domény kompletně vyloučena.

715

Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?

« kdy: 12. 11. 2016, 23:36:40 »

Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Vy ste asi mysleli tento prispevok. https://forum.root.cz/index.php?topic=13854.msg179201#msg179201

[...] V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe. Defaultně se o to snaží, ale ne vždy to lze. Problém je to hlavně při fragmentaci haldy, pak si alokátor bude vytvářet objekty tam, kde je zrovna místo. Nelze to rozumně ovlivnit. Heap compaction nic moc neřeší, protože je to drahé.

Ale jasne, ze to ide aj v Jave, ved som to linkoval vyssie http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html .
Je to blog samotneho Thomsona, na ktoreho odkazuje aj Ondra Satai Nekola v tom vlakne... Takze to islo to uz 4 roky pred tou septembrovou diskusiou, LOL...

Ten blog přesně potvrzuje, co tu psal O.S.Nekola a tuším že R.Miček.

Ach, chapem, ja som predpokladal, ze vas argument je, ze to Java neumoznuje. A moj protiargument bol, ze to umoznuje, za cenu, ze si musite alokovat blok pamate mimo heap cez Unsafe, inymi slovami presne to iste, co je v predmetnom algoritme napisane v C. Predpokladam, ze toto je ten algoritmus
https://forum.root.cz/index.php?topic=13854.msg179103#msg179103 . Cize cele to bolo o tom, ze si allocujete jeden suvisli blok pamate, teda pocet * velkost structov Point. Ja to chapem tak, ze presne to sa da urobit a presne to je predmetom toho blogu. C-cko ziadnu typesafety nema, takze porovnavat Javovsky ArrayList/array referenci nema zmysel. Porovnavat suvisli blok alokovanej pamate z Javy cez Unsafe a struct Point *points = malloc(ARR_LEN * sizeof(struct Point)) sa moze? Spravne to chapem?

Ne, to není ten algoritmus, a nešlo o souvislou alokaci, ale o použití objektů alokovaných na zásobníku v kolekcích, což v Javě nejde ani s použitím unsafe, jež se tu taky řešilo a místní Java bumboys ho nazvali prasárnou. Jinak univerzálně přenositelný kód - pokud někomu nevoní POSIX - lze psát v Go včetně jednoduché kroskompilace.

716

Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?

« kdy: 12. 11. 2016, 23:30:54 »

Jen nejsou tak dobré. Plno skriptovacích věcí běží všude, ale kdo by chtěl dělat v jazycích na malé skriptíky. Plus jsou obvykle brutálně pomalé.

Java je ale z takych jazykov najrychlejsia.

c se dá zkompilovat všude.

To by som netvrdil.  Staci skusit zobrat projekt z linuxu a bezo zmien ho skompilovat trebars pod cygwin. Clovek z toho zosedivie.

Pokud v Javě používáte nativní knihovny nebo kód specifický pro platformu, dopadnete stejně. Jediná výhoda Javy je, že můžete distribuovat software bez zdrojových kódů.

Pokud ...  V Jave to byva skor vynimka, kdezto v C je to pravidlo. Vacsinou, ak je Java vyvojar aplikacie prasa a pouziva nejaku platformovo zavislu kniznicu, byva tak jedna v celom projekte. Kdezto programy zlozitejsie nez hello world v C sa zavislostami na platforme hemzia. Pri lenivom programatorovi to skonci pribalenim emulacie posix-u, alebo windows api do projektu. Pri menej lenivom programatorovi sialenymi ifdefmi.

Co když potřebuju třeba GPGPU? Jinak s C jsem nikdy problémy neměl, ale ono to je o zkušenostech, žádný učený z nebe nespadl a psát dobrý kód se člověk učí s časem (nicméně při dodržení POSIXu a nějakého toho BSD API by neměl být problém).

717

Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?

« kdy: 12. 11. 2016, 22:28:56 »

Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Vy ste asi mysleli tento prispevok. https://forum.root.cz/index.php?topic=13854.msg179201#msg179201

[...] V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe. Defaultně se o to snaží, ale ne vždy to lze. Problém je to hlavně při fragmentaci haldy, pak si alokátor bude vytvářet objekty tam, kde je zrovna místo. Nelze to rozumně ovlivnit. Heap compaction nic moc neřeší, protože je to drahé.

Ale jasne, ze to ide aj v Jave, ved som to linkoval vyssie http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html .
Je to blog samotneho Thomsona, na ktoreho odkazuje aj Ondra Satai Nekola v tom vlakne... Takze to islo to uz 4 roky pred tou septembrovou diskusiou, LOL...

Ten blog přesně potvrzuje, co tu psal O.S.Nekola a tuším že R.Miček.

718

Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?

« kdy: 12. 11. 2016, 13:39:14 »

což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Nevyhrala to nahodou Java, lebo niekto v C++ zvolil horsi grafovy algoritmus?
Vyhrava lepsi algoritmus. A vo tom to je.

Ne, byl to stejný algoritmus (logicky), nějaký matematický výpočet nad vektory, nepamatuju si přesně detaily, ale ten kód někde mám, pamatuju si, že jsem to přepisovat ještě do Go a Swiftu. Java bumboys reagovali tím, že to není fér, protože Java neumí alokovat na zásobníku, což ovšem byla celá pointa zmiňovaná od začátku, takže vlastními slovy potvrdili, co ostatní říkali. Celé to má ještě více aspektů, jako běh při akutním nedostatku paměti nebo na ARM, ale i na amd64 s 64GB RAM to Java prostě nedá kvůli JVM.

719

Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?

« kdy: 12. 11. 2016, 11:23:11 »

Kdo zná Javu a jeden z moderních jazyků typu C(++), C#, Go nebo Swift, snadno napíše microbenchmark, co Javu roznese na kopytech.

V případě C/C++ to zcela jistě neplatí. Dnes používané JVM jsou totiž napsané právě v C/C++, takže každý výsledek běhu benchmarku pro Javu je zároveň i výsledkem pro C/C++. Asi budete oponovat, že se daná úloha dá v C/C++ napsat efektivněji, než že si vytvoříte vlastní jazyk, pro něj napíšete kompilátor a VM, a v tom jazyce pak tu úlohu vyřešíte. Ano, to je v mnoha případech pravda, zejména u microbenchmarků (a ve značné části reálných případů to pravda není, zejména pokud už ten jazyk a nástroje nutné pro běh vytvořil někdo před vámi – jak ukazuje obliba mnohých jazyků jako Java, Python, JavaScript, PHP a mnohé další). Jenže o efektivitě vy jste nic nepsal. (A také by záleželo na tom, která efektivita vás zajímá – paměťová při běhu programu, doba běhu programu, celková náročnost na zdroje, efektivita vývoje…) Vy byste prostě z množiny všech možných hloupých i dobrých řešení náhodně vybral jedno pro každý implementační jazyk, a ta byste porovnal. Výsledek by ovšem byl zcela náhodný a nevypovídá vůbec o ničem. Nanejvýš ho nějaký mysteriózní tazatel použije ve svém dotazu, když se mu nebude chtít generovat náhodné číslo – kolikrát je něco rychlejší nebo pomalejší – jiným způsobem.

Zcela jistě to platí. Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

720

Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?

« kdy: 12. 11. 2016, 04:29:58 »

Proc je Java priblizne 3x pomalejsi nez C++, cim je ta aplikace tak bzdena? A jde Javovska aplikace prelozit do nativniho kodu s rozumnymi vykonostnimi vysledky?

Pokud Javu brzdi nejvic garbage c., je mozne psat aplikaci s manualnim uvolnovanim zdroju jako v c++? Je k tomu nejaka dobra literatura?

V podstatě jen jedna věc - alokace všeho na haldě (už se to tu řešilo). GC sám o sobě nevadí, Go má plně automatický GC a rychlostí je na úrovni C. Kdo zná Javu a jeden z moderních jazyků typu C(++), C#, Go nebo Swift, snadno napíše microbenchmark, co Javu roznese na kopytech. Jiná otázka pak je, nakolik se to projevuje v reálných úlohách. Tvůrci Javy si jsou problému vědomi, už plánují nápravu (v Javě 9 nebo 10). (GC je velkou brzdou jen v případě akutního nedostatku paměti, například při běhu na mobilech; pokud je k dispozici násobně více paměti než vyžaduje algoritmus, GC se na rychlosti neprojeví - toto je empirický akademický výsledek).