C# alebo Java?

[Tomas Lipsky]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++. Zatímco C# má hromadu vlastností, které toto umožňují (např. hodnotové typy, reifikovaná generika, reference, Span). Podívejte se třeba, jak zoufalý výkon má Apache Spark (a to i přesto, že na mnoha místech sáhl k unsafe trikům).

Nebudu komentovat nic, co souvisi s vykonem Hadoop, Spark, Pig a cimkoliv z tehle rodiny. Kde je tam problem jsem psal uz v dobe, kdy tyhle veci vznikaly a chyba neni v Java.

Krom toho, Java nemá žádnou použitelnou a používanou GUI knihovnu pro desktop.

V tehle oblasti se nepohybuju. Jen si jako pragmatik rikam, jestli maji podobne knihovny vubec jeste nejaky vyznam v dobe dotykovych zarizeni, kde vladne Android se svym Linuxem a Javou premalovanou na Dalvik.

[Reklama]

[Wavelet]

Pro začátečníka bych vybral Javu, pro výuku je o dost jednodušší.

Blbost, c# je jednodušší. Teoretizujes. C# má mnohem přehlednější knihovnu a dokumentaci.

Proc tedy Google, Linkedin, Facebook, ale dalsi jako treba Amazon, a vubec vsechny velke firmy precpane kvalitnimi vyvojari pouzivaji Java na nejdulezitejsich mistech svych infrastruktur? Bezi na tom rozsahle systemy od IoT a mobilnich platforem az po Big Data. Vzdycky me zajimalo jak studenti s pramalem zkusenosti dojdou k tomu, ze je c# lepsi nebo dokonce jednodussi. Jejich zdrojem je jen to, ze jim to rikali kamaradi, vesmes proto, ze neznaji do hlubky nic jineho.

PRESNE TAK! to su tie "core veci" o ktorych som hovoril vyssie. Take Go je tam uplne irelevantne Ja viem ze Google to pouziva na svoje "core veci" niekde, ale skuste to brat v suvislostiach, Go je uplne nevyznamny jazyk.

Tak z nějakého důvodu Google go vytvořil a například pro jejich core bysnys AdWords používá dart. A jeho nejnovější knihovna pro tvoru UI flutter taky není v jave ale v dartu. A pro Android zase zavedl Kotlin. Osobně z toho mám pocit že Google dělá vše proto aby se javy zbavil a nedivím se, když se s Oraclem soudí. Ale uznávám, že to je jen můj osobní pocit.

Go je minimalistický, extrémně pragmatický jazyk, ain’t have no fancy shit. Navrhnout něco tak, aby to bylo jednoduché a zároveň funkční, je nejtěžší.

Zboji jsi to ty? Pan Géomètre 

[Kit]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++.

Blbost. Když to někdo neumí, tak to ještě neznamená, že to nejde.

[Radek Miček]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++.

Blbost. Když to někdo neumí, tak to ještě neznamená, že to nejde.

To je pravda. Nicméně ten váš argument ani neznamená, že to rozumně jde. A kdyby to rozumně v Javě šlo, proč se už roky uvažuje o přidání hodnotových typů do JVM a Javy?

[hurvajs]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++.

Blbost. Když to někdo neumí, tak to ještě neznamená, že to nejde.

To je pravda. Nicméně ten váš argument ani neznamená, že to rozumně jde. A kdyby to rozumně v Javě šlo, proč se už roky uvažuje o přidání hodnotových typů do JVM a Javy?

To sice výkon zlepšit může, ale nikoliv natolik aby to v oblastech, kde to hraje roli -- hrálo roli.
Stejně tak má .NET podporu SIMD -- viz System.Numerics a žádná revoluce např. v game engineech se nekoná.

[Reklama]

[Radek Miček]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++.

Blbost. Když to někdo neumí, tak to ještě neznamená, že to nejde.

To je pravda. Nicméně ten váš argument ani neznamená, že to rozumně jde. A kdyby to rozumně v Javě šlo, proč se už roky uvažuje o přidání hodnotových typů do JVM a Javy?

To sice výkon zlepšit může, ale nikoliv natolik aby to v oblastech, kde to hraje roli -- hrálo roli.
Stejně tak má .NET podporu SIMD -- viz System.Numerics a žádná revoluce např. v game engineech se nekoná.

Při zpracování velkých dat to zvýší výkon několikanásobně (v C# se takhle můžete vyhnout GC na miliónech objektů). A i využití paměti je efektivnější (např. na jednu položku seznamu ArrayList<Integer> v Javě spotřebujete 20-24 bajtů paměti (16 bajtů na objekt a 4-8 bajtů na referenci) zatímco v .NET na List<int> jen 4 bajty - což je 5-6x méně).

[hurvajs]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++.

Blbost. Když to někdo neumí, tak to ještě neznamená, že to nejde.

To je pravda. Nicméně ten váš argument ani neznamená, že to rozumně jde. A kdyby to rozumně v Javě šlo, proč se už roky uvažuje o přidání hodnotových typů do JVM a Javy?

To sice výkon zlepšit může, ale nikoliv natolik aby to v oblastech, kde to hraje roli -- hrálo roli.
Stejně tak má .NET podporu SIMD -- viz System.Numerics a žádná revoluce např. v game engineech se nekoná.

Při zpracování velkých dat to zvýší výkon několikanásobně (v C# se takhle můžete vyhnout GC na miliónech objektů). A i využití paměti je efektivnější (např. na jednu položku seznamu ArrayList<Integer> v Javě spotřebujete 20-24 bajtů paměti (16 bajtů na objekt a 4-8 bajtů na referenci) zatímco v .NET na List<int> jen 4 bajty - což je 5-6x méně).

To vám věřím. Otázkou je proč se tedy nepíšou věci v .NETu, když je jasně efektivnějsí. Je to jen stigma .NETu, že je od MS? A opravdu si myslíte si že by přepsání do .NETu přineslo zlepšení?

[Tomas Lipsky]

Při zpracování velkých dat to zvýší výkon několikanásobně (v C# se takhle můžete vyhnout GC na miliónech objektů). A i využití paměti je efektivnější (např. na jednu položku seznamu ArrayList<Integer> v Javě spotřebujete 20-24 bajtů paměti (16 bajtů na objekt a 4-8 bajtů na referenci) zatímco v .NET na List<int> jen 4 bajty - což je 5-6x méně).

Jenze spravne implementovany framework vyuzije prave toho, ze se predevsim nevytvari takove mnozstvi objektu, ktere krome rezie zpusobuji i implicitni vicenasobne bufferovani dat. To by u TB kolekci vedlo k neodstranitelne rezii a zbytecne ztrate vykonu. U velkych dat se predevsim pouzivaji algoritmy nad proudy dat, kterym pak staci jen male posuvne okno.

[Radek Miček]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++.

Blbost. Když to někdo neumí, tak to ještě neznamená, že to nejde.

To je pravda. Nicméně ten váš argument ani neznamená, že to rozumně jde. A kdyby to rozumně v Javě šlo, proč se už roky uvažuje o přidání hodnotových typů do JVM a Javy?

To sice výkon zlepšit může, ale nikoliv natolik aby to v oblastech, kde to hraje roli -- hrálo roli.
Stejně tak má .NET podporu SIMD -- viz System.Numerics a žádná revoluce např. v game engineech se nekoná.

Při zpracování velkých dat to zvýší výkon několikanásobně (v C# se takhle můžete vyhnout GC na miliónech objektů). A i využití paměti je efektivnější (např. na jednu položku seznamu ArrayList<Integer> v Javě spotřebujete 20-24 bajtů paměti (16 bajtů na objekt a 4-8 bajtů na referenci) zatímco v .NET na List<int> jen 4 bajty - což je 5-6x méně).

To vám věřím. Otázkou je proč se tedy nepíšou věci v .NETu, když je jasně efektivnějsí. Je to jen stigma .NETu, že je od MS?

Span je třeba celkem nový (květen 2018), takže se o něm zatím moc neví.

A opravdu si myslíte si že by přepsání do .NETu přineslo zlepšení?

Třeba v případě Sparku by to přineslo zlepšení jako přináší UnsafeRow - s tím rozdílem, že by uživatel mohl používat normální struktury a normální funkce (AFAIK s UnsafeRow nejde používat normální uživatelsky definované funkce).

[Radek Miček]

U velkych dat se predevsim pouzivaji algoritmy nad proudy dat, kterym pak staci jen male posuvne okno.

Co když data chcete setřídit nebo joinovat (tam Spark často také používá třídění)?

[tralala]

Dakujem panom expertom z rootu ze som sa dozvedel ze spark ke zufalo pomaly nejaky micek z hornej dolnrj by to asi napisal rychlejsie ale to je pre neho o nicom problem spark byva podla statistik aj 100 krat rychlejsi jak hadoop, co potom vravi micek na ten?

[Radek Miček]

nejaky micek z hornej dolnrj by to asi napisal rychlejsie

Přesně tak, kdyby mi to někdo zaplatil

Podívejte se třeba https://andygrove.io/2018/03/datafusion-0.2.1-benchmark/ - je to projekt jednoho člověka a je to asi 3x rychlejší než Spark.

Nebo se podívejte sem https://www.quora.com/Is-it-significant-to-rewrite-HDFS-Hadoop-Spark-or-HBase-in-C-C++-to-improve-computational-efficiency

Nebo třeba SnappyData http://www.snappydata.io/highlights/performance - zase to ukazuje, že Spark má poměrně velké rezervy

[hurvajs]

No, třeba udělat výkonnou aplikaci nad JVM je prakticky nemožné - musíte sáhnout k C nebo C++.

Blbost. Když to někdo neumí, tak to ještě neznamená, že to nejde.

To je pravda. Nicméně ten váš argument ani neznamená, že to rozumně jde. A kdyby to rozumně v Javě šlo, proč se už roky uvažuje o přidání hodnotových typů do JVM a Javy?

To sice výkon zlepšit může, ale nikoliv natolik aby to v oblastech, kde to hraje roli -- hrálo roli.
Stejně tak má .NET podporu SIMD -- viz System.Numerics a žádná revoluce např. v game engineech se nekoná.

Při zpracování velkých dat to zvýší výkon několikanásobně (v C# se takhle můžete vyhnout GC na miliónech objektů). A i využití paměti je efektivnější (např. na jednu položku seznamu ArrayList<Integer> v Javě spotřebujete 20-24 bajtů paměti (16 bajtů na objekt a 4-8 bajtů na referenci) zatímco v .NET na List<int> jen 4 bajty - což je 5-6x méně).

To vám věřím. Otázkou je proč se tedy nepíšou věci v .NETu, když je jasně efektivnějsí. Je to jen stigma .NETu, že je od MS?

Span je třeba celkem nový (květen 2018), takže se o něm zatím moc neví.

A opravdu si myslíte si že by přepsání do .NETu přineslo zlepšení?

Třeba v případě Sparku by to přineslo zlepšení jako přináší UnsafeRow - s tím rozdílem, že by uživatel mohl používat normální struktury a normální funkce (AFAIK s UnsafeRow nejde používat normální uživatelsky definované funkce).

Ano Span je celkem nový, podpora SIMD a RyuJIT taky... nicméně si pořád nejsem jistý, jestli by to ty nástroje zlepšilo. Daleko větší smysl by to mělo napsat v D, Rustu i v tom C++ -- takže je mi záhadou proč někdo volil/volí Javu, když je podle vás jasně neefektivní. Podle mého laického názoru proto, že je to prostě "good enough" a tam kde to nahoníte výkonem, ztratíte jinde -- hlavně nástroji. Jak se třeba profiluje v takovém .NETu? Monitoruje VM atd.? Pokud se nepletu, tak za velké peníze.

[hurvajs]

nejaky micek z hornej dolnrj by to asi napisal rychlejsie

Přesně tak, kdyby mi to někdo zaplatil

Podívejte se třeba https://andygrove.io/2018/03/datafusion-0.2.1-benchmark/ - je to projekt jednoho člověka a je to asi 3x rychlejší než Spark.

Nebo se podívejte sem https://www.quora.com/Is-it-significant-to-rewrite-HDFS-Hadoop-Spark-or-HBase-in-C-C++-to-improve-computational-efficiency

Nebo třeba SnappyData http://www.snappydata.io/highlights/performance - zase to ukazuje, že Spark má poměrně velké rezervy

Jo ale ten DataFusion je v Rustu ne? Je to důkaz efektivity .NETu?

[Radek Miček]

nejaky micek z hornej dolnrj by to asi napisal rychlejsie

Přesně tak, kdyby mi to někdo zaplatil

Podívejte se třeba https://andygrove.io/2018/03/datafusion-0.2.1-benchmark/ - je to projekt jednoho člověka a je to asi 3x rychlejší než Spark.

Nebo se podívejte sem https://www.quora.com/Is-it-significant-to-rewrite-HDFS-Hadoop-Spark-or-HBase-in-C-C++-to-improve-computational-efficiency

Nebo třeba SnappyData http://www.snappydata.io/highlights/performance - zase to ukazuje, že Spark má poměrně velké rezervy

Jo ale ten DataFusion je v Rustu ne? Je to důkaz efektivity .NETu?

Důkaz, že Spark není příliš efektivní.