Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Mysteriozni 11. 11. 2016, 20:38:32
-
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?
-
Tak třeba se tam dost věcí kontroluje. A rozhodně není vždy tak pomalá. Někde bude stejně rychlá a někde o něco pomalejší.
Do nativního kódu se normálně kompiluje, víc už to nejde. Proč myslíš, že je to tak rychlý?
GC rozhodně brzdí, to ale není chyba. Dá se třeba vypnout a vlastní implementace na míru je ideálním způsobem. Ne že bys to potřeboval, ale může se to hodit.
-
Proc je Java priblizne 3x pomalejsi nez C++
Protože není. To tvrzení je nesmysl – úplně stejně můžete tvrdit, že je 6× pomalejší, 20× pomalejší, 3× rychlejší nebo 10× rychlejší, a bude to pořád stejně pravdivé tvrzení.
A jde Javovska aplikace prelozit do nativniho kodu s rozumnymi vykonostnimi vysledky?
Ano, dělá to každá rozumná JVM.
Pokud Javu brzdi nejvic garbage c., je mozne psat aplikaci s manualnim uvolnovanim zdroju jako v c++? Je k tomu nejaka dobra literatura?
Hloupostí si můžete navymýšlet nekonečně mnoho, takže nemůžete čekat, že ke každé z nich bude existovat dobrá literatura.
-
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?
Java je pomala dokedy neprebehne ~20 000 iteracii toho isteho kodu a ona to neprelozi do nativneho kodu. Sama, bez tvojej asistencie. Predtym to zdrzuje analyza - co sa vola, ako casto sa to vola a co s tym. Potom je to bez alokacii / GC na urovni C++ kodu minus par percent na beh GC. O tom sa presvedcis v jednoduchom benchmarku.
Pisat aplikaciu s manualnym uvolnovanim zdrojov ako v C++ priamo nejde. Mozes do objektov priradzovat null, takze sa ti niekam nezatula referencia, ktora by drzala alokovane zdroje. Mozes znovupouzivat objekty. To je design anti-pattern, ale usetris na behu GC a doba behu bude stabilna napriec iteraciami.
Toto generuje vela garbage:
while (haveData()) {
byte[] data = readDataOfConstantSize();
processBigData(data);
}
Toto je rychlejsie, ale budes mat problem, ked data nebudu konstantnej velkosti. Ked citanie neuspeje, budes tam mat stare data:
byte[] data = new byte[getDataSize()];
while (haveData()) {
readDataOfConstantSize(data);
processBigData(data);
}
-
...
Ten druhý přístup je vytažený z C/C++, do Javy vůbec nepatří.
-
Ten druhý přístup je vytažený z C/C++, do Javy vůbec nepatří.
Ten druhý přístup používá třeba InputStream.read.
-
IMHO Python je mnohem lepsi... :)
-
Proc je Java priblizne 3x pomalejsi nez C++
No to by ma zaujimalo, ako ste namerali "priblizne 3x pomalsi". Microbenchmarking cez JMH vam asi nic nehovori. Keby Java bola taka katastrofa, asi by v nej nevznikol LMAX Disruptor, ktory sa pouziva v systemoch s "trochu" inymi narokmi na rychlost...
A jde Javovska aplikace prelozit do nativniho kodu s rozumnymi vykonostnimi vysledky?
Ano. Budete prekvapeny, ale funguje to velmi dobre a jednoducho. Robi sa to tak, ze Javovsku aplikaciu spustite.
IMHO Python je mnohem lepsi... :)
Hmm. Este aj ten Jython na JVM je rychlejsi ako CPython https://youtu.be/hLm3garVQFo?t=218 :-\
-
Pokud Javu brzdi nejvic garbage c., je mozne psat aplikaci s manualnim uvolnovanim zdroju jako v c++? Je k tomu nejaka dobra literatura?
Ak vas toto najviac trapi, tak sa to robi tak, ze si naallokujete blok pamate mimo heap a spravujete si ho sami (marshal/unmarshal). Literatura nech je vam GitHub.
LArray
https://github.com/xerial/larray/blob/develop/larray-buffer/src/main/java/xerial/larray/buffer/DefaultMemoryAllocator.java#L72
OpenHFT
https://github.com/OpenHFT/Chronicle-Core/blob/f8e14cb2b5e7daed17dc6feba0a30284f3fae0d6/src/main/java/net/openhft/chronicle/core/UnsafeMemory.java#L124
Pre jednoduchsie pochopenie clanok na tuto temu od tvorcu LMAX Disruptora:
http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html
Este k tej rychlosti, to HF v OpenHFT znamena HIGH FREQUENCY.
-
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).
-
Kdo zná Javu a jeden z moderních jazyků typu C(++), C#, Go nebo Swift, snadno napíše microbenchmark, co Javu roznese na kopytech.
Iste, ak vam ide o to, ako "roznest nejaky jazyk na kopytech", velmi rad si pozriem ako pobezi Bogosort rychlejsie v C ako v Jave. Kludne moze byt aj microbenchmark.
Dalsi idealny kandidat na rovnako kvalitny microbenchmarking je otvaranie a citanie suborov z disku/file systemu delegovanim volani kernelu. To bezpochyby ukaze, aky je ten ktory jazyk rychly. Vedlajsie efekty ako vlastnosti a implementacia file systemu, kernel schedulera alebo samotneho diskoveho media sa v teste vobec neodzrkadlia.
Pravdepodobne aj JMH vzniklo len preto, ze core vyvojari JVM nemali co robit.
Ked uz budeme pri tom testovani, tak vobec netreba zohladnovat fakt, ze JVM implementacii je hned niekolko (Oracle, IBM, Azul) pre rozne architektury, a ze existuju rozne implementacie zakladnych datovych struktur ako su Mapy, Listy, Sety atd. od roznych vendorov.
-
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.
-
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).
-
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ší.
Asi máme každý jinou definici inteligentně napsaného kódu. Já bych třeba od inteligentně napsaného kódu očekával, že bude aspoň dělat to, co má. Java neumožňuje objekty alokovat na zásobníku, tudíž v Javě takový kód nemůže existovat. Neexistují kód bude nejen řádově pomalejší, bude dokonce nekonečněkrát pomalejší, nebude dělat nic – a podle mne to rozhodně není inteligentně napsaný kód.
Inteligentně napsaný kód podle mne nejen dělá, co má, ale navíc dobře využívá prostředků dané platformy. Takže nebudu posuzovat, zda ten kód dobře pracuje s mnoha objekty alokovanými na zásobníku, ale jak dobře dělá to, co dělat má. A pokud při tom používá mnoho objektů alokovaných na zásobníku, prosím, ať to tak dělá, ale je to nepodstatný implementační detail.
-
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ší.
Asi máme každý jinou definici inteligentně napsaného kódu.
+1
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).
To je dobrý. Ty si najdeš někoho, kdo ty tvoje nesmysly vidí stejně a pak ho označíš za inteligentního :D To se mi líbí. Ty jsi samozřejmě také superbystrý, protože jinak bys to přece nemohl vidět stejně. Cool.
-
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.
Vyber si libovolnou "reálnou" úlohu a pošli sem své řešení v Javě. Ostatní diskutující se pokusí napsat rychlejší řešení v jiném jazyku.
-
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.
-
Jenže to nebyla dost inteligentní odpověď, tak se nepočítá ;D
-
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.
-
Vyber si libovolnou "reálnou" úlohu a pošli sem své řešení v Javě. Ostatní diskutující se pokusí napsat rychlejší řešení v jiném jazyku.
To je dost hloupé zadání, nemyslíte? Je program, který denně používají tisíce lidí, dostatečně reálná úloha? Já bych řekl, že ano. Takže takové „řešení v Javě“ může být například běhové prostředí pro Groovy, Scalu, nebo Kotlin. Tato běhová prostředí shodou okolností zahrnují JVM. Bylo by fajn, kdyby někdo jen tak na základě komentáře na Rootu napsal rychlejší JVM, ale já považuji za velmi nepravděpodobné, že by se do toho někdo pustil.
Možná jste nemyslel jakoukoli úlohu, ale něco jednoduchého, implementaci nějakého algoritmu apod. Jenže tím už dost omezujete zadání a hlavně se vzdalujete reálnému světu, protože v něm se v drtivé většině nepoužívají jednoduché programy řešící jedinou úlohu, právě naopak, používají se komplexní programy.
Navíc jste zadání omezil jen na rychlost běhu programu, což je jen jedno možné kritérium, a také se moc nepotkává s reálným světem. Jindy může být důležitá paměťová náročnost, rychlost vývoje, možnost dalšího rozvoje programu, škálovatelnost. A obvykle to bude nějaká kombinace těchto požadavků.
Prostě je nesmyslné obecně srovnávat programovací jazyky nebo platformy. Navíc v reálném světě je to přesně opačně, nehledám, co bych naprogramoval v nějakém jazyce, ale mám nějaké zadání, a k němu hledám vhodný jazyk. Pokud mám nějakou úlohu, při které potřebuju vyždímat maximum z CPU, asi sáhnu po C nebo C++, pokud mne bude zajímat bezpečnost kódu, budu se zajímat o Go, Rust nebo Erlang, pokud budu psát webovou aplikaci běžící v prohlížeči, podívám se po JavaScriptu a jazycích, které se do něj kompilují nebo transpilují, pokud budu chtít integrovat spoustu různých komponent a služeb do nějaké komplexní aplikace, zvolím Javu nebo C#.
-
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.
Takže závěr byl, že na úlohy, pro které není Java vhodná, je nevhodné používat Javu. Což věděli všichni od začátku, jenom někdo (nevím, zda přímo Zboj) měl potřebu dokazovat to – složitě a iterováním přes několik neefektivních implementací v C.
-
Vyber si libovolnou "reálnou" úlohu a pošli sem své řešení v Javě. Ostatní diskutující se pokusí napsat rychlejší řešení v jiném jazyku.
To je dost hloupé zadání, nemyslíte? Je program, který denně používají tisíce lidí, dostatečně reálná úloha? Já bych řekl, že ano. Takže takové „řešení v Javě“ může být například běhové prostředí pro Groovy, Scalu, nebo Kotlin. Tato běhová prostředí shodou okolností zahrnují JVM. Bylo by fajn, kdyby někdo jen tak na základě komentáře na Rootu napsal rychlejší JVM, ale já považuji za velmi nepravděpodobné, že by se do toho někdo pustil.
Možná jste nemyslel jakoukoli úlohu, ale něco jednoduchého, implementaci nějakého algoritmu apod. Jenže tím už dost omezujete zadání a hlavně se vzdalujete reálnému světu, protože v něm se v drtivé většině nepoužívají jednoduché programy řešící jedinou úlohu, právě naopak, používají se komplexní programy.
Navíc jste zadání omezil jen na rychlost běhu programu, což je jen jedno možné kritérium, a také se moc nepotkává s reálným světem. Jindy může být důležitá paměťová náročnost, rychlost vývoje, možnost dalšího rozvoje programu, škálovatelnost. A obvykle to bude nějaká kombinace těchto požadavků.
Prostě je nesmyslné obecně srovnávat programovací jazyky nebo platformy. Navíc v reálném světě je to přesně opačně, nehledám, co bych naprogramoval v nějakém jazyce, ale mám nějaké zadání, a k němu hledám vhodný jazyk. Pokud mám nějakou úlohu, při které potřebuju vyždímat maximum z CPU, asi sáhnu po C nebo C++, pokud mne bude zajímat bezpečnost kódu, budu se zajímat o Go, Rust nebo Erlang, pokud budu psát webovou aplikaci běžící v prohlížeči, podívám se po JavaScriptu a jazycích, které se do něj kompilují nebo transpilují, pokud budu chtít integrovat spoustu různých komponent a služeb do nějaké komplexní aplikace, zvolím Javu nebo C#.
Jediné možné objektivní srovnání je porovnání implementací stejné úlohy v různých jazycích. Vy zde stále uvádíte příklady softwaru napsaného v Javě, ke kterému neexistuje alternativní implementace. Jediná existující implementace bude logicky nejlepší.
-
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.
Takže závěr byl, že na úlohy, pro které není Java vhodná, je nevhodné používat Javu. Což věděli všichni od začátku, jenom někdo (nevím, zda přímo Zboj) měl potřebu dokazovat to – složitě a iterováním přes několik neefektivních implementací v C.
Kdo jiný. Vždy přijde s nějakou hovadinou a bez jakýchkoli důkazů to začne obhajovat. Pokud použiju špatný přístup, tak není moc s podivem, že to nefunguje. Čistě logicky, pokud je Java jen o kousek pomalejší než C/C++, tak tam žádný problém s výkonem nebude. Můžu zvolit přístup, kdy chci ukládat na zásobník a ještě pořád dělat GC, abych jako ukázal "reálný" svět, ale nikdo tomu asi moc neuvěří.
A jak se tu psalo. Asi těžko budu prodávat quicksort v krabici jako produkt.
-
Jediné možné objektivní srovnání je porovnání implementací stejné úlohy v různých jazycích.
To by platilo jenom tehdy, pokud by všechny porovnávané jazyky měly být pro nějakou úlohu stejně vhodné. Zrovna pro C a Javu takových úloh asi moc nebude, v případe C++ a Javy by nějaký průnik mohl existovat – ale zase to budou komplexní úlohy, které budete velmi těžko nějak porovnávat (rychlost běhu programu to nebude ani náhodou).
Vy zde stále uvádíte příklady softwaru napsaného v Javě, ke kterému neexistuje alternativní implementace. Jediná existující implementace bude logicky nejlepší.
Neexistuje k tomu alternativní implementace, protože každému soudnému člověku je jasné, že nedává smysl psát alternativní implementaci s pomocí nástroje, který je pro danou věc méně vhodný než současné řešení. Prostě jsou různé jazyky a platformy vhodné na různé věci. A když se to někde překrývá, je potřeba porovnávat to podle kritérií, která jsou důležitá pro tu danou úlohu.
-
V reálném světě je většinou součástí zadání běžnému programátorovi i jazyk. Pelmel všech možných jazyků v jednom větším projektu se dost špatně udržuje.
IMO není ve většině projektů, na kterých dělají čeští vývojáři, rychlost javy až tak podstatná. Daleko podstatnější bývá čistota kódu, udržovatelnost, rozšiřitelnost, rychlost uchopení projektu dalšími/novými lidmi. Mluvím o běžných byznys aplikacích, kterých si troufnu tvrdit je daleko nejvíce, takřka každá větší firma (a každá internetová) takové projekty má, obvykle interní pro své potřeby.
-
Jediné možné objektivní srovnání je porovnání implementací stejné úlohy v různých jazycích.
To by platilo jenom tehdy, pokud by všechny porovnávané jazyky měly být pro nějakou úlohu stejně vhodné. Zrovna pro C a Javu takových úloh asi moc nebude, v případe C++ a Javy by nějaký průnik mohl existovat – ale zase to budou komplexní úlohy, které budete velmi těžko nějak porovnávat (rychlost běhu programu to nebude ani náhodou).
Co třeba rychlost vývoje takového programu?
-
Koho zajímá rychlost vývoje? Přece neprodáváš prototypy.
-
Koho zajímá rychlost vývoje? Přece neprodáváš prototypy.
Zajímá to hlavně investora.
-
Jen toho hloupého. Vývoj je totiž to nejlevnější. Pokud chce nějaký shit rychle dostat na trh a pak je mu to jedno, tak v pohodě. Ale to nebude běžný přístup.
-
Jen toho hloupého.
Jistě, protože takový by ti nebyl ochoten platit stovky tisíc za kecy.
Rychlost vývoje je v dnešní době klíčová. Zadání se neustále mění a je potřeba na ně pružně reagovat. Divím se, že ty to ze své nelopatovské pozice nevidíš. Nebo že by nebyla až tak vysoká, jak se prsíš?
-
Vy zde stále uvádíte příklady softwaru napsaného v Javě, ke kterému neexistuje alternativní implementace. Jediná existující implementace bude logicky nejlepší.
Neexistuje k tomu alternativní implementace, protože každému soudnému člověku je jasné, že nedává smysl psát alternativní implementaci s pomocí nástroje, který je pro danou věc méně vhodný než současné řešení. Prostě jsou různé jazyky a platformy vhodné na různé věci. A když se to někde překrývá, je potřeba porovnávat to podle kritérií, která jsou důležitá pro tu danou úlohu.
Zrovna Javisté často reimplementují existující software v Javě.
Třeba Rhino a V8 https://axtaxt.wordpress.com/2011/09/25/benchmark-rhino-vs-chrome-v8-on-server-side/
PyPy a Jython https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=pypy&lang2=jython&data=u64q
-
Jen toho hloupého.
Jistě, protože takový by ti nebyl ochoten platit stovky tisíc za kecy.
Rychlost vývoje je v dnešní době klíčová. Zadání se neustále mění a je potřeba na ně pružně reagovat. Divím se, že ty to ze své nelopatovské pozice nevidíš. Nebo že by nebyla až tak vysoká, jak se prsíš?
Aneb běžná lopaťárna. Nevíme, co chceme, ale musí to být levné a hned. Najmeme pár lopat a budeme dřít. Přesčasy nevadí, protože vývoj je tvrdá práce jako práce v dole. Na přemýšlení není čas, protože by akorát zdržovalo od práce.
Já to právě vidím a denně musím vysvětlovat lopaťáckým manažerům, že jsou k ničemu a chtějí nesmysly. Pokud by nebyli hloupí, tak si to spočítají. Jenže oni vidí tak měsíc dopředu a pak už pro ně nic není. Tím se liší patlání od vývoje.
-
Já to právě vidím a denně musím vysvětlovat lopaťáckým manažerům, že jsou k ničemu a chtějí nesmysly. Pokud by nebyli hloupí, tak si to spočítají. Jenže oni vidí tak měsíc dopředu a pak už pro ně nic není. Tím se liší patlání od vývoje.
Dovolí ti ten tvůj manažer psát testy?
-
Já to právě vidím a denně musím vysvětlovat lopaťáckým manažerům, že jsou k ničemu a chtějí nesmysly. Pokud by nebyli hloupí, tak si to spočítají. Jenže oni vidí tak měsíc dopředu a pak už pro ně nic není. Tím se liší patlání od vývoje.
Dovolí ti ten tvůj manažer psát testy?
Se na něj můžu vysrat. Vývoj řídím já a on jen může souhlasit a nebo si najít někoho jiného. SW bez testů je zase lopaťárna. "My spíše vyvíjíme nové fíčury!" :D
-
Zrovna Javisté často reimplementují existující software v Javě.
[...]
PyPy a Jython https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=pypy&lang2=jython&data=u64q
Ehm, right... Nie ze by PyPy nezacal svoj zivot ako implementacia Pythonu v CPythone....
Psyco (2001)/PyPy(2007)
https://web.archive.org/web/20021205004539/http://psyco.sourceforge.net/index.html
vs
JPython (1997)/Jython(1999)
https://wiki.python.org/jython/JythonFaq/GeneralInfo
-
Zrovna Javisté často reimplementují existující software v Javě.
Protože z toho, že to bude implementované i v Javě, plynou nějaké výhody oproti existujícím implementacím. Některé implementace v Javě se zase reimplementují v C# nebo inspirují implementace napsané v JavaScriptu.
-
Zrovna Javisté často reimplementují existující software v Javě.
V pohode, akurat, ze podla zdrojakov to vyzera, ze standardne Python moduly a struktury su v Jythonove napisane v ... Pythone? :-\ Oops...
https://github.com/jythontools/jython/blob/master/lib-python/2.7/Queue.py
-
Zrovna Javisté často reimplementují existující software v Javě.
V pohode, akurat, ze podla zdrojakov to vyzera, ze standardne Python moduly a struktury su v Jythonove napisane v ... Pythone? :-\ Oops...
https://github.com/jythontools/jython/blob/master/lib-python/2.7/Queue.py
No a co? Pokud ten modul použijete, tak se přeloží do java bytekódu. Provádění toho bytekódu je řádově pomalejší než pypy.
Queue.py je stejný ve všech implementacích.
https://github.com/python/cpython/blob/master/Lib/queue.py
https://github.com/aljosa/pypy/blob/master/lib-python/2.7/Queue.py
-
Provádění toho bytekódu bude maximálně tak pomalé jako pypy, ale pravděpodobně daleko rychlejší.
-
K tomu prepisovani "lepsiho" softu do Javy, ona vyhoda bude, ze to potom spustite vsude, kde se spusti Java. Nejste zavisli na nejakych binarkach pro konkretni architekturu.
Treba v JavaScriptu je to podobne. Nektere baliky z npm si s sebou tahaji ruzne obludnosti v Ruby, Pythonu nebo C (klidne na vsech zaroven) a jsou s tim neustale problemy. Pokud to funguje, tak to muze byt rychlejsi, ale pokud to nefunguje, tak je to celkem peklo - dohledavani na cem vsem to zavisi, ze to nefunguje s touhle verzi Pythonu (2 vs 3) a ze se tomu musi manualne nekde predat cesta, ze se nekde nestahly predkompilovane binarky pro mou architekturu a OS, ze mi chybi nejaka knihovna. Proste tohle u cisteho JS reseni neni, tomu date "npm install" a konec. Vse je rychle stazene, nic se nemusi prekladat nebo dotahovat odjinud, funguje to vsude, kde jede nodejs.
-
K tomu prepisovani "lepsiho" softu do Javy, ona vyhoda bude, ze to potom spustite vsude, kde se spusti Java. Nejste zavisli na nejakych binarkach pro konkretni architekturu.
Takových jazyků, které běží (skoro) všude je víc, Java je jen jedním z nich.
-
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é.
-
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.
-
Pokud to funguje, tak to muze byt rychlejsi, ale pokud to nefunguje, tak je to celkem peklo - dohledavani na cem vsem to zavisi, ze to nefunguje s touhle verzi Pythonu (2 vs 3) a ze se tomu musi manualne nekde predat cesta, ze se nekde nestahly predkompilovane binarky pro mou architekturu a OS, ze mi chybi nejaka knihovna.
Tohle se děje i nad JVM - různé problémy s classpath nebo JARy, jenž obsahují nativní knihovny, které fungují pouze pro pár platforem.
-
Java je pomala dokedy neprebehne ~20 000 iteracii toho isteho kodu a ona to neprelozi do nativneho kodu. Sama, bez tvojej asistencie. Predtym to zdrzuje analyza - co sa vola, ako casto sa to vola a co s tym. Potom je to bez alokacii / GC na urovni C++ kodu minus par percent na beh GC. O tom sa presvedcis v jednoduchom benchmarku.
Pisat aplikaciu s manualnym uvolnovanim zdrojov ako v C++ priamo nejde. Mozes do objektov priradzovat null, takze sa ti niekam nezatula referencia, ktora by drzala alokovane zdroje. Mozes znovupouzivat objekty. To je design anti-pattern, ale usetris na behu GC a doba behu bude stabilna napriec iteraciami.
<snip>
zalezi co je pouzity za JIT. C2 ma hranici pro hot metody 10k by default, C1 5k. u tiered jsou to jednoduchy optimalizace a postupne prechazej v C2.
znovupouzivat objekty: idealne direct ByteBuffer.
-
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.
-
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é.
Mám to chápat tak, že např. GitHub a GitLab napsaly samé lopaty?
-
Asi ano, ale to jsou dost jednoduché softy, které nic moc neumí, takže třeba to nejsou lopaty. Webové věci jsou celkově dost jednoduché a back-end z toho nepoznám.
-
K tomu prepisovani "lepsiho" softu do Javy, ona vyhoda bude, ze to potom spustite vsude, kde se spusti Java. Nejste zavisli na nejakych binarkach pro konkretni architekturu.
Treba v JavaScriptu je to podobne. Nektere baliky z npm si s sebou tahaji ruzne obludnosti v Ruby, Pythonu nebo C (klidne na vsech zaroven) a jsou s tim neustale problemy. Pokud to funguje, tak to muze byt rychlejsi, ale pokud to nefunguje, tak je to celkem peklo - dohledavani na cem vsem to zavisi, ze to nefunguje s touhle verzi Pythonu (2 vs 3) a ze se tomu musi manualne nekde predat cesta, ze se nekde nestahly predkompilovane binarky pro mou architekturu a OS, ze mi chybi nejaka knihovna. Proste tohle u cisteho JS reseni neni, tomu date "npm install" a konec. Vse je rychle stazene, nic se nemusi prekladat nebo dotahovat odjinud, funguje to vsude, kde jede nodejs.
Původní téma této diskuze bylo proč je Java pomalá. Uvedl jsem ty příklady pro srovnání rychlosti. Chápu, že implementace v Javě může mít své výhody.
-
Queue.py je stejný ve všech implementacích.
https://github.com/python/cpython/blob/master/Lib/queue.py
https://github.com/aljosa/pypy/blob/master/lib-python/2.7/Queue.py
To je v poriadku. Ja som reagoval na tvrdenie "Zrovna Javisté často reimplementují existující software v Javě" nasledovnymi argumentami:
- PyPy vobec nie je dobry priklad pre nastoleny argument nakolko neobstoji voci odkazovanym faktom. Je to tak isto reimplementacia Pythonu a navyse mladsia ako Jython. Argument je preto mozne obratit: Preco niekto potreboval pisat PyPy, ked uz existoval CPython a Jython...
- Co sa Jythonu konkretne tyka, je to port runtime-u na JVM. Pythonovske moduly z Python Standard Library funguju bezozmeny, co priamo hovori o miere kompatibility runtime-u. Inymi slovami, tuto cast Pythonu Javisti nereimplementovali, lebo to nebolo nutne.
Pokud ten modul použijete, tak se přeloží do java bytekódu. Provádění toho bytekódu je řádově pomalejší než pypy.
Iste, asi ste prehliadli video, ktore som linkoval na prvej strane aj s casovym odkazom na presne miesto, kde Jim Baker porovnava vysledky pystone benchmarku Jython vs. CPython vs. PyPy... Odporucam davat pozor na argumenty, s ktorymi test spusta Jim vo videu versus argumenty, s ktorymi sa test spusta na pybenchmarks.org vid tu https://pybenchmarks.org/u64q/benchmark.php?test=pystone&lang=jython&data=u64q#log
-
Co zpomaluje Javu?
To fluidum, co je mezi židlí a klávesnicí.
A co preklad do nativniho kodu?
To má opačný efekt snad. :)
-
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.
-
Queue.py je stejný ve všech implementacích.
https://github.com/python/cpython/blob/master/Lib/queue.py
https://github.com/aljosa/pypy/blob/master/lib-python/2.7/Queue.py
To je v poriadku. Ja som reagoval na tvrdenie "Zrovna Javisté často reimplementují existující software v Javě" nasledovnymi argumentami:
- PyPy vobec nie je dobry priklad pre nastoleny argument nakolko neobstoji voci odkazovanym faktom. Je to tak isto reimplementacia Pythonu a navyse mladsia ako Jython. Argument je preto mozne obratit: Preco niekto potreboval pisat PyPy, ked uz existoval CPython a Jython...
- Co sa Jythonu konkretne tyka, je to port runtime-u na JVM. Pythonovske moduly z Python Standard Library funguju bezozmeny, co priamo hovori o miere kompatibility runtime-u. Inymi slovami, tuto cast Pythonu Javisti nereimplementovali, lebo to nebolo nutne.
Pokud ten modul použijete, tak se přeloží do java bytekódu. Provádění toho bytekódu je řádově pomalejší než pypy.
Iste, asi ste prehliadli video, ktore som linkoval na prvej strane aj s casovym odkazom na presne miesto, kde Jim Baker porovnava vysledky pystone benchmarku Jython vs. CPython vs. PyPy... Odporucam davat pozor na argumenty, s ktorymi test spusta Jim vo videu versus argumenty, s ktorymi sa test spusta na pybenchmarks.org vid tu https://pybenchmarks.org/u64q/benchmark.php?test=pystone&lang=jython&data=u64q#log
Podle toho videa je PyPy řádově rychlejší. Jython je na druhou stranu kompatibilější s CPythonem (podporuje C extensions). Srovnávat rychlost s CPythonem nedává moc smysl. CPython je čistě interpretovaný a nepoužívá JIT. Vyniká v jiných parametrech. Například v rychlosti startu a paměťové náročnosti.
-
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...
-
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.
-
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ů.
-
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.
-
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?
-
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).
-
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.
-
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.
Vyborne. Konecne som sa zorientoval. Mate absolutnu pravdu.
-
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).
Pri takychto prasacinach treba zvazit, ci to ozaj clovek potrebuje. Ak ano, tak radsej treba zvazit, ci nepouzije fortran, brainfuck, C alebo cobol.
-
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?
Pane Mysteriozni, muzes doplnit dotaz?
Predpokladam, ze zakladni problem je - neco je 3x pomalejsi nez neco jineho. Pak uz jen resis proc to prvni neco je tak pomale a jak to zrychlit.
Muzes uvest jak jsi dosel k tomu '3x pomalejsi'? Co je to za aplikaci, jak jsi meril rychlost,... Proste muzes dat dohromady nejaky smysluplny dotaz, aby melo vubec smysl na to rozumne reagovat?
Napada me treba situace, kdy obe aplikace spoustis pomoci shell scriptu, ale shell script, ktery spousti javu je blbe napsany, na necem se zadrhne/zacykli a to je vlastne duvod toho 3x pomalejsi. ;-)
Bez upresneni nema smysl se tim dotazem vubec zabyvat. Prevkapuje me, ze ostatni tak udelali.
-
GC zabíjí málo paměti.
JIT a platforma kolem něho žere výkon.
Preferování bezpečnosti před rychlostí. Opět ztráta výkonu.
Takže výsledek zhruba 300% pomalejší než C++. Alespoň podle benchmarks game.
-
Když jsem počítal integrály metodou Runge-Kutta 4. řádu, tak jazyky Java a C vyšly výkonově téměř nastejno. Fortran byl kousek před nimi.
-
Hm, C bezi vsude, argument jako prase proc mit binarni/cizojazycnou zasivlost v JavaScriptu, ktery take bezi skoro vsude (a tam, kde nebezi, tam mi je bezici knihovna v C na prd, kdyz hlavni aplikaci nespustim :D). U vykonostne nekriticke knihovny to muze jen idiot takto roztrkat. C bych i chapal, pokud je opravdu narust ve vykonu v nasobcich a pokud bottleneck vetsiny aplikaci prave stoji na teto knihovne. Pokud knihovna zavisi na vylozene pomalejsich vecech jako Python nebo Ruby, tak je to vzdycky na facku. Pokud existuje alternativa, tak nasleduje instantni zahozeni tohoto odpadniho baliku a nainstalovani normalniho. Kdyz totiz mate takhle "genialne" resene zavislosti (spise neresene), tak nestaci mit nainstalovany node a npm, ale musite instalovat Python, build veci pro C, dalsi ne-npm knihovny (dll/so), laborovat s verzemi Pythonu a zjistovat, jakymi workaroundy se ma predavat node-gyp cesta k pythoni binarce, protoze pozaduje prirozene nejakou archaickou verzi (dvojkova vetev). Takze si instalujete knihovnu pres balickovac - npm, ktery bezne resi zasislovi, pokud ale pouzivate takoveto veci mimo platformu, tak tam si musite cast zavislosti resit sami.
Jestli je to stejne polamane i v Jave, tj. ze se knihovna distribuuje napr. treba jen binarkami pro linuxu x64 a vse ostatni "pores si sam", tak se vubec nedivim, ze to nekdo prepsal do Javy. Jen opravdu ve vypocetne kriticke situaci bych sahl po kockopsovi (napr. knihovna pro nejake obecne mat. vypocty). Pokud je to knihovna, ktera i kdyby byla 100x pomalejsi nez verze napr. v C, ale aplikace stravi 0.01% casu vykonavanim kodu knihovny, tak to pridava akorat zbytecne starosti.
-
GC zabíjí málo paměti.
JIT a platforma kolem něho žere výkon.
Preferování bezpečnosti před rychlostí. Opět ztráta výkonu.
Takže výsledek zhruba 300% pomalejší než C++. Alespoň podle benchmarks game.
To jsou akorát kecy někoho, kdo vůbec netuší, o čem je řeč. Když řešíte overhead GC, měl byste také dodat, že i aplikace napsaná v C má automatickou správu paměti a něco stojí i ten luxus, že si naalokujete 10 bajtů, pak je zase vrátíte a neznamená to alokaci celé nové stránky od jádra.
JIT platforma žere levný výkon v době běhu programu výměnou za ušetření drahého výkonu při vývoji programu. Navíc umožňuje optimalizovat nativní kód podle aktuální platformy, na které program běží, a podle skutečného způsobu použití. Takže i čistý výkon na CPU může být ve výsledku pod JVM vyšší, než když stejný kód napíšete v C.
Preferování bezpečnosti před rychlostí odpovídá požadavkům na IT. Rychlost totiž snadno vyřešíte přidáním dalšího levného stroje, bezpečnost takhle vyřešit nejde. Navíc k čemu vám je teoretická rychlost aplikace, když vám ta aplikace kvůli nějaké triviální chybě neběží, nebo když vedle ní běží hackerův kód, který je součástí nějakého botnetu.
Když interpretujete výsledky nějakého měření, musíte také vědět, co se měřilo. Což evidentně Mysteriozni ani čumil nevědí, protože jinak by nemohli napsat nicneříkající blábol o tom, že je něco 3× rychlejší nebo pomalejší. V čem je to rychlejší? Tiskárna rychleji vytiskne papír, rychleji se zapíšou data na disk, u kvízu běží čas 3× rychleji? Mimochodem, i když byste chtěli porovnávat výkon na (C)PU, zaspali jste dobu, protože takovéhle věci se dnes neřeší zrychlováním algoritmu o drobná procenta, ale řeší se paralelizací.
-
GC zabíjí málo paměti.
JIT a platforma kolem něho žere výkon.
Preferování bezpečnosti před rychlostí. Opět ztráta výkonu.
Takže výsledek zhruba 300% pomalejší než C++. Alespoň podle benchmarks game.
To jsou akorát kecy někoho, kdo vůbec netuší, o čem je řeč. Když řešíte overhead GC, měl byste také dodat, že i aplikace napsaná v C má automatickou správu paměti a něco stojí i ten luxus, že si naalokujete 10 bajtů, pak je zase vrátíte a neznamená to alokaci celé nové stránky od jádra.
On řeší to, že overhead GC roste, když je méně paměti - což se u klasického mallocu tolik neděje.
Takže i čistý výkon na CPU může být ve výsledku pod JVM vyšší, než když stejný kód napíšete v C.
Jak často se to děje v praxi?
Rychlost totiž snadno vyřešíte přidáním dalšího levného stroje
To nemusí být vůbec pravda: Třeba v případě mobilního telefonu. Nebo, když máte výpočetní cluster, tak abyste dosáhl znatelného zrychlení, musíte přidat třeba desítky ne zrovna levných strojů - proto některé společnosti přešly od Cloudery k MapR, protože v MapR přepsali část Hadoopu do C++ a výkonostní rozdíl je znatelný - viz Is it significant to rewrite HDFS, Hadoop/Spark or HBase in C/C++ to improve computational efficiency? (https://www.quora.com/Is-it-significant-to-rewrite-HDFS-Hadoop-Spark-or-HBase-in-C-C++-to-improve-computational-efficiency).
-
On řeší to, že overhead GC roste, když je méně paměti - což se u klasického mallocu tolik neděje.
Ne, neřeší, to je daleko za jeho znalostmi. On jenom papouškuje, co četl někde v diskusích. Člověk, který aspoň tuší, jak funguje GC, nebude psát „jazyk X je 300% rychlejší než jazyk Y“.
Takže i čistý výkon na CPU může být ve výsledku pod JVM vyšší, než když stejný kód napíšete v C.
Jak často se to děje v praxi?
Zhruba tak stejně často, jako je potřeba řešit výkon tím, že se nějaká aplikace celá napíše v C. Jinak JVM kód za běhu optimalizuje včetně optimalizace skoků, třeba JRockit dělá při optimalizacích evidentně i docela divoké kousky. Takže je dost pravděpodobné, že některé části nativního kódu jsou za běhu v JVM optimalizované lépe, než jak je dokáže optimalizovat překladač na základě statické analýzy kódu. Akorát že na těch dílčích optimalizacích nikdo nezávisí, takže se nijak neměří a nezjišťují. Nemám tedy kód, na který bych ukázal a napsal „JRockit to při takovéhle profilu používání optimalizuje na tenhle nativní kód“.
Rychlost totiž snadno vyřešíte přidáním dalšího levného stroje
To nemusí být vůbec pravda: Třeba v případě mobilního telefonu. Nebo, když máte výpočetní cluster, tak abyste dosáhl znatelného zrychlení, musíte přidat třeba desítky ne zrovna levných strojů - proto některé společnosti přešly od Cloudery k MapR, protože v MapR přepsali část Hadoopu do C++ a výkonostní rozdíl je znatelný - viz Is it significant to rewrite HDFS, Hadoop/Spark or HBase in C/C++ to improve computational efficiency? (https://www.quora.com/Is-it-significant-to-rewrite-HDFS-Hadoop-Spark-or-HBase-in-C-C++-to-improve-computational-efficiency).
Bavíme se ale (asi) o rychlosti vykonávání aplikace na CPU. Aplikace, pro které je tohle kritické, nebudete provozovat na mobilním telefonu. V případě clusteru pouhým přepsáním z Javy do C++ zvýšíte výkon minimálně, přidat ne zrovna levné stroje do clusteru je pořád levnější. Výkon můžete podstatně zvýšit tím, že změníte algoritmus zpracování. Pak se může ukázat, že ten algoritmus nejde efektivně implementovat s prostředky JVM (a implementovat to přímým přístupem do paměti nedává pod JVM moc smysl, protože pak ztrácíte výhody JVM). Také je pravda, že clusterová řešení jdou proti výhodám JIT kompilace, protože u levných hloupých procesorů ztrácíte tu výhodu kódu optimalizovaného pro spekulativní provádění kódu. Nebo-li i když se jedná o výpočetně náročnou aplikaci, zvolený jazyk (nebo spíš prostředí) je spíš podružná záležitost, výkon mnohem víc ovlivňují jiné věci – na prvních třech místech jsou možnost paralelizace, použité algoritmy a schopnost využít vysokého výkonu procesoru (aby procesor minimálně čekal – tj. aby měl data v cache, nemusel se synchronizovat s jinými vlákny, aby mohl kód provádět paralelně a aby využil výsledky spekulativního provádění kódu).
-
Co když potřebuju třeba GPGPU?
JOCL?
-
Co když potřebuju třeba GPGPU?
JOCL?
To je nativní knihovna.
-
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.
-
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.
False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.
-
Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.
-
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.
False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.
BigData a AI jsou mimoběžné věci.
-
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.
False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.
BigData a AI jsou mimoběžné věci.
Ne v dnesni dobe.
A argumentace s OpenCL je hovadina. Pokud nekdo neco pocita na grafice, zavisi na nativnich knihovnach stejne, takze jakykoliv jazyk s timhle bude mit stejne problemy.
-
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.
False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.
BigData a AI jsou mimoběžné věci.
False
-
Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.
To se ozval ten pravej :D :D
-
Tak jistě. Házet špínu na nejlepší jazyk všech dob by vám šlo. Filip se alespoň snaží dávat i nějaké argumenty.
-
Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.
Škoda, že jinak je Filip úplnej magor.
-
Tak jistě. Házet špínu na nejlepší jazyk všech dob by vám šlo. Filip se alespoň snaží dávat i nějaké argumenty.
jo jasně, chápu, promiň javamane ... :(
-
Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.
Škoda, že jinak je Filip úplnej magor.
To má být argument týkající se Javy nebo nějakých špatných benchmarků?
-
Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.
Škoda, že jinak je Filip úplnej magor.
Jak jinak? Tady píše obvykle k věci.
Tak jistě. Házet špínu na nejlepší jazyk všech dob by vám šlo. Filip se alespoň snaží dávat i nějaké argumenty.
jo jasně, chápu, promiň javamane ... :(
:D
-
Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.
Škoda, že jinak je Filip úplnej magor.
To má být argument týkající se Javy nebo nějakých špatných benchmarků?
Filipa chlapče, Filipa ...
-
To má být argument týkající se Javy nebo nějakých špatných benchmarků?
Filipa chlapče, Filipa ...
Jenže tady neřešíme Filipa, ale příčiny zpomalování Javy. Nespletl sis fórum?
-
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.
False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.
BigData a AI jsou mimoběžné věci.
False
Ale, ale...
Hodně aplikací velkých dat je vcelku triviální počítání... nad velkými daty. Žádná AI.
A naopak dost různých aplikací AI nemá s velkými daty co dělat.
Netvrdím, že se ty dvě věci nesetkávají, ale rozhodně se nekryjí...
-
Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.
Škoda, že jinak je Filip úplnej magor.
To má být argument týkající se Javy nebo nějakých špatných benchmarků?
Filipa chlapče, Filipa ...
hu řešil Filipa a já sem ti jen objasňoval zjevný fakt :D
-
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.
False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.
BigData a AI jsou mimoběžné věci.
False
Ale, ale...
Hodně aplikací velkých dat je vcelku triviální počítání... nad velkými daty. Žádná AI.
A naopak dost různých aplikací AI nemá s velkými daty co dělat.
Netvrdím, že se ty dvě věci nesetkávají, ale rozhodně se nekryjí...
Nekryjí, ale setkávají čím dál tím víc. A budou ještě víc.
-
Zasa sa tu zisli experti na AI a Big Data. Taketo debaty byvaju celkom "vyzivne", idem si zobrat pukance :)
-
tyhle ty pindikovska srovnavaci vlakna dopadnou vzdy stejne....
nicmene tak pred rokem jsem v jednom podobnem vznesl ze zvedavosti dotaz, na najeakou libovolnou javovksou desktop aplikaci, ktera se da pouzit jako dukaz ze to jde....v tu dobu byl ale vysledek vsech odpovedi cistokrevna nula.....proste v jave neni napsane kvalitni vubec NIC. myslim ze par lidi nabydlo nejake utilitky, tooly atd, ale zadna big java desktop app vubec nikoho nenapadla......takze round #2, ma uz java nejakou vykladni skrin?
-
tyhle ty pindikovska srovnavaci vlakna dopadnou vzdy stejne....
nicmene tak pred rokem jsem v jednom podobnem vznesl ze zvedavosti dotaz, na najeakou libovolnou javovksou desktop aplikaci, ktera se da pouzit jako dukaz ze to jde....v tu dobu byl ale vysledek vsech odpovedi cistokrevna nula.....proste v jave neni napsane kvalitni vubec NIC. myslim ze par lidi nabydlo nejake utilitky, tooly atd, ale zadna big java desktop app vubec nikoho nenapadla......takze round #2, ma uz java nejakou vykladni skrin?
eclipse?
-
..., ma uz java nejakou vykladni skrin?
Co třeba LibreOffice?
-
..., ma uz java nejakou vykladni skrin?
Co třeba LibreOffice?
Pokud se něco nezměnilo, je v LO tak 8% kódu v Javě (zbytek prakticky C++) a existovaly snahy se jí zbavit úplně. Výkladní skříň si představuju jinak.
-
FreeMind.
-
IntelliJ IDEA a všechny IDE na něm postavené.
GeoGebra.
-
DbVisualizer
http://www.dbvis.com/
-
tyhle ty pindikovska srovnavaci vlakna dopadnou vzdy stejne....
nicmene tak pred rokem jsem v jednom podobnem vznesl ze zvedavosti dotaz, na najeakou libovolnou javovksou desktop aplikaci, ktera se da pouzit jako dukaz ze to jde....v tu dobu byl ale vysledek vsech odpovedi cistokrevna nula.....proste v jave neni napsane kvalitni vubec NIC. myslim ze par lidi nabydlo nejake utilitky, tooly atd, ale zadna big java desktop app vubec nikoho nenapadla......takze round #2, ma uz java nejakou vykladni skrin?
Jasně že ta vlákna dopadnou vždycky stejně – když váš první příspěvek do diskuse je lež… Už minule tady byly jmenovány stejné aplikace, jako dnes. Eclipse, NetBeans, IntelliJ Idea a další IDE z ní vycházející, FreeMind, NATO Mice Console (http://netbeans.dzone.com/nb-updated-nato-air-defence-solution), Northrop Grumman Agile Client, SeeTrack Military (http://www.seebyte.com/military/seetrack-military/), US Navy JECP System Performance Model, US Navy JMAT Visualization, Gecco (https://blogs.oracle.com/geertjan/entry/royal_netherlands_navy_on_netbeans), Boeing Mass Properties Toolkit (https://netbeans.org/community/articles/boeing-netbeans-platform.html), Zebra Imaging (https://blogs.oracle.com/geertjan/entry/electromagnetic_simulation_integration_platform_on), Vespa (http://netbeans.dzone.com/nb-proteogenomics), aplikace NASA JPL Maestro Team (http://www.eclipse.org/community/casestudies/NASAfinal.pdf)… Stačí, nebo mám pokračovat?
-
Jasně že ta vlákna dopadnou vždycky stejně – když váš první příspěvek do diskuse je lež…
Podle většiny benchmarků je to pravda.
-
Jasně že ta vlákna dopadnou vždycky stejně – když váš první příspěvek do diskuse je lež…
Podle většiny benchmarků je to pravda.
Mohl byste odkázat na ty benchmarky, které ukazují, že Ferrenz nedostal žádnou odpověď, když se minule ptal na dobré desktopové aplikace napsané v Javě?
Ale už se nedivím, že nedokážete interpretovat výsledky benchmarku, když vám dělá problém i jednoduchá česká věta.
Navíc i ten Ferrenzův dotaz je zavádějící, protože původně se psalo o aplikacích obecně, on to najednou zúžil na desktopové aplikace.
-
Jasně že ta vlákna dopadnou vždycky stejně – když váš první příspěvek do diskuse je lež…
Podle většiny benchmarků je to pravda.
Mohl byste odkázat na ty benchmarky, které ukazují, že Ferrenz nedostal žádnou odpověď, když se minule ptal na dobré desktopové aplikace napsané v Javě?
Ale už se nedivím, že nedokážete interpretovat výsledky benchmarku, když vám dělá problém i jednoduchá česká věta.
Navíc i ten Ferrenzův dotaz je zavádějící, protože původně se psalo o aplikacích obecně, on to najednou zúžil na desktopové aplikace.
Omlouvám se. Myslel jsem první příspěvek této diskuze od Mysteriozni. Desktopové aplikace mě nezajímají. Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C. Někteří se tu snažili odpovědět proč tomu tak je. Vy diskutujete mimo téma a napadáte Čumila za odpověď na původní otázku.
http://benchmarksgame.alioth.debian.org/u64q/java.html
-
nicmene tak pred rokem jsem v jednom podobnem vznesl ze zvedavosti dotaz, na najeakou libovolnou javovksou desktop aplikaci, ktera se da pouzit jako dukaz ze to jde....
Uvedu znovu kvalitni (jiz mnohokrat zminenou) IntelliJ IDEA, ale stitek desktop aplikace nese i velmi popularni Minecraft.
<trolling>
v tu dobu byl ale vysledek vsech odpovedi cistokrevna nula.....proste v jave neni napsane kvalitni vubec NIC. myslim ze par lidi nabydlo nejake utilitky, tooly atd, ale zadna big java desktop app vubec nikoho nenapadla......takze round #2, ma uz java nejakou vykladni skrin?
</trolling>
FIFY
PS: IDEA zcela jiste spada do kategorie "big java desktop app" (stejne jako Eclipse a NetBeans) .
-
Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C.
Vy tomu vážně věříte, že? Pořád to papouškujete dokola a nikdy vás nenapadlo zamyslet se, co ta věta vlastně znamená – a jestli vůbec má nějaký význam. Tak se nad tím prosím zkuste tentokrát zamyslet a tu větu vysvětlit.
Zde je malá nápověda. Java i C jsou programovací jazyky. Co znamená „programovací jazyk“? Obvykle je to nějaký standard, který popisuje syntaxi toho programovacího jazyka, a případně význam jednotlivých lexémů nebo tokenů. Vy porovnáváte rychlost programovacích jazyků. Znamená to, že porovnáváte rychlost těch standardů? Leda že byste jejich definici vytiskl a výtisky shazoval z věže… Tak porovnáváte rychlost aplikací napsaných v těch jazycích? Aplikací napsaných v C i v Javě je spousta, takže jak je budete porovnávat? Znamená ten výrok „Každá aplikace v Javě je 2× až 3× pomalejší než libovolná aplikace napsaná v C“? Co znamená „rychlost aplikace“ – třeba u kancelářského balíku, zálohovacího programu, budíku, webového serveru?
Někteří se tu snažili odpovědět proč tomu tak je. Vy diskutujete mimo téma a napadáte Čumila za odpověď na původní otázku.
Je marné pokoušet se odpovídat na nesmyslnou otázku. Mimo téma diskutují všichni, kteří na tu „otázku“ zdánlivě odpovídají. Klidně ať vám pomohou s výše uvedeným a vysvětlí, co ta otázka vlastně znamená.
-
A jeje, zase tup[ej jirsak zvani zcela z cesty ...
Jirsak, java je jazyk nekompilovanej, a to je jedna z jejich primarnich vlastnosti. A negramoti to samo nemuzou pochopit. Jo a u toho kancl baliku je docela rozdil jestli neco bude domument prechroustavat a formatovat minutu (v C) nebo 10 (java).
-
Omlouvám se. Myslel jsem první příspěvek této diskuze od Mysteriozni. Desktopové aplikace mě nezajímají. Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C. Někteří se tu snažili odpovědět proč tomu tak je. Vy diskutujete mimo téma a napadáte Čumila za odpověď na původní otázku.
http://benchmarksgame.alioth.debian.org/u64q/java.html
...a jako podporu tvrzeni "Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C" posles link, kde je vetsina benchamrku takova, ze Java neni ani 2* pomalejsi nez C....
-
Jirsak, java je jazyk nekompilovanej, a to je jedna z jejich primarnich vlastnosti.
Množství toho, co všechno můžete vědět špatně, je zřejmě opravdu neomezené. JVM (Java Virtual Machine) provádí bajtkód. Programátoři nepíšou bajtkód v hexaeditoru, ale píšou program v nějakém programovacím jazyce, který se následně do bajtkódu kompiluje. Do bajtkódu se dá kompilovat několik jazyků, nejčastěji je to právě Java (což mimochodem vypovídá o znalostech zdejších „3× rychlejších“, protože není jasné ani to, zda píšou o Javě nebo o JVM). Kompilátor z Javy do bajtkódu je součástí JDK a obvykle se jmenuje javac (http://docs.oracle.com/javase/8/docs/technotes/guides/javac/index.html).
-
A jeje, zase tup[ej jirsak zvani zcela z cesty ...
Jirsak, java je jazyk nekompilovanej, a to je jedna z jejich primarnich vlastnosti. A negramoti to samo nemuzou pochopit. Jo a u toho kancl baliku je docela rozdil jestli neco bude domument prechroustavat a formatovat minutu (v C) nebo 10 (java).
Cim hur informovany tim agresivnejsi...
-
Ahoj,
kratka odpoved. Ano java je pomala, presto jsem ji pouzivam uz vic jak 10 let a stale budu.
Ale je to dan za plno dalsich veci co nam java prinasi. Napriklad zpetnou kompatibilitu, bezpecnost a standartni SDK s kterym mohu pocitat na kazde implementaci. Doporucuju kouknot take na tuto odpoved na stackoverflow http://stackoverflow.com/a/2163570 Je to tam myslim velmi dobre schrnuto.
Pokud nekdo potrebuje rychle pocitat pocasi, simulace tekutin ci mandelbrotovy mnoziny, tak na to java opravdu nebyla prvne navrzena. Ale pokud nekdo potrebuje provozovat informacni system o 500k radkach kodu s integraci do nekolika databazi a distribuovanych transakci, tak zde java bude excelovat. Nikdy nebude rychlejsi nez C,ASM,FPGA,ASIC ale vzdy to vyvazi necim jinym. Treba 1/4 casem na vyvoj a udrzovani takoveho systemu.
Radek
-
Omlouvám se. Myslel jsem první příspěvek této diskuze od Mysteriozni. Desktopové aplikace mě nezajímají. Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C. Někteří se tu snažili odpovědět proč tomu tak je. Vy diskutujete mimo téma a napadáte Čumila za odpověď na původní otázku.
http://benchmarksgame.alioth.debian.org/u64q/java.html
...a jako podporu tvrzeni "Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C" posles link, kde je vetsina benchamrku takova, ze Java neni ani 2* pomalejsi nez C....
Průměr těch benchmarků vychází hůř než 2-krát pomalejší. Ten poslední je 3.5-krát pomalejší. Žádný z nich není rychlejší. Mnohokrát jsem se v těchto dskuzích dočetl, že Java je v některých případech rychlejší díky analýze spuštěného programu. Nikdy jsem neviděl benchmark, který by to potvrzoval.
-
Jirsak, java je jazyk nekompilovanej, a to je jedna z jejich primarnich vlastnosti.
Množství toho, co všechno můžete vědět špatně, je zřejmě opravdu neomezené. JVM (Java Virtual Machine) provádí bajtkód. Programátoři nepíšou bajtkód v hexaeditoru, ale píšou program v nějakém programovacím jazyce, který se následně do bajtkódu kompiluje. Do bajtkódu se dá kompilovat několik jazyků, nejčastěji je to právě Java (což mimochodem vypovídá o znalostech zdejších „3× rychlejších“, protože není jasné ani to, zda píšou o Javě nebo o JVM). Kompilátor z Javy do bajtkódu je součástí JDK a obvykle se jmenuje javac (http://docs.oracle.com/javase/8/docs/technotes/guides/javac/index.html).
Ty si fakt matroš :D takovýho demagoga sem fakt už dlouho nepotkal.
My chápeme že rychlost syntaxe nejde měřit, narozdíl od tebe ale umíme trošku generalizovat a nepotřebujeme za benchmarkem mít napsanou velikost čůráka tvurce vm pro maximální objektivitu.
-
Omlouvám se. Myslel jsem první příspěvek této diskuze od Mysteriozni. Desktopové aplikace mě nezajímají. Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C. Někteří se tu snažili odpovědět proč tomu tak je. Vy diskutujete mimo téma a napadáte Čumila za odpověď na původní otázku.
http://benchmarksgame.alioth.debian.org/u64q/java.html
...a jako podporu tvrzeni "Podle většiny benchmarků je Java opravdu 2x až 3x pomalejší než C" posles link, kde je vetsina benchamrku takova, ze Java neni ani 2* pomalejsi nez C....
Průměr těch benchmarků vychází hůř než 2-krát pomalejší.
To uz je dost jine tvrzeni, nez se kterym jsi zacal.
-
Jirsak, java je jazyk nekompilovanej, a to je jedna z jejich primarnich vlastnosti.
Množství toho, co všechno můžete vědět špatně, je zřejmě opravdu neomezené. JVM (Java Virtual Machine) provádí bajtkód. Programátoři nepíšou bajtkód v hexaeditoru, ale píšou program v nějakém programovacím jazyce, který se následně do bajtkódu kompiluje. Do bajtkódu se dá kompilovat několik jazyků, nejčastěji je to právě Java (což mimochodem vypovídá o znalostech zdejších „3× rychlejších“, protože není jasné ani to, zda píšou o Javě nebo o JVM). Kompilátor z Javy do bajtkódu je součástí JDK a obvykle se jmenuje javac (http://docs.oracle.com/javase/8/docs/technotes/guides/javac/index.html).
Ty si fakt matroš :D takovýho demagoga sem fakt už dlouho nepotkal.
My chápeme že rychlost syntaxe nejde měřit, narozdíl od tebe ale umíme trošku generalizovat a nepotřebujeme za benchmarkem mít napsanou velikost čůráka tvurce vm pro maximální objektivitu.
Ono hlavne je potreba uvedomit si, ze kompilovany a interpretovany nejsou ciste protiklady.
Java je kompilovana (jak do bytecodu tak pak prostrednictvim JIT nebo AOT dal do nativu) i interpretovana (interpretace bytecodu, kde se to podle JIT nevyplati resit).
-
Ono hlavne je potreba uvedomit si, ze kompilovany a interpretovany nejsou ciste protiklady.
Java je kompilovana (jak do bytecodu tak pak prostrednictvim JIT nebo AOT dal do nativu) i interpretovana (interpretace bytecodu, kde se to podle JIT nevyplati resit).
Složitější optimalizace musí řešit kompilátor do bytekódu. V JIT fázi na to není čas.
-
Ono hlavne je potreba uvedomit si, ze kompilovany a interpretovany nejsou ciste protiklady.
Java je kompilovana (jak do bytecodu tak pak prostrednictvim JIT nebo AOT dal do nativu) i interpretovana (interpretace bytecodu, kde se to podle JIT nevyplati resit).
Složitější optimalizace musí řešit kompilátor do bytekódu. V JIT fázi na to není čas.
To jsou zase moudra.
Pri prekladu do bytecode muzes udelat trebas escape analysis, ale nemas sanci poradne udelat devirtualizace. Stejne tak nemas pri prekladu do bytecode sanci udelat optimalizace, ktere zaviseji na cilove platforme.
-
My chápeme že rychlost syntaxe nejde měřit, narozdíl od tebe ale umíme trošku generalizovat
Tak generalizujte, generalizujte. Vždyť jsme to psal už v minulém komentáři, že mne zajímá, co přesně ty benchmarky podle vás ukazují. Když to umíte, tak přece pro vás není problém, abyste to zformuloval.
Ono to totiž takhle vypadá, že ta obecná tvrzení a generalizace jsou jen zástěrkou toho, že vlastně nevíte.
-
Složitější optimalizace musí řešit kompilátor do bytekódu. V JIT fázi na to není čas.
Právě naopak, složitější optimalizace dělá až JIT, protože k nim má potřebné informace – na rozdíl od kompilátoru zdrojových kódů, který nemá nic jiného, než ten zdrojový kód.
Mimochodem, spousta javovského kódu běží na serverech, kde má JIT dny, týdny nebo měsíce času na optimalizaci. To je řádově víc, než kolik má javac.
-
Složitější optimalizace musí řešit kompilátor do bytekódu. V JIT fázi na to není čas.
Právě naopak, složitější optimalizace dělá až JIT, protože k nim má potřebné informace – na rozdíl od kompilátoru zdrojových kódů, který nemá nic jiného, než ten zdrojový kód.
Mimochodem, spousta javovského kódu běží na serverech, kde má JIT dny, týdny nebo měsíce času na optimalizaci. To je řádově víc, než kolik má javac.
Když tu aplikaci restartuješ tak jsou měsíce optimalizací ztraceny.
-
Složitější optimalizace musí řešit kompilátor do bytekódu. V JIT fázi na to není čas.
Právě naopak, složitější optimalizace dělá až JIT, protože k nim má potřebné informace – na rozdíl od kompilátoru zdrojových kódů, který nemá nic jiného, než ten zdrojový kód.
Mimochodem, spousta javovského kódu běží na serverech, kde má JIT dny, týdny nebo měsíce času na optimalizaci. To je řádově víc, než kolik má javac.
Když tu aplikaci restartuješ tak jsou měsíce optimalizací ztraceny.
Presne tak.
Ono naopak by to bylo docela tezke, trebas kvuli tem devirtualizacim, ze?
-
Tadle celá diskuze je padlá na hlavu.
Takže vážení, Ondro a Filipe, máte pravdu, Java (JVM ... Oracle™ JVM) je úplně to nejrychlejší v celé poznané a nepoznané galaxii. Nativně kompilovaný kód je proti Java (JVM ... Oracle™ JVM) totální sráč, úplně stejný jako všichni diskutující v tomhle vláknu, kteří místo toho aby něco užitečnýho dělali tak se hádaj o kompletní bullshit a vedou diskuzi na úrovni právníků na piku.
Tázajícího nezajímalo proč Java (JVM ... Oracle™ JVM) není 3x pomalejší. Tázajícího zajímalo proč naopak je 3x pomalejší. Tázající zřejmě ví že je pomalejší a nepotřebuje o tom poučovat. A i kdyby kecal sračky, proč vás to proboha tak tankuje, to Javu (JVM ... Oracle™ JVM) o volným čase šukáte takže to berete jako urážku cti? Nebo jako co?
Já si fakt připadám jak na exkurzi do 1984, kde se taky kecali totální sračky, ale pochvilce výkladu začli i celkem dávat smysl.
-
Tázajícího nezajímalo proč Java (JVM ... Oracle™ JVM) není 3x pomalejší. Tázajícího zajímalo proč naopak je 3x pomalejší.
Třeba proto, že programátoři napsali tu aplikaci blbě.
-
Tadle celá diskuze je padlá na hlavu.
Takže vážení, Ondro a Filipe, máte pravdu, Java (JVM ... Oracle™ JVM) je úplně to nejrychlejší v celé poznané a nepoznané galaxii. Nativně kompilovaný kód je proti Java (JVM ... Oracle™ JVM) totální sráč, úplně stejný jako všichni diskutující v tomhle vláknu, kteří místo toho aby něco užitečnýho dělali tak se hádaj o kompletní bullshit a vedou diskuzi na úrovni právníků na piku.
Strc si toho strawmana...
-
Takže vážení, Ondro a Filipe, máte pravdu, Java (JVM ... Oracle™ JVM) je úplně to nejrychlejší v celé poznané a nepoznané galaxii.
Jn, to tu urcite nekdo tvrdil. Spis bych rekl, ze naopak byli proti takovymto prehnanym a lzivym generalizacim.
Nativně kompilovaný kód je proti Java (JVM ... Oracle™ JVM) totální sráč, úplně stejný jako všichni diskutující v tomhle vláknu, kteří místo toho aby něco užitečnýho dělali tak se hádaj o kompletní bullshit a vedou diskuzi na úrovni právníků na piku.
JIT kompiluje do nativniho kodu, kdyz to vede ke zvyseni vykonu. (Ano, prvnich par tisic iteraci bude pomalejsi nez nativni kod, dalsi ale ne nutne. V realnych aplikaci je to jen vyjmecne problem a za cenu rychlejsiho behu po hodiny/mesice/roky tech par vterin/minut na zacatku vetsinou neni zadny problem.) Proto je vykon aplikaci nad JVM (ne jen Java) tak dobry, prestoze to jede na VM.
Tázajícího nezajímalo proč Java (JVM ... Oracle™ JVM) není 3x pomalejší.
Rekl bych, ze tazatele to nikdy nezajimalo. Tipuju ze to byl bait. Napsal tu vubec neco krom prvniho postu?
Tezko muzete radit jak resit neco, co neni pravda, minimalne v obecne rovine. Kdyby tazatel poslal odkaz na kod, nebo uvedl kus zdrojaku, tak mu profici mohli poradit.
Tázajícího zajímalo proč naopak je 3x pomalejší. Tázající zřejmě ví že je pomalejší a nepotřebuje o tom poučovat.
Kdyz je nepravdive puvodni tvrzeni, tak o tom asi potrebuje poucit, kdyz zije v omylu. Proc by se jinak ptal na takovou hloupost?
A i kdyby kecal sračky, proč vás to proboha tak tankuje, to Javu (JVM ... Oracle™ JVM) o volným čase šukáte takže to berete jako urážku cti? Nebo jako co?
Ono nekterym lidem vadi, kdyz ostatni melou kraviny a snazi se to vsem cpat. Proto snad chodi na forum, aby se dozvedeli neco noveho nebo se podelili o svoje vedomosti a rady. Ne vsichni sem chodi trolovat ;).
-
Tázající zřejmě ví že je pomalejší a nepotřebuje o tom poučovat.
Pokud to ví, má to napsat. Má napsat, co je pomalejší, kdy je to pomalejší, jak měří, že je to pomalejší. Pak mu někdo může poradit.
Tadle celá diskuze je padlá na hlavu.
Já si fakt připadám jak na exkurzi do 1984, kde se taky kecali totální sračky, ale pochvilce výkladu začli i celkem dávat smysl.
Na tom, že je ta diskuse padlá na hlavu, máte zrovna vy lví podíl. Totální nesmysly tu píšete právě vy, a když si dovolím zeptat se, co jste tím obecným prohlášením myslel a jestli pro něj máte nějaký důkaz, nezmůžete se na nic jiného, než na urážky.
Když někdo tvrdí, že je něco rychlejší, měl by být schopen napsat, co to ta rychlost je a jak ji měří. To tady zatím neudělal nikdo z těch, kteří tvrdí, že je nějaký jazyk rychlejší než jiný jazyk. Pokud je to pro vás tak jednoduché, nemůže pro vás přeci být žádný problém to srozumitelně popsat. Vzhledem k tomu, že to ještě nikdo neudělal, jeví se jako pravděpodobné, že ta tvrzení o rychlosti jsou jenom ničím nepodložené plky. Které jejich autoři pouze někde zahlédli na internetu, ale vůbec jim nerozumí, takže nejsou schopni je ani obhájit, ale dokonce ani vysvětlit, co podle nich vlastně znamenají.
Takže vážení, Ondro a Filipe, máte pravdu, Java (JVM ... Oracle™ JVM) je úplně to nejrychlejší v celé poznané a nepoznané galaxii.
Nic takového tu nikdo netvrdil. To, že vy nejste schopen svá tvrzení jakkoli doložit nebo obhájit, neznamená, že platí tvrzení opačná. Tak ještě jednou, třeba to konečně pochopíte: problém není v tom, že by z toho tvrzení vycházela Java špatně. Úplně stejně nesmyslné by to tvrzení bylo, i kdybyste psal, že je Java 1000× rychlejší. Problém je totiž v tom, že to tvrzení je nesmyslné, nedává žádný smysl mluvit obecně o „rychlosti jazyka“.
A i kdyby kecal sračky, proč vás to proboha tak tankuje, to Javu (JVM ... Oracle™ JVM) o volným čase šukáte takže to berete jako urážku cti? Nebo jako co?
Nadávkami a nesmysly tu svá tvrzení „obhajujete“ vy. To, co tu bylo napsáno, není urážka cti a není to nic proti Javě, C, C++ nebo proti čemukoli jinému. Jde jenom o to, že psát o „rychlosti jazyka“ je nesmysl. Původní tazatel nad tím možná nepřemýšlel a napsal, co někde zaslechl. To je v pořádku, diskuse je od toho, aby mu někdo vysvětlil, že neexistuje žádná „rychlost jazyka“ a že porovnávání programovacích jazyků je poněkud komplikovanější, a je závislé na řešených úlohách – pro různé úlohy budou různá kritéria. Zbytek diskuse je pak už jenom o tom, aby se neznalý tazatel dozvěděl, kterým směrem má pátrat, když se chce přiblížit pravdě, a aby nenaletěl těm vašim nesmyslům, které tu píšete.
-
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 i neni. Fakticky stejne ty skutecne vykonne veci pobezi na X serverech s load balancerem a nastartovanou zalohou. A vzhledem k tomu jak je HW levny, nema smysl lovit nekde C / C++ profiky, kdyz ty Javisty sezenete snadneji a udelaji v kodu o trochu min chyb.
Asi nejspravnejsi odpoved je, ze Java se snazi byt bezpecnejsi nez C / C++ a to neco stoji, ale musite se hodne snazit, abyste nasel tak fatalni pripad, kdy budete 3x pomalejsi, v realu to bude nekde 1.xyz pomalejsi.
-
Meow ! ...
Jako vzdy, nevysychajici studnice vedomosti ;D.
si piš
-
Meow ! ...
Jako vzdy, nevysychajici studnice vedomosti ;D.
si piš
Jenom noef zapomnel zduraznit ze otravena...
-
k te me miniankete:
odpovedi jsou vesmes jak pred rokem, tj Eclipse a par ide, dal vesmes utilitky.
krom vlastni naprosti priserne zkusenosti s Eclipse ( pomaly, sem tam lagy, pametozrout, sem tam crash) ostiatni neznam primo, nicmene i kdyby byly super, nesplnuji podstatu dotazu, tj neni mozne na nich poznat pouzitelnost jazyka.
upresnim, ocekaval bych aplikaci co zatizi cpu (skutecnou cinnosti, ne svou neefektivitou), jsou vypocetne pametove i IO narocne (opet ale jen svym principialnim uzitim, ne spatnym kodem).
od IDE neocekavam ze bude zrat > 5% cpu,mem,io takze IDE lze psal v jakemkoli jazyku, pokud clovek neni prase....
takze bud jsem prehlidl nebo se stale nejaky java klenot hleda:-)
-
Tázající zřejmě ví že je pomalejší a nepotřebuje o tom poučovat.
Pokud to ví, má to napsat. Má napsat, co je pomalejší, kdy je to pomalejší, jak měří, že je to pomalejší. Pak mu někdo může poradit.
Tadle celá diskuze je padlá na hlavu.
Já si fakt připadám jak na exkurzi do 1984, kde se taky kecali totální sračky, ale pochvilce výkladu začli i celkem dávat smysl.
Na tom, že je ta diskuse padlá na hlavu, máte zrovna vy lví podíl. Totální nesmysly tu píšete právě vy, a když si dovolím zeptat se, co jste tím obecným prohlášením myslel a jestli pro něj máte nějaký důkaz, nezmůžete se na nic jiného, než na urážky.
Když někdo tvrdí, že je něco rychlejší, měl by být schopen napsat, co to ta rychlost je a jak ji měří. To tady zatím neudělal nikdo z těch, kteří tvrdí, že je nějaký jazyk rychlejší než jiný jazyk. Pokud je to pro vás tak jednoduché, nemůže pro vás přeci být žádný problém to srozumitelně popsat. Vzhledem k tomu, že to ještě nikdo neudělal, jeví se jako pravděpodobné, že ta tvrzení o rychlosti jsou jenom ničím nepodložené plky. Které jejich autoři pouze někde zahlédli na internetu, ale vůbec jim nerozumí, takže nejsou schopni je ani obhájit, ale dokonce ani vysvětlit, co podle nich vlastně znamenají.
Takže vážení, Ondro a Filipe, máte pravdu, Java (JVM ... Oracle™ JVM) je úplně to nejrychlejší v celé poznané a nepoznané galaxii.
Nic takového tu nikdo netvrdil. To, že vy nejste schopen svá tvrzení jakkoli doložit nebo obhájit, neznamená, že platí tvrzení opačná. Tak ještě jednou, třeba to konečně pochopíte: problém není v tom, že by z toho tvrzení vycházela Java špatně. Úplně stejně nesmyslné by to tvrzení bylo, i kdybyste psal, že je Java 1000× rychlejší. Problém je totiž v tom, že to tvrzení je nesmyslné, nedává žádný smysl mluvit obecně o „rychlosti jazyka“.
A i kdyby kecal sračky, proč vás to proboha tak tankuje, to Javu (JVM ... Oracle™ JVM) o volným čase šukáte takže to berete jako urážku cti? Nebo jako co?
Nadávkami a nesmysly tu svá tvrzení „obhajujete“ vy. To, co tu bylo napsáno, není urážka cti a není to nic proti Javě, C, C++ nebo proti čemukoli jinému. Jde jenom o to, že psát o „rychlosti jazyka“ je nesmysl. Původní tazatel nad tím možná nepřemýšlel a napsal, co někde zaslechl. To je v pořádku, diskuse je od toho, aby mu někdo vysvětlil, že neexistuje žádná „rychlost jazyka“ a že porovnávání programovacích jazyků je poněkud komplikovanější, a je závislé na řešených úlohách – pro různé úlohy budou různá kritéria. Zbytek diskuse je pak už jenom o tom, aby se neznalý tazatel dozvěděl, kterým směrem má pátrat, když se chce přiblížit pravdě, a aby nenaletěl těm vašim nesmyslům, které tu píšete.
no, to ty jsi se mi pověsil na ocas jakmile sem napsal něco proti královně :D
Vzhledem k tvým promakaným úskokům, hraní si se slovy a agresivitě, nepochybuju že si nikdy nikoho nepřesvětdčil o svojí pravdě i kdyby to nakrásně pravda byla.
-
Meow ! ...
Jako vzdy, nevysychajici studnice vedomosti ;D.
si piš
Jenom noef zapomnel zduraznit ze otravena...
ale notak ...
-
k te me miniankete:
odpovedi jsou vesmes jak pred rokem, tj Eclipse a par ide, dal vesmes utilitky.
krom vlastni naprosti priserne zkusenosti s Eclipse ( pomaly, sem tam lagy, pametozrout, sem tam crash) ostiatni neznam primo, nicmene i kdyby byly super, nesplnuji podstatu dotazu, tj neni mozne na nich poznat pouzitelnost jazyka.
upresnim, ocekaval bych aplikaci co zatizi cpu (skutecnou cinnosti, ne svou neefektivitou), jsou vypocetne pametove i IO narocne (opet ale jen svym principialnim uzitim, ne spatnym kodem).
od IDE neocekavam ze bude zrat > 5% cpu,mem,io takze IDE lze psal v jakemkoli jazyku, pokud clovek neni prase....
takze bud jsem prehlidl nebo se stale nejaky java klenot hleda:-)
Nejsou IDE, tim myslim poradna IDE jako IDEA s napr. type-aware autocomplete (ne textove editory), prave jedny z nejkomplikovanejsich dekstopovych aplikaci?
Rekl bych, ze porad jen menite zadani tak, aby to zadna aplikace v Jave nesplnovala a pak si vyvodite nesmyslny zaver, ze "neexistuji zadne desktopove aplikace v Jave". Vase puvodni podminky splnuje i ten Minecraft, ktery je poctem uzivatelu zatracene vysoko, mozna i vys nez ta ruzna IDE. By me celkem zajimalo, jake desktopove aplikace v jinych jazycich splnuji vase stale-se-menici zadani?
-
.....
Ach jo - pokud pouzivate vubec nejaky banking (to jest penize nedostavate v obalce), tak ty transakce jdou pres servery na kterych bezi java applikace. stejne tak obchody na burzach. a tak dale a tak dale ....
Neznepokuje vas trochu, ze vase financni situace, zdravi i pohodli zavisi z casti na aplikacich napsanych v Jave ?
Hrozna predstava, ticha pliziva Java otravuje telni tekutiny ceckaru a pythonistu ;)
-
to se vubec neda rici obecne, ze penezni transakce a obchodovani na burze jde pres Java servery..... neplest prosim aplikaci na interbenking s statnimi systemy
-
to se vubec neda rici obecne, ze penezni transakce a obchodovani na burze jde pres Java servery..... neplest prosim aplikaci na interbenking s statnimi systemy
ja si to nepletu :) proste delam pro jednu banku a vidim, co nam bezi na serverech
-
neznam primo, nicmene i kdyby byly super, nesplnuji podstatu dotazu, tj neni mozne na nich poznat pouzitelnost jazyka.
To vy jste omezil výběr jen na desktopové aplikace, o použitelnosti jazyka nebyla řeč.
upresnim, ocekaval bych aplikaci co zatizi cpu (skutecnou cinnosti, ne svou neefektivitou), jsou vypocetne pametove i IO narocne (opet ale jen svym principialnim uzitim, ne spatnym kodem).
Tohle už je vaše třetí kritérium výběru. Nejdřív desktop, pak použitelnost jazyka, a nakonec zatížení CPU a IO. To jsou tři různá kritéria. Netuším, proč jste si vybral zrovna tahle tři kritéria. Ale klidně vám řeknu, jak se to s nimi a s Javou má.
Desktopové aplikace nejsou silnou stránkou Javy, zejména proto, že Sun a později Oracle na desktopovou Javu kašlou. Takže s použitím Javy pro desktopovou aplikaci není problém, má to své výhody ale i nevýhody, Javu určitě stojí za to zvážit, ale má minimálně rovnocenné konkurenty.
Použitelnost jazyka, to asi samo o sobě nemá smysl hodnotit, takže spíš použitelnost platformy. Tady si myslím, že je Java na špičce, protože má obrovský a jednotný ekosystém. V Javě můžete programovat od mobilních aplikací po zpracování BigData v cloudu. Pokud potřebujete prostředí pro integraci, je Java jasná volba.
Zatížení CPU a IO – tohle není doména Javy a pokud je nějaká aplikace zaměřená jen na tohle, asi nebude moc důvod vybrat si zrovna Javu. Většinou tohle ale budou spíš jen nějaké části nebo komponenty, které napíšete v C, a pak je klidně použijete z jiného jazyka (Python, Java, JavaScript…) Dále to také často může vést k tomu, že vám zatížení jednoho CPU a IP na jedné sběrnici nestačí, ale že potřebujete cluster – a tam už s to s tím C zase nebude tak slavné, protože potřebujete vícevláknovou aplikaci a síťovou komunikaci, a tady už zase může být výhoda v tom, že to v Javě napíšete snadno (respektive spíš poskládáte z už hotových komponent). Ale to zadání je velmi obecné, takže stejně „rozplizlá“ musí být i odpověď – ve skutečnosti totiž nikdo nechce zatížit CPU (ani smysluplným kódem), ale potřebuje řešit nějaký problém – a vytížit CPU je jenom jedno z možných řešení problému.
takze bud jsem prehlidl nebo se stale nejaky java klenot hleda:-)
Spíš se ptáte na oblasti, které nejsou doménou Javy, a snažíte se tam najít nějakou skutečnou perlu, která s přehledem strčí ostatní do kapsy. Ale když tu byla zmíněna ta IDE, zkuste uvést příklad nějakého IDE srovnatelného s Eclipse, NetBEans nebo IntelliJ Ideou, které bude napsané v C nebo (ať máte šanci) v C++.
-
Ale když tu byla zmíněna ta IDE, zkuste uvést příklad nějakého IDE srovnatelného s Eclipse, NetBEans nebo IntelliJ Ideou, které bude napsané v C nebo (ať máte šanci) v C++.
IDE považuji za aplikaci, která slouží pouze vývojářům. Takový vývoj pro vývoj. Spíš bych uvítal srovnání nějakých non-IT aplikací. Co třeba nějaký webový klient, účetnictví, střižna videa, 3D modelování, ... ?
-
java nema velke zastupenie na desktope lebo neexistuje nejake rozumne desktopove rozhranie napisane v Jave. Ale keby niekto preportoval QT alebo GTK alebo hocico ine do javy,tak by si nikto rozdiel ci to je pisane v C alebo v jave nevsimol :)
Jednoducho len chyba ta cast komunity, lebo Javisti sa zdrziavaju v enterprise povacsinou s vynimkou android devs ale to je nizsie, tak naco by minali svoj cas na takuto cinnost? :)
Ale kde zas java dominuje? :) v com existuje java API? zeby android? kolko % aplikacii v androide je napisanych v nativnom API a kolko v Jave? 99%? Keby google napisal api pre C, tak by v nom isto existovali aplikacie, ale potom by nemal ekosystem ktory funguje na x86 atomoch, ARM rozne architektury etc. out of the box
-
Ale když tu byla zmíněna ta IDE, zkuste uvést příklad nějakého IDE srovnatelného s Eclipse, NetBEans nebo IntelliJ Ideou, které bude napsané v C nebo (ať máte šanci) v C++.
IDE považuji za aplikaci, která slouží pouze vývojářům. Takový vývoj pro vývoj. Spíš bych uvítal srovnání nějakých non-IT aplikací. Co třeba nějaký webový klient, účetnictví, střižna videa, 3D modelování, ... ?
Co treba vase bankovni karta ?
Co treba asi bambilion appek na Androidu ?
Co treba Minecraft ?
Jinak Java je vazne spis backendova zalezitost, od Hadoop pres ElasticSearch po proprietarni reseni v korporatu.
-
Heh, dobra komedie.
Realita je pritom tak prosta.
Java je "obvykle" pri vykonavani "bezneho" kodu o cca 10 - 15% pomalejsi nez C++. Java pozaduje cca 20-30% vice pameti nez C++. Za to Java nabizi veci, ktere C++ nikdy neda, Spring Boot framework v C++ opravdu nenapisete. Tolik obecna generalizace.
Java navic dovede pri dlouhodobem behu programu (nepzr J2EE aplikacni server) kod optimalizovat a pak je i rychlejsi nez C++.
Dalsi aspekt je doba nutna pro start JVM. Pokud tu nekdo (nebudeme jmenovat) s vaznou tvari linkuje "benchmark", ktery ukazuje ze C++ kod trval 1 sec a Java kod 3 sec (z cehoz 2 sec startoval JVM) a vyvozuje z toho, ze Java je 3x pomalejsi, pak ano, dotycny je hnup.
Videl jsem dokonce vazne mineny "benchmark", kde nejaky jouda v ruby mel cyklus 1000 iteraci jakesi ruby funkce a potom implementoval funkci v jave a volal ji v jave pres system exec - z tohoto "testu" vyvodil, ze java je cca 100x pomalejsi nez ruby...
-
Java navic dovede pri dlouhodobem behu programu (nepzr J2EE aplikacni server) kod optimalizovat a pak je i rychlejsi nez C++.
Nějaký konkrétní příklad? Tohle tvrzení jsem četl mnohokrát, ale ještě jsem neviděl kód, pro který to platí.
Dalsi aspekt je doba nutna pro start JVM. Pokud tu nekdo (nebudeme jmenovat) s vaznou tvari linkuje "benchmark", ktery ukazuje ze C++ kod trval 1 sec a Java kod 3 sec (z cehoz 2 sec startoval JVM) a vyvozuje z toho, ze Java je 3x pomalejsi, pak ano, dotycny je hnup.
V tom benchmarku se startup time nezapočítává.
Videl jsem dokonce vazne mineny "benchmark", kde nejaky jouda v ruby mel cyklus 1000 iteraci jakesi ruby funkce a potom implementoval funkci v jave a volal ji v jave pres system exec - z tohoto "testu" vyvodil, ze java je cca 100x pomalejsi nez ruby...
Kde jste to viděl?
-
IDE považuji za aplikaci, která slouží pouze vývojářům.
Myslíte, že vývojáři sami sebe odbývají nějakým šuntem a to nejlepší programují pro ostatní? A nebo naopak IDE musí být špičkový program, protože když dáte sekretářce špatný textový editor, bude nadávat, ale bude ho používat, zatímco když dáte špatné IDE programátorovi, začne programovat vlastní?
Co třeba nějaký webový klient
Apache HTTP Client, Jetty Client, Netty HTTP kodek, Google HTTP Client Library for Java a mnohé další. Nebo jste myslel prohlížeč?
účetnictví
FlexiBee
střižna videa
Uvítal bych jakoukoli použitelnou OSS i kdyby byla napsaná v Brainfucku.
3D modelování
Díval jste se na ty výše uvedené aplikace? ZEBRA (https://blogs.oracle.com/geertjan/entry/electromagnetic_simulation_integration_platform_on)
-
Nějaký konkrétní příklad? Tohle tvrzení jsem četl mnohokrát, ale ještě jsem neviděl kód, pro který to platí.
Jaký pro to používáte benchmark? (Předpokládám, že to své tvrzení máte něčím podložené, že to není jenom „nepátral jsem po tom, tudíž jsem to neviděl, tudíž to neexistuje“.)
-
Nějaký konkrétní příklad? Tohle tvrzení jsem četl mnohokrát, ale ještě jsem neviděl kód, pro který to platí.
Jaký pro to používáte benchmark? (Předpokládám, že to své tvrzení máte něčím podložené, že to není jenom „nepátral jsem po tom, tudíž jsem to neviděl, tudíž to neexistuje“.)
To zde tvrdíty vy a Youda. Jo na vás abyste poskytli příklad.
-
oprava:
Nějaký konkrétní příklad? Tohle tvrzení jsem četl mnohokrát, ale ještě jsem neviděl kód, pro který to platí.
Jaký pro to používáte benchmark? (Předpokládám, že to své tvrzení máte něčím podložené, že to není jenom „nepátral jsem po tom, tudíž jsem to neviděl, tudíž to neexistuje“.)
To zde tvrdíte vy a Youda. Jo na vás abyste poskytli příklad.
-
Nějaký konkrétní příklad? Tohle tvrzení jsem četl mnohokrát, ale ještě jsem neviděl kód, pro který to platí.
Jaký pro to používáte benchmark? (Předpokládám, že to své tvrzení máte něčím podložené, že to není jenom „nepátral jsem po tom, tudíž jsem to neviděl, tudíž to neexistuje“.)
To zde tvrdíty vy a Youda. Jo na vás abyste poskytli příklad.
https://cs.wikipedia.org/wiki/HotSpot
A jak vidno z popisu technologie, priklad ti nikdo neposle protoze HotSpot optimalizace ja na urovni bytecode -> strojove instrukce a se zdrojakem nema nic spolecneho.
Zjednosduseny popis je takovy, ve JVM vytipovava "horke" kusy kodu (nejpouzivanejsi casti) a spekulativne zkousi ruzne optimalizace kompileru. Kdysi jsem videl nejaky clanek, ktery to popisoval na systemu co zpracovaval stram prichozich messages a pro velke messages a male messages (java objekty) to nakonec zkompilovalo jinak.
Je to defacto mix gentoo (kompilovani na miru zeleza) s genetickymi algoritmy.
-
k te me miniankete:
odpovedi jsou vesmes jak pred rokem, tj Eclipse a par ide, dal vesmes utilitky.
krom vlastni naprosti priserne zkusenosti s Eclipse ( pomaly, sem tam lagy, pametozrout, sem tam crash) ostiatni neznam primo, nicmene i kdyby byly super, nesplnuji podstatu dotazu, tj neni mozne na nich poznat pouzitelnost jazyka.
upresnim, ocekaval bych aplikaci co zatizi cpu (skutecnou cinnosti, ne svou neefektivitou), jsou vypocetne pametove i IO narocne (opet ale jen svym principialnim uzitim, ne spatnym kodem).
od IDE neocekavam ze bude zrat > 5% cpu,mem,io takze IDE lze psal v jakemkoli jazyku, pokud clovek neni prase....
takze bud jsem prehlidl nebo se stale nejaky java klenot hleda:-)
Nejsou IDE, tim myslim poradna IDE jako IDEA s napr. type-aware autocomplete (ne textove editory), prave jedny z nejkomplikovanejsich dekstopovych aplikaci?
Rekl bych, ze porad jen menite zadani tak, aby to zadna aplikace v Jave nesplnovala a pak si vyvodite nesmyslny zaver, ze "neexistuji zadne desktopove aplikace v Jave". Vase puvodni podminky splnuje i ten Minecraft, ktery je poctem uzivatelu zatracene vysoko, mozna i vys nez ta ruzna IDE. By me celkem zajimalo, jake desktopove aplikace v jinych jazycich splnuji vase stale-se-menici zadani?
no, to nejsou. kod sice mozou mit celkem kosaty, ale z pohledu jazyku a jejich dospelosti pro realny svet jsou to naprosto nenarocne veci. cpu by nemely zrat vubec...vzdyt co delaji? nejnarocnejsi operace je nejspis neco jako hledani v nejakem indexu, databazi. je rok 2016 a tohle fakt neni nic u ceho by se mel system zapotit.....
a co vlastne hledam....no zacnu ciste ze sveta v kterem se ja pohybuju tj. napriklad vizualizacni sw jako zbrush,maya,max...ruzne archviz, dynamics, finite elements, kapalinove simulace, treba nejaky vetsi cad....atd. proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze, klidne muzou byt ruzna data mining, expertni systemy, kompexnejsi databaze, deep learning, analyza reci, proste cokoli kde se hw zapoti tim,ze resi kompexni problemy, nejen ze resi samy sebe...
-
Zjednosduseny popis je takovy, ve JVM vytipovava "horke" kusy kodu (nejpouzivanejsi casti) a spekulativne zkousi ruzne optimalizace kompileru. Kdysi jsem videl nejaky clanek, ktery to popisoval na systemu co zpracovaval stram prichozich messages a pro velke messages a male messages (java objekty) to nakonec zkompilovalo jinak.
To zní hezky, problém je ovšem v tom, že na složitější optimalizace je při běhu v produkci málo času a paměti.
Je to defacto mix gentoo (kompilovani na miru zeleza) s genetickymi algoritmy.
To je AFAIK hodně vzdálená charakteristika - produkční JVM si nemůže dovolit zkoušet "optimalizace", které mají katastrofální vliv na výkon (na rozdíl od genetického algoritmu) - nekonzistentní a těžko předvídatelné chování JVM by se uživatelům příliš nelíbilo.
-
Java navic dovede pri dlouhodobem behu programu (nepzr J2EE aplikacni server) kod optimalizovat a pak je i rychlejsi nez C++.
Nějaký konkrétní příklad? Tohle tvrzení jsem četl mnohokrát, ale ještě jsem neviděl kód, pro který to platí.
A neplati to pro kazdou NE unrollnutou smycku a pro kazdou NE inlajnutou funkci ? Java JIT compiler tyhle optimalizace dela. C/C++ compiler to bez hintu udela ? (Se ptam, C jsem naposledy resil na skole).
-
https://cs.wikipedia.org/wiki/HotSpot
A jak vidno z popisu technologie, priklad ti nikdo neposle protoze HotSpot optimalizace ja na urovni bytecode -> strojove instrukce a se zdrojakem nema nic spolecneho.
To je ale škoda, protože v takovém příkladu by byl krásně vidět kód v Javě, bytekód, a generované strojové instrukce, třeba pro oba /dva+/ optimalizované případy. Potom bychom to mohli krásně v benchmarku srovnat, ne že ne.
-
Java navic dovede pri dlouhodobem behu programu (nepzr J2EE aplikacni server) kod optimalizovat a pak je i rychlejsi nez C++.
Nějaký konkrétní příklad? Tohle tvrzení jsem četl mnohokrát, ale ještě jsem neviděl kód, pro který to platí.
A neplati to pro kazdou NE unrollnutou smycku a pro kazdou NE inlajnutou funkci ? Java JIT compiler tyhle optimalizace dela. C/C++ compiler to bez hintu udela ? (Se ptam, C jsem naposledy resil na skole).
Java JIT tyto optimalizace dělá jen za určitých podmínek - např. když počet instrukcí v těle metody nepřekračuje určité číslo. Navíc není vždy zaručeno, že tyto optimalizace zvýší výkon a naopak ho nesníží.
Kromě toho kompilátor C++ to dokáže i bez hintu.
-
Videl jsem dokonce vazne mineny "benchmark", kde nejaky jouda v ruby mel cyklus 1000 iteraci jakesi ruby funkce a potom implementoval funkci v jave a volal ji v jave pres system exec - z tohoto "testu" vyvodil, ze java je cca 100x pomalejsi nez ruby...
Kde jste to viděl?
http://mrcook.uk/golang-vs-java-performance
Posledni komentar zacinajici "OMG!!!" jsem psal ja.
A autor pridal porovnani, kdy java iteruje sama, voila java zrychlila z 1200 se na 60 sec.
-
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ě).
-
...
Java JIT tyto optimalizace dělá jen za určitých podmínek - např. když počet instrukcí v těle metody nepřekračuje určité číslo. Navíc není vždy zaručeno, že tyto optimalizace zvýší výkon a naopak ho nesníží.
...
No, ale C++ to snad pri spatnem vykonu po spusteni nemuze od-inlinovat jako JVM. Takze kdyz se C++ prekladac netrefi do kristalove koule, tak je program navzdy pomaly. Kdyz se netrefi JVM, tak (pokud si dobre pamatuju) tu spatnou optimalizaci zahodi a jede s puvodni vykonejsi variantou.
no, to nejsou.
No, to jste me teda presvedcil. Nejake argumenty by nebyly?
kod sice mozou mit celkem kosaty, ale z pohledu jazyku a jejich dospelosti pro realny svet jsou to naprosto nenarocne veci. cpu by nemely zrat vubec...vzdyt co delaji? nejnarocnejsi operace je nejspis neco jako hledani v nejakem indexu, databazi. je rok 2016 a tohle fakt neni nic u ceho by se mel system zapotit.....
To myslite vazne? Bavim o IDE, ne o textovem editoru ala Vim nebo Atom, tam by hledani v trapnem indexu ID stacilo. Dnesni IDE provadi na pozadi preklad a podle toho naseptavaji, jaky typ se hodi do aktulane psaneho vyrazu na danem miste. V podstate ihned zobrazuji syntakticke chyby, ktere mohou vyplyvat z interakce veci z nekolika ruznych trid nebo celych knihoven. Treba ta IDEA si snad i prekladac nekterych jazyku napsala od piky sama, jen aby mohla lepe naseptavat...
Se asi pujdu podivat, jak je to s tou velikosti IDE, protoze se mi nezda, ze jsou tak male, jak se snazite podsunout.
-
...
Java JIT tyto optimalizace dělá jen za určitých podmínek - např. když počet instrukcí v těle metody nepřekračuje určité číslo. Navíc není vždy zaručeno, že tyto optimalizace zvýší výkon a naopak ho nesníží.
...
No, ale C++ to snad pri spatnem vykonu po spusteni nemuze od-inlinovat jako JVM. Takze kdyz se C++ prekladac netrefi do kristalove koule, tak je program navzdy pomaly. Kdyz se netrefi JVM, tak (pokud si dobre pamatuju) tu spatnou optimalizaci zahodi a jede s puvodni vykonejsi variantou.
no, to nejsou.
No, to jste me teda presvedcil. Nejake argumenty by nebyly?
kod sice mozou mit celkem kosaty, ale z pohledu jazyku a jejich dospelosti pro realny svet jsou to naprosto nenarocne veci. cpu by nemely zrat vubec...vzdyt co delaji? nejnarocnejsi operace je nejspis neco jako hledani v nejakem indexu, databazi. je rok 2016 a tohle fakt neni nic u ceho by se mel system zapotit.....
To myslite vazne? Bavim o IDE, ne o textovem editoru ala Vim nebo Atom, tam by hledani v trapnem indexu ID stacilo. Dnesni IDE provadi na pozadi preklad a podle toho naseptavaji, jaky typ se hodi do aktulane psaneho vyrazu na danem miste. V podstate ihned zobrazuji syntakticke chyby, ktere mohou vyplyvat z interakce veci z nekolika ruznych trid nebo celych knihoven. Treba ta IDEA si snad i prekladac nekterych jazyku napsala od piky sama, jen aby mohla lepe naseptavat...
Se asi pujdu podivat, jak je to s tou velikosti IDE, protoze se mi nezda, ze jsou tak male, jak se snazite podsunout.
nejsem neomylny, pouzivam ale Visual Studio jako IDE, coz patri spis vic k tem komplexnejsim, presto ho nikde v top cpu, mem, io nevidim, je nenarocne na vykone (v podstate mui staci reagovat rychlosti cloveka, jak ten kod pise:-) takze aplikovat nejaky search(i kdyz ne uplne trivialni 5x za sekundu by to zvladlo by to zvladlo snad v libovolnem jazyce.
-
...
Nejsou IDE, tim myslim poradna IDE jako IDEA s napr. type-aware autocomplete (ne textove editory), prave jedny z nejkomplikovanejsich dekstopovych aplikaci?
Rekl bych, ze porad jen menite zadani tak, aby to zadna aplikace v Jave nesplnovala a pak si vyvodite nesmyslny zaver, ze "neexistuji zadne desktopove aplikace v Jave". Vase puvodni podminky splnuje i ten Minecraft, ktery je poctem uzivatelu zatracene vysoko, mozna i vys nez ta ruzna IDE. By me celkem zajimalo, jake desktopove aplikace v jinych jazycich splnuji vase stale-se-menici zadani?
no, to nejsou. kod sice mozou mit celkem kosaty, ale z pohledu jazyku a jejich dospelosti pro realny svet jsou to naprosto nenarocne veci. cpu by nemely zrat vubec...vzdyt co delaji? nejnarocnejsi operace je nejspis neco jako hledani v nejakem indexu, databazi. je rok 2016 a tohle fakt neni nic u ceho by se mel system zapotit.....
a co vlastne hledam....no zacnu ciste ze sveta v kterem se ja pohybuju tj. napriklad vizualizacni sw jako zbrush,maya,max...ruzne archviz, dynamics, finite elements, kapalinove simulace, treba nejaky vetsi cad....atd. proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze, klidne muzou byt ruzna data mining, expertni systemy, kompexnejsi databaze, deep learning, analyza reci, proste cokoli kde se hw zapoti tim,ze resi kompexni problemy, nejen ze resi samy sebe...
$ cloc blender-2.78a.tar/blender-2.78a | tee blender_stats.txt
7573 text files.
7534 unique files.
539 files ignored.
http://cloc.sourceforge.net v 1.60 T=19.52 s (360.5 files/s, 141850.5 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 1209 199927 132849 853513
C++ 1533 74439 75523 407681
C/C++ Header 3048 104375 158525 379963
Python 956 54875 43780 217801
CMake 206 3092 5043 18257
XML 22 0 0 12034
Javascript 8 1867 1774 8078
Bourne Shell 18 903 470 4019
Objective C++ 7 786 474 2889
HTML 6 92 2 1104
OpenCL 13 162 303 1021
Objective C 2 229 106 949
CSS 5 80 154 747
make 2 81 78 332
DOS Batch 1 23 14 237
-------------------------------------------------------------------------------
SUM: 7036 440931 419095 1908625
-------------------------------------------------------------------------------
$ cloc intellij-community-master/intellij-community-master/ | tee idea_stats.txt
79146 text files.
73722 unique files.
11995 files ignored.
http://cloc.sourceforge.net v 1.60 T=132.93 s (485.6 files/s, 46463.7 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
Java 49769 591983 707529 3305910
Python 6875 105711 156920 423533
XML 1777 9451 3072 245739
Javascript 1189 10481 33715 153307
XSD 259 14633 3095 148722
Groovy 1994 15816 13721 75915
HTML 2111 6083 3771 55425
C 17 2353 6452 21958
DTD 86 5038 8746 14809
CSS 44 1175 477 5117
Maven 54 235 711 4654
C++ 16 668 497 3538
XSLT 107 367 81 2133
Ant 16 346 89 2007
Cython 6 373 286 1336
DOS Batch 17 334 59 1289
Bourne Shell 27 256 437 1203
C/C++ Header 25 350 431 1136
Objective C 6 149 46 598
YAML 83 77 8 494
Bourne Again Shell 5 58 53 312
Scala 1 21 26 258
Perl 4 38 1 223
JavaServer Faces 7 37 18 181
Ruby 2 15 5 103
CoffeeScript 3 7 10 79
C# 42 3 3 77
make 2 20 1 61
JSP 7 5 22 44
CMake 1 5 0 14
Visual Basic 1 0 0 1
Erlang 1 0 0 1
--------------------------------------------------------------------------------
SUM: 64554 766088 940282 4470177
--------------------------------------------------------------------------------
Takze Blender vs IDEA na LOC to vychazi 1 908 625 vs 4 470 177. :D Takze nejen, ze Blender oproti IDEA ma mene radku, coz jaksi neodpovida tomu vasemu "skoro to nic nedela" a "neni poradna desktop aplikace", ale navic ma IDEA tech radku jednou tolik, co Blender. ;D Nope, zatim jste me teda nepresvedcil.
-
...
Nejsou IDE, tim myslim poradna IDE jako IDEA s napr. type-aware autocomplete (ne textove editory), prave jedny z nejkomplikovanejsich dekstopovych aplikaci?
Rekl bych, ze porad jen menite zadani tak, aby to zadna aplikace v Jave nesplnovala a pak si vyvodite nesmyslny zaver, ze "neexistuji zadne desktopove aplikace v Jave". Vase puvodni podminky splnuje i ten Minecraft, ktery je poctem uzivatelu zatracene vysoko, mozna i vys nez ta ruzna IDE. By me celkem zajimalo, jake desktopove aplikace v jinych jazycich splnuji vase stale-se-menici zadani?
no, to nejsou. kod sice mozou mit celkem kosaty, ale z pohledu jazyku a jejich dospelosti pro realny svet jsou to naprosto nenarocne veci. cpu by nemely zrat vubec...vzdyt co delaji? nejnarocnejsi operace je nejspis neco jako hledani v nejakem indexu, databazi. je rok 2016 a tohle fakt neni nic u ceho by se mel system zapotit.....
a co vlastne hledam....no zacnu ciste ze sveta v kterem se ja pohybuju tj. napriklad vizualizacni sw jako zbrush,maya,max...ruzne archviz, dynamics, finite elements, kapalinove simulace, treba nejaky vetsi cad....atd. proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze, klidne muzou byt ruzna data mining, expertni systemy, kompexnejsi databaze, deep learning, analyza reci, proste cokoli kde se hw zapoti tim,ze resi kompexni problemy, nejen ze resi samy sebe...
$ cloc blender-2.78a.tar/blender-2.78a | tee blender_stats.txt
7573 text files.
7534 unique files.
539 files ignored.
http://cloc.sourceforge.net v 1.60 T=19.52 s (360.5 files/s, 141850.5 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 1209 199927 132849 853513
C++ 1533 74439 75523 407681
C/C++ Header 3048 104375 158525 379963
Python 956 54875 43780 217801
CMake 206 3092 5043 18257
XML 22 0 0 12034
Javascript 8 1867 1774 8078
Bourne Shell 18 903 470 4019
Objective C++ 7 786 474 2889
HTML 6 92 2 1104
OpenCL 13 162 303 1021
Objective C 2 229 106 949
CSS 5 80 154 747
make 2 81 78 332
DOS Batch 1 23 14 237
-------------------------------------------------------------------------------
SUM: 7036 440931 419095 1908625
-------------------------------------------------------------------------------
$ cloc intellij-community-master/intellij-community-master/ | tee idea_stats.txt
79146 text files.
73722 unique files.
11995 files ignored.
http://cloc.sourceforge.net v 1.60 T=132.93 s (485.6 files/s, 46463.7 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
Java 49769 591983 707529 3305910
Python 6875 105711 156920 423533
XML 1777 9451 3072 245739
Javascript 1189 10481 33715 153307
XSD 259 14633 3095 148722
Groovy 1994 15816 13721 75915
HTML 2111 6083 3771 55425
C 17 2353 6452 21958
DTD 86 5038 8746 14809
CSS 44 1175 477 5117
Maven 54 235 711 4654
C++ 16 668 497 3538
XSLT 107 367 81 2133
Ant 16 346 89 2007
Cython 6 373 286 1336
DOS Batch 17 334 59 1289
Bourne Shell 27 256 437 1203
C/C++ Header 25 350 431 1136
Objective C 6 149 46 598
YAML 83 77 8 494
Bourne Again Shell 5 58 53 312
Scala 1 21 26 258
Perl 4 38 1 223
JavaServer Faces 7 37 18 181
Ruby 2 15 5 103
CoffeeScript 3 7 10 79
C# 42 3 3 77
make 2 20 1 61
JSP 7 5 22 44
CMake 1 5 0 14
Visual Basic 1 0 0 1
Erlang 1 0 0 1
--------------------------------------------------------------------------------
SUM: 64554 766088 940282 4470177
--------------------------------------------------------------------------------
Takze Blender vs IDEA na LOC to vychazi 1 908 625 vs 4 470 177. :D Takze nejen, ze Blender oproti IDEA ma mene radku, coz jaksi neodpovida tomu vasemu "skoro to nic nedela" a "neni poradna desktop aplikace", ale navic ma IDEA tech radku jednou tolik, co Blender. ;D Nope, zatim jste me teda nepresvedcil.
pocet radku neni relevantni, bavime se o vykone jazyka......nejme v 90 letech, kdy jazyky a prekladace meli i nejake limity v smyslu max radku file, max file / project atd....bavime se o real-time
-
btw ja niko nepresvedcuju, ja se vyptavam.......nejsem zaujatej, nemyslim ze je to o jazyku ale algoritmech.....jen me ale u javy (nejen, podobnych je vic) zarazi nedostatek kvalitnich veci v ni. ale jen jsem to chtel zuzit k real-time kvalite a vygenerovanem kodyu, at se to nevzrhne do debaty o kvalite vyvojaru, o lopatach a jinych nastrojich....
-
... proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze,...
Ten Minecraft vam nevoni? Na CPU a myslim i na GPU jsou voxelove svety zatracene narocne (proto se to zacina prosazovat az ted, protoze na to pc zacinaji mit vykon). Na io - disk spise narazove, na sit, pokud putujete po svete rychle, tak to take neni zanedbatelne. Ale chapu, ze to zase smetete ze stolu, ze to neni "poradna dekstop aplikace", protoze pridate dalsi podminku :).
Ne, asi se nema cenu se s vami bavit, pusobite jako trochu sofistikovanejsi trol. Nejdrive oznacite IDE za male projekty, ktere nic nedelaji. Kdyz vam predhodim fakta, ktera rikaji opak, tak si to zase okecate, ze najednou je potreba realtime. Kolikata podminka to uz je? Desktop aplikace, ktera je narocna na io, pamet, cpu, gpu, prikon, rozliseni, fps, spojeni se satelitem, zabudovanym ovladanim vodotrysku a spustite ji jen na desktopu s hw za dva miliony $?
-
... proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze,...
Ten Minecraft vam nevoni? Na CPU a myslim i na GPU jsou voxelove svety zatracene narocne (proto se to zacina prosazovat az ted, protoze na to pc zacinaji mit vykon). Na io - disk spise narazove, na sit, pokud putujete po svete rychle, tak to take neni zanedbatelne. Ale chapu, ze to zase smetete ze stolu, ze to neni "poradna dekstop aplikace", protoze pridate dalsi podminku :).
Ne, asi se nema cenu se s vami bavit, pusobite jako trochu sofistikovanejsi trol. Nejdrive oznacite IDE za male projekty, ktere nic nedelaji. Kdyz vam predhodim fakta, ktera rikaji opak, tak si to zase okecate, ze najednou je potreba realtime. Kolikata podminka to uz je? Desktop aplikace, ktera je narocna na io, pamet, cpu, gpu, prikon, rozliseni, fps, spojeni se satelitem, zabudovanym ovladanim vodotrysku a spustite ji jen na desktopu s hw za dva miliony $?
Minecraft je jiste zajimava volba.....nicmene Minecraft prorazil nikoli technickou strankou ale napadem (ostatni vizualni kvalita je zcela zamerne retro oldskulova az indie :-)
-
... proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze,...
Ne, asi se nema cenu se s vami bavit, pusobite jako trochu sofistikovanejsi trol. Nejdrive oznacite IDE za male projekty, ktere nic nedelaji. Kdyz vam predhodim fakta, ktera rikaji opak, tak si to zase okecate, ze najednou je potreba realtime. Kolikata podminka to uz je? Desktop aplikace, ktera je narocna na io, pamet, cpu, gpu, prikon, rozliseni, fps, spojeni se satelitem, zabudovanym ovladanim vodotrysku a spustite ji jen na desktopu s hw za dva miliony $?
ja nikoho neurazim. ale vy asi nectete pozorne co pisu, maximalne slusne receno:-)
nebavime se o velikosti projektu jako takoveho ale VYKONU. celou dobu, nemenim zadani, celou dobu pisu konzistetne o RESOURCE_HEAVY aplikacich, nikoliv o velkych projektech dle LoC metriky. to je prece irelevantni pri debate o rychlosti kodu prece. neprijde mi to jako velka dusevni ekvilibristika pochopit na co se ptam....
-
...
Java JIT tyto optimalizace dělá jen za určitých podmínek - např. když počet instrukcí v těle metody nepřekračuje určité číslo. Navíc není vždy zaručeno, že tyto optimalizace zvýší výkon a naopak ho nesníží.
...
Takze kdyz se C++ prekladac netrefi do kristalove koule, tak je program navzdy pomaly.
Ano. Na druhé straně kompilátory C++ podporují profilováním řízené optimalizace - tj. nemusí to být věštění z křišťálové koule.
Na rozdíl od JVM je na profilování i kompilaci dost času a paměti, což je výhoda. Nevýhodou naopak je, že C++ kompilátor nemůže reagovat, když se program začne používat jiným způsobem, pro který nebyl optimalizován.
Kdyz se netrefi JVM, tak (pokud si dobre pamatuju) tu spatnou optimalizaci zahodi a jede s puvodni vykonejsi variantou.
Ano, neznám však detaily.
BTW v tomto kontextu je zajímavý projekt Sulong (https://github.com/graalvm/sulong), který zkouší spouštět C v Graal VM.
-
nebavime se o velikosti projektu jako takoveho ale VYKONU. celou dobu, nemenim zadani, celou dobu pisu konzistetne o RESOURCE_HEAVY aplikacich, nikoliv o velkych projektech dle LoC metriky. to je prece irelevantni pri debate o rychlosti kodu prece. neprijde mi to jako velka dusevni ekvilibristika pochopit na co se ptam....
Nejnáročnějšími aplikacemi na výkon jsou simulace. Na těch mi Java vyšla o něco pomalejší než C, ale nebyla to žádná hrůza - bylo to nějakých 10-20 %. Spíš jsem postrádal některé datové typy, které v Javě prostě nejsou a musí se složitě emulovat. Zlatej Fortran.
-
na simulacie FPGA FTW! alebo nejaky asic koprocesor, naco sa obtazovat nejakym programovanim.
-
... proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze,...
Ten Minecraft vam nevoni? Na CPU a myslim i na GPU jsou voxelove svety zatracene narocne (proto se to zacina prosazovat az ted, protoze na to pc zacinaji mit vykon). Na io - disk spise narazove, na sit, pokud putujete po svete rychle, tak to take neni zanedbatelne. Ale chapu, ze to zase smetete ze stolu, ze to neni "poradna dekstop aplikace", protoze pridate dalsi podminku :).
Ne, asi se nema cenu se s vami bavit, pusobite jako trochu sofistikovanejsi trol. Nejdrive oznacite IDE za male projekty, ktere nic nedelaji. Kdyz vam predhodim fakta, ktera rikaji opak, tak si to zase okecate, ze najednou je potreba realtime. Kolikata podminka to uz je? Desktop aplikace, ktera je narocna na io, pamet, cpu, gpu, prikon, rozliseni, fps, spojeni se satelitem, zabudovanym ovladanim vodotrysku a spustite ji jen na desktopu s hw za dva miliony $?
Minecraft je jiste zajimava volba.....nicmene Minecraft prorazil nikoli technickou strankou ale napadem (ostatni vizualni kvalita je zcela zamerne retro oldskulova az indie :-)
Co to meleš? On ti píše, že nic náročnějšího není a ty začneš zase nějaké nesmysly :D Technickou stránkou právě všechny porazil.
-
Co to meleš? On ti píše, že nic náročnějšího není a ty začneš zase nějaké nesmysly :D Technickou stránkou právě všechny porazil.
Ale prosímtě, minecraft v Javě je z hlediska výkonu dost tragédie, C++ verze je násobně rychlejší:
https://www.youtube.com/watch?v=dKgQwaKQ87Y
http://www.zdnet.com/article/minecrafts-new-education-edition-written-in-c-will-outrun-the-java-version/
Nějak nám ty super hyper hotspot runtime optimalizace moc nefungují, že?
-
... proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze,...
Ten Minecraft vam nevoni? Na CPU a myslim i na GPU jsou voxelove svety zatracene narocne (proto se to zacina prosazovat az ted, protoze na to pc zacinaji mit vykon). Na io - disk spise narazove, na sit, pokud putujete po svete rychle, tak to take neni zanedbatelne. Ale chapu, ze to zase smetete ze stolu, ze to neni "poradna dekstop aplikace", protoze pridate dalsi podminku :).
Ne, asi se nema cenu se s vami bavit, pusobite jako trochu sofistikovanejsi trol. Nejdrive oznacite IDE za male projekty, ktere nic nedelaji. Kdyz vam predhodim fakta, ktera rikaji opak, tak si to zase okecate, ze najednou je potreba realtime. Kolikata podminka to uz je? Desktop aplikace, ktera je narocna na io, pamet, cpu, gpu, prikon, rozliseni, fps, spojeni se satelitem, zabudovanym ovladanim vodotrysku a spustite ji jen na desktopu s hw za dva miliony $?
Minecraft je jiste zajimava volba.....nicmene Minecraft prorazil nikoli technickou strankou ale napadem (ostatni vizualni kvalita je zcela zamerne retro oldskulova az indie :-)
Co to meleš? On ti píše, že nic náročnějšího není a ty začneš zase nějaké nesmysly :D Technickou stránkou právě všechny porazil.
no nevim, hry me zivily 8 let (AAA), voxelove enginy jsou soucasti demo sceny konce 20 stoleti, osobne jsem napsal hned nekolik voxelovych algoritmu , naposled jsem na distance field ray marchingu delal tak pred mesicem, ale kdyz rika ze je to narocne, tak to asi narocne je, nema cenu se prit ;-) ne fakt kouzlo minecraftu neni v technicke strance....
-
ostatne, jak je narocne udelat voxelovej engine se staci podivat treba na https://www.shadertoy.com/results?query=voxel
vcetne zdrojaku...
-
no, to nejsou. kod sice mozou mit celkem kosaty, ale z pohledu jazyku a jejich dospelosti pro realny svet jsou to naprosto nenarocne veci. cpu by nemely zrat vubec...vzdyt co delaji?
nejnarocnejsi operace je nejspis neco jako hledani v nejakem indexu, databazi. je rok 2016 a tohle fakt neni nic u ceho by se mel system zapotit.....
Nemohl byste vedle reálného světa vzít v úvahu také reálný letopočet? Rok 1970 už je poněkud passé a to, co vyřizuje požadavky uživatelů, opravdu nejsou jednovláknová CPU. Nejpočetnější skupina IT zařízení, se kterými uživatelé přímo pracují, dnes jsou nebo brzy budou mobilní zařízení (která se mimochodem neprogramují v C ani C++, ale v Javě nebo v ObjectiveC), další v pořadí je desktop (kde vedou Windows a tudíž C#).
Ukažte mi nějakou „spotřební“ aplikaci (kterou používají lidé jako používají ledničku, televizi nebo auto – kancelářský balík, internetový prohlížeč, hry, editory fotek, e-mailový klient, mapy), u které je pro uživatele podstatný výkon na CPU. Myslím, že nenajdete ani jednu. Pokud už to budou aplikace náročné na výkon, bude to buď výkon při paralelizaci, nebo výkon na GPU.
a co vlastne hledam....no zacnu ciste ze sveta v kterem se ja pohybuju tj. napriklad vizualizacni sw jako zbrush,maya,max...ruzne archviz, dynamics, finite elements, kapalinove simulace, treba nejaky vetsi cad....atd.
Tak hledejte, hledejte. Já už jsem vám sem odkazy dával.
proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku.
Zatím to vypadá, že je vám úplně jedno, zda je program užitečný pro uživatele, důležité pro vás je jenom to, zda vytěžuje CPU, GPU, paměť a IO. Naštěstí to tak nepojímají všichni, takže existují i užitečné programy napsané v C nebo C++.
klidne muzou byt ruzna data mining, expertni systemy, kompexnejsi databaze, deep learning, analyza reci, proste cokoli kde se hw zapoti tim,ze resi kompexni problemy, nejen ze resi samy sebe...
Příklady tu už opět padly. A v těchto oblastech se používá Java, Python, JavaScript případně další skriptovací a funkcionální jazyky. C je někde schované pro urychlení některých výpočetně náročných operací. To asi znamená to „dospělý programovací jazyk“ – že se mu každý vyhýbá a použije ho jedině tehdy, když není zbytí…
Mimochodem, pořád jste nenadefinoval, co je to ta „rychlost programovacího jazyka“, kterou se tady pořád tak oháníte. Někteří lidé píší šílený kód a obhajují to tím, že je to optimalizace – přitom nikdy nedokážou změřit to, v čem má být jejich kód údajně lepší, a dokonce ani nedokáží definovat, co by mělo být kritériem. Zdá se, že někteří to praktikují trošku jiným způsobem, a to tak, že píší v C.
Naštěstí máme spoustu různých jazyků a prostředí, a každý se hodí trochu na něco jiného. Vaše smůla je, že ke správnému výběru nestačí silná víra, že právě ten váš jazyk je ten „dospělý“, ale je potřeba umět nadefinovat kritéria, podle kterých budete hodnotit.
-
Co to meleš? On ti píše, že nic náročnějšího není a ty začneš zase nějaké nesmysly :D Technickou stránkou právě všechny porazil.
Ale prosímtě, minecraft v Javě je z hlediska výkonu dost tragédie, C++ verze je násobně rychlejší:
https://www.youtube.com/watch?v=dKgQwaKQ87Y
http://www.zdnet.com/article/minecrafts-new-education-edition-written-in-c-will-outrun-the-java-version/
Nějak nám ty super hyper hotspot runtime optimalizace moc nefungují, že?
Ahaaa a on je to úplně stejný MC, co? Vůbec tam nejsou rozdíly :D
... proste veci ktere dokazi zamestnat multi cpu,gpu,pamet,io a ktere je treba psat v dospelem jazyku. ale to je jen priklad, nemusi to byt z me branze,...
Ten Minecraft vam nevoni? Na CPU a myslim i na GPU jsou voxelove svety zatracene narocne (proto se to zacina prosazovat az ted, protoze na to pc zacinaji mit vykon). Na io - disk spise narazove, na sit, pokud putujete po svete rychle, tak to take neni zanedbatelne. Ale chapu, ze to zase smetete ze stolu, ze to neni "poradna dekstop aplikace", protoze pridate dalsi podminku :).
Ne, asi se nema cenu se s vami bavit, pusobite jako trochu sofistikovanejsi trol. Nejdrive oznacite IDE za male projekty, ktere nic nedelaji. Kdyz vam predhodim fakta, ktera rikaji opak, tak si to zase okecate, ze najednou je potreba realtime. Kolikata podminka to uz je? Desktop aplikace, ktera je narocna na io, pamet, cpu, gpu, prikon, rozliseni, fps, spojeni se satelitem, zabudovanym ovladanim vodotrysku a spustite ji jen na desktopu s hw za dva miliony $?
Minecraft je jiste zajimava volba.....nicmene Minecraft prorazil nikoli technickou strankou ale napadem (ostatni vizualni kvalita je zcela zamerne retro oldskulova az indie :-)
Co to meleš? On ti píše, že nic náročnějšího není a ty začneš zase nějaké nesmysly :D Technickou stránkou právě všechny porazil.
no nevim, hry me zivily 8 let (AAA), voxelove enginy jsou soucasti demo sceny konce 20 stoleti, osobne jsem napsal hned nekolik voxelovych algoritmu , naposled jsem na distance field ray marchingu delal tak pred mesicem, ale kdyz rika ze je to narocne, tak to asi narocne je, nema cenu se prit ;-) ne fakt kouzlo minecraftu neni v technicke strance....
Tak jsi tam třeba jen uklízel. MC má věci, které jinde nejsou a asi to nebude náhoda.
Nemám čas na ta videa, ale první, které jsem měl, nemělo kolize, AI, pohybující se věci, interakci mezi tím, fyziku pro to atd.
-
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?
-
jirsak:
ufff, takze telegraficky
1) ad mobile world....jako celek me nezajima, ale jen jako edukovany uzivatel mam dojem ze je snaha se brime javy v jeji ciste podobe zbavit....aspon z meho pohledu, tj pohledu grafickeho programatora (viz vsechny aktivity kolem daydream pro vr, tam se cesta closer to metal nabizi....
2)ty nektere odkazy vypadaji zajimave, prispevek jsem puvodne prehledl, vesmes to ale nejsou veci o kterych by google nabidl relevantni odkazy, neda se takto posoudit kvalita. zvlast u tech military projektu, muzou to byt uzasne veci a tako to muzou byt grantove sracky. ale jo, snad teda nejake funkcni veci mame...
3) ano je mi jedno jestli veci maji sve uzivatele, protoze tema nejsou user-aware aplikace :-)
4) viz bod 2. ze sve praxe mam dojem ze java, python atd se pouziji na rychly prototyp. kdyz se ozvedci tak se to pise znovu a poradne....zkusenosti tu ale muzou byt jine....nevnucuju ty me....
5)neohanim se benchmarky ty resi jina skupina. ptam se na celkova reseni. robustni velka reseni ALE zamerena na vykon, kde proste efektivni kod po vsech strankach udela rozdil
-
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.
-
javaman:
ano uklizel jsem tam, nicmene mana uklizela na opbh a ta si neni vedoma, ze by minecraft byl ocenovan za technickou realizaci. naopak, protoze je psan horkou jehlou a proto existuje spousta vice ci mene vaznych projektu jeho casti prepsat. ja ho ale uznavam, za chytre napady. jenze ty nemaji nic spolecneho s zadnym jazykem. btw minecraft ai? nepletes si to spis s ruznymi ai projekty, ktere svou funkcnost testuji v prostredi minecraftu? viz https://www.google.cz/search?q=minecraft+ai
-
http://stackoverflow.com/research/developer-survey-2016
co takto sa pozriet na 56k programatorov? :) v com codia, co je teraz trend, v ktorych odvetviach je java dominantna, v ktorych c++?
-
Ahaaa a on je to úplně stejný MC, co? Vůbec tam nejsou rozdíly :D
Ano, rozdíly jsou tam pomětně velké, v C++ je Minecraft výrazně rychlejší ;). Jinak budoucnost Minecraftu je celkem jasná, Microsoft Java verzi zařízne a nebude dál vyvíjet. Nemá cenu zabývat se Javou, která je pomalá a má problémy s portabilitou (neběží na XBOXu, PS4, iPhonu...). C++ běží všude a rychleji než Java.
-
ad mobile world....jako celek me nezajima
Jenže tady nediskutujeme o tom, co vás zajímá nebo nezajímá, ale o tom, jak je to v reálném světě.
mam dojem ze je snaha se brime javy v jeji ciste podobe zbavit
To je opravdu jen ničím nepodložený dojem.
ptam se na celkova reseni. robustni velka reseni ALE zamerena na vykon, kde proste efektivni kod po vsech strankach udela rozdil
Pak to hledání máte docela snadné, protože robustní velká řešení se dnes dělají prakticky jen v cloudu. Takže nemusíte hledat aplikace (které často nenajdete, protože jsou privátní), ale stačí hledat poskytovatele. Podívejte se na Google, Amazon, Microsoft Azure, podívejte se na ekosystém, který kolem toho existuje. Efektivita se v těchto případech řeší tak, aby to dobře běželo v cloudu a v druhém kole aby se používaly efektivní algoritmy. Pokud by se něco přepisovalo do jiného jazyka, bude častějším důvodem udržovatelnost kódu než výkonnost kódu na CPU. Výkon na CPU se řeší jen velmi okrajově, protože získaný výkon je velmi malý a obvykle jej mnohem levněji získáte prostě nákupem většího výkonu v cloudu. Navíc se tím podstatně zhorší udržovatelnost kódu (najednou tam máte další jazyk, musíte třeba řešit překlad pro různé platformy) a hlavně tím přicházíte o spoustu možností cloudu (třeba na Google Engine nativní kód nenasadíte).
Programování blízko hardwaru má samozřejmě pořád význam, třeba ta cloudová řešení ho potřebují pro jádro OS a pro virtualizační prostředí. Ale nejsou to ta velká řešení, je to jenom jedna komponenta, kterou ta velká řešení používají.
-
Ale prosímtě, minecraft v Javě je z hlediska výkonu dost tragédie, C++ verze je násobně rychlejší:
Nějak nám ty super hyper hotspot runtime optimalizace moc nefungují, že?
Aniž bych se chtěl vlamovat do dobře rozjetého flamu, tak tohle nelze srovnávat, protože:
MC v roce 2010 byl úplně jiný než MC dnes. Vyvíjel se. Dnes už se ví, co je potřeba a co není a jak by to mělo být a jak by to nemělo být. Pokud někdo přijde k hotovému a jen to přepíše (do libovolného jazyka), tak to bude výkonnější, protože ví, do čeho jde a může si to navrhnout lépe. První dema MC (se ještě ani nejmenoval MC) měla s dnešním MC společného tak akorát voxelovost. Toť vše.
Ovšem hlavním hybatelem v popularitě MC byla odpočátku možnost téměř neomezené modovatelnosti. Dodnes nemá mod API a je to dobře. I bez mod api už od alpha verzí MC vznikaly skvělé mody jen díky tomu, že je možné v jaru nahradit jednu třídu jinou, na libovolné místo dát hooky a zpětná volání apod. Tedy tím mod api byl samotný jar.
Tohle nelze v C++ dosáhnout. Zdrojové kódy nejsou dostupné, dodává se pouze hotový zkompilovaný program. A zatímco mod v javě napíše každý druhý hráč, tak injektovat nějaký vlastní kód do paměťového prostoru hry nebude dělat skoro nikdo. Oficiální mod api (až ho MS vydá) příliš nepomůže, protože bude dovolovat pouze to, co povolí tvůrci.
Takže díky za MC v Javě, nebýt tohoto, tak po něm dneska ani pes neštěkne a MS nekoupí Mojang.
-
Souhlas, děti zajímají jen různé mody, čisté MC je po nějaké době omrzí. Kvalita modů je věc jiná, ale existují a je jich mraky.
-
Souhlas, děti zajímají jen různé mody, čisté MC je po nějaké době omrzí. Kvalita modů je věc jiná, ale existují a je jich mraky.
Mody hlavne fragmentuju hracsku komunitu.
-
ad mobile world....jako celek me nezajima
Jenže tady nediskutujeme o tom, co vás zajímá nebo nezajímá, ale o tom, jak je to v reálném světě.
mam dojem ze je snaha se brime javy v jeji ciste podobe zbavit
To je opravdu jen ničím nepodložený dojem.
ptam se na celkova reseni. robustni velka reseni ALE zamerena na vykon, kde proste efektivni kod po vsech strankach udela rozdil
Pak to hledání máte docela snadné, protože robustní velká řešení se dnes dělají prakticky jen v cloudu. Takže nemusíte hledat aplikace (které často nenajdete, protože jsou privátní), ale stačí hledat poskytovatele. Podívejte se na Google, Amazon, Microsoft Azure, podívejte se na ekosystém, který kolem toho existuje. Efektivita se v těchto případech řeší tak, aby to dobře běželo v cloudu a v druhém kole aby se používaly efektivní algoritmy. Pokud by se něco přepisovalo do jiného jazyka, bude častějším důvodem udržovatelnost kódu než výkonnost kódu na CPU. Výkon na CPU se řeší jen velmi okrajově, protože získaný výkon je velmi malý a obvykle jej mnohem levněji získáte prostě nákupem většího výkonu v cloudu. Navíc se tím podstatně zhorší udržovatelnost kódu (najednou tam máte další jazyk, musíte třeba řešit překlad pro různé platformy) a hlavně tím přicházíte o spoustu možností cloudu (třeba na Google Engine nativní kód nenasadíte).
Programování blízko hardwaru má samozřejmě pořád význam, třeba ta cloudová řešení ho potřebují pro jádro OS a pro virtualizační prostředí. Ale nejsou to ta velká řešení, je to jenom jedna komponenta, kterou ta velká řešení používají.
1) ze me nezajima,to znamena ze tam nehodlam argumentovat. podle me mobile app hype uz mame za sebou, sousta firem zjistila ze tam jen par vyvolenych dokaze prodavat za velke penize, zbytek zivori na reklamach. ale budiz
2) daydream
3) it is not cloud, it is only somebody else's computer. ale jo,z javy se da vzdy zdtrhnout k webu a cloudu, je to pohodlene utociste ;-)
-
Souhlas, děti zajímají jen různé mody, čisté MC je po nějaké době omrzí. Kvalita modů je věc jiná, ale existují a je jich mraky.
Mody hlavne fragmentuju hracsku komunitu.
To s tím rozšířením souvisí. Čistý MC mi přijde ztráta času, když už hraji, tak blbnu s ComputerCraftem a redstonem (= rozuměj stavění autonomních vlakových tratí).
-
Tohle nelze v C++ dosáhnout. Zdrojové kódy nejsou dostupné, dodává se pouze hotový zkompilovaný program.
No ja ti nevim, Factorio je v C++ a modding scena je celkem aktivni. Ditto pro Skyrim. Ano, pocitali s tim (maji oficialni API), ale rozhodne to neni tak, ze kdyby Mojang nechtel, tak to nejde.
-
Tohle nelze v C++ dosáhnout. Zdrojové kódy nejsou dostupné, dodává se pouze hotový zkompilovaný program.
No ja ti nevim, Factorio je v C++ a modding scena je celkem aktivni. Ditto pro Skyrim. Ano, pocitali s tim (maji oficialni API), ale rozhodne to neni tak, ze kdyby Mojang nechtel, tak to nejde.
To není ani tak o tom, že by to nešlo, ale o tom, že by šlo pouze to, co by Mojang povolil. Změnu textur, změnu mapy, to půjde vždy - to je prostě změna datových souborů. Ale nějaké důkladnější změny (já hraju zejména technické packy), které z toho dělají de facto úplně novou hru (na stejném jevišti), tak to si nejsem jist, zda by tady bylo, kdyby existovalo nějaké officiální api. Možná jo, možná by jej vyvíjeli společně s modařema a nakonec by to api umožňovalo vše, co se teď dělá změnou class souborů - akorát lépe dokumentovaně.
To je taky vidět i na tom Skyrimu. Mění se hlavně textury a modely. (Dneska už bych vanilla skyrim nehrál; zkoušel jsem Special Edition, jako je to pěkný, ale stejně jsem si hned nahrál nějaké mody z nexusu - zejména textury a modely postav). Na nějaký mód, který by kompletně měnil skyrim na něco jiného jsem nenarazil. A třeba takový SKSE potřebuje injektovat do paměti hry. To už přes jeho api udělat nelze.
Factorio jsem zatím nehrál.
-
Drtiva vetsina games vypada tak, ze mas nejakou binarku, kera vlastne nic nedela a pak mas hromadu textur, dat ... a ... voiala ... scriptu. Mno a kdyz zmenis ty scripty, muzes (v ramci moznosti) napsat klidne uplne jinou hru.
Ta binarka prevazne slouzi jen jako loader a spoustec prave tech scriptu. A tady zalezi samo dost na tom, jak moc obecnej ten spoustec je, ale pokud dost, tak muzes defakto cokoli.
Dalsi vec je samo pripadna podpora modovani ze strany hry, ta ti muze hazet klacky pod nohy nebo te naopak podporit, treba tim, ze dostanes editor, takze nemusis resit jak data z nejakyho komprimovance vymlatis, jak je dostanes zpet ...
-
Rekl bych ze java bude o neco malo pomalejsi nez C/C++, nemyslim ze tohle je problem dneska kdyz mame k dispozici vykonne CPU, mnohem vetsi problem je velka spotreba pameti programu napsanych v JAVE.
Kazdopadne nejlepsi argument, lepsi nez nejake benchmarky je tento:
Kdyz se podivam na svuj desktop a v nem nejpouzivanejsou programy ktere ja pouzivam, napr: Chrome, Internet Explorer, Outlook, Excel, Word, Notepad++, uTorrent, Oracle, PostgreSQL, SAP Gui. Tak zadny z nich neni napsan v te uzasne JAVE (uzasne zkurvene pomale a nenazrane) , Proc? Kdyz je tak rychla a uzasne rychle se v ni vyviji?
-
Kdyz se podivam na svuj desktop a v nem nejpouzivanejsou programy ktere ja pouzivam, napr: Chrome, Internet Explorer, Outlook, Excel, Word, Notepad++, uTorrent, Oracle, PostgreSQL, SAP Gui. Tak zadny z nich neni napsan v te uzasne JAVE (uzasne zkurvene pomale a nenazrane) , Proc? Kdyz je tak rychla a uzasne rychle se v ni vyviji?
Podle seznamu to vypadá na desktop Windows, u kterého by bylo na místě spíš srovnání C# vs. C++
-
Kdyz se podivam na svuj desktop a v nem nejpouzivanejsou programy ktere ja pouzivam, napr: Chrome, Internet Explorer, Outlook, Excel, Word, Notepad++, uTorrent, Oracle, PostgreSQL, SAP Gui. Tak zadny z nich neni napsan v te uzasne JAVE (uzasne zkurvene pomale a nenazrane) , Proc? Kdyz je tak rychla a uzasne rychle se v ni vyviji?
Podle seznamu to vypadá na desktop Windows, u kterého by bylo na místě spíš srovnání C# vs. C++
Mas pravdu, ale C# je na tom uplne stejne tragicky, ani jeden z tech vyjmenovanych programu neni napsan v C#. Coz je paradoxni jelikoz Microsoft protlacuje .NET uz peknych par let ale jeho nejpouzivanejsi programy v nem napsane nejsou.
-
Rekl bych ze java bude o neco malo pomalejsi nez C/C++, nemyslim ze tohle je problem dneska kdyz mame k dispozici vykonne CPU, mnohem vetsi problem je velka spotreba pameti programu napsanych v JAVE.
Kazdopadne nejlepsi argument, lepsi nez nejake benchmarky je tento:
Kdyz se podivam na svuj desktop a v nem nejpouzivanejsou programy ktere ja pouzivam, napr: Chrome, Internet Explorer, Outlook, Excel, Word, Notepad++, uTorrent, Oracle, PostgreSQL, SAP Gui. Tak zadny z nich neni napsan v te uzasne JAVE (uzasne zkurvene pomale a nenazrane) , Proc? Kdyz je tak rychla a uzasne rychle se v ni vyviji?
Většina toho zmíněného sw je starší než Java - některé z těchto aplikací mohou pracovat s dost složitými datovými strukturami - a pak není nad C nebo C++.