Oh, bože ... -> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html. Samozřejmě že se používá, je to nejpoužívanější jazyk kterej umí každej manták.
Hej, to si beru osobně, jako Lael opravdu nejsem ... já, narozdíl od něj, mám pravdu. Java sama je důkaz mého tvrzení.
Ahoj :-),
začala jsem se učit Javu, ale slyšela jsem(místní blog), že se již nepoužívá. Je to pravda????
Děkuji ;)
Fráze "být za zenitem" znamená, že má nejlepší za sebou
onehda jsem se tady ve foru ptal na nejakou vlajkovou lod javy,ukazkovou aplikaci ze to v jave jde a dostal jsem jsem velmi rozpacite odpovedi:-)
Ahoj :-),java sa samozrejme pouziva, je to dlhodobo v top 3 najpouzivanejsich, jazykov. na desktope mozno nie (tam mozno vidiet akurat vyvojove prostredia v nej napisane), ale na serveri urcite, a to nehovorim o androide, kde je primarny jazyk.
začala jsem se učit Javu, ale slyšela jsem(místní blog), že se již nepoužívá. Je to pravda????
Děkuji ;)
Ahoj :-),
začala jsem se učit Javu, ale slyšela jsem(místní blog), že se již nepoužívá. Je to pravda????
Děkuji ;)
Citaceonehda jsem se tady ve foru ptal na nejakou vlajkovou lod javy,ukazkovou aplikaci ze to v jave jde a dostal jsem jsem velmi rozpacite odpovedi:-)
Napadá mě například netbeans.
Java sa pouziva, ale na backendoch. Za zenitom urcite nie je, lebo .net bezi iba na windows a node.js je pre enterprise prilis velke riziko, aj ked si na tom fici paypal. Uz len portovat vsetky tie db ovladace, adaptery a ja neviem co stoji zbytocne velke prachy. Taky twitter presiel na javu kvoli vykonu. Dnes je moderne asynchronne programovanie a tam ma java napr. oproti .netu medzery, ale inak zvlada vsetko co treba. Pravdupovediac keby bezal .net pod linuxom (mono nema vykon), tak asi prejdem nan.
Java sa pouziva, ale na backendoch. Za zenitom urcite nie je, lebo .net bezi iba na windows a node.js je pre enterprise prilis velke riziko, aj ked si na tom fici paypal. Uz len portovat vsetky tie db ovladace, adaptery a ja neviem co stoji zbytocne velke prachy. Taky twitter presiel na javu kvoli vykonu. Dnes je moderne asynchronne programovanie a tam ma java napr. oproti .netu medzery, ale inak zvlada vsetko co treba. Pravdupovediac keby bezal .net pod linuxom (mono nema vykon), tak asi prejdem nan.
Hmm, Python? Ruby? Java je ale fajn, bez problémů stihnete uvařit i vypít kafe, než se spustí Tomcat :-)Tomcat ale není Java. Také existují i jiné servlet kontejnery. Jak dlouho startuje třeba takový IIS?
Má praktická zkušenost je, že Mono je serveru s ARM 4x rychlejší než Java a v podstatě se rychlostí blíží nativní aplikaci.Z kolika srovnatelných aplikací tato zkušenost vychází?
Pred 10 rokmi?
A pokud ti to nevyhovuje tak si napis vlastni jazykskvely napad, nieco podobne robili aj ostatni:
Ahoj :-),Takto položená otázka vylučuje touhu nechat se vést vlastní hlavou ...
začala jsem se učit Javu, ale slyšela jsem(místní blog), že se již nepoužívá. Je to pravda?
Děkuji
a má tendenci nezvládnout management paměti bez GC ...
Přesně, ti kdož si alokují/dealokují paměť ručně jsou 1.25x větší drsňáci a otrocké psaní řádků kódu navíc vydávají za ctnost.CitaceAhoj :-),Takto položená otázka vylučuje touhu nechat se vést vlastní hlavou ...
začala jsem se učit Javu, ale slyšela jsem(místní blog), že se již nepoužívá. Je to pravda?
Děkuji
Začít s Javou je podle mne chyba, pokud bude někdy chtít přejít na jiný (-> efektivnější) jazyk (ať už z důvodu zájmu a nebo práce), bude to mít zbytečně těžké. Průměrný Javista je zlenivělí (takto to stačí říci abych nikoho neurazil) a má tendenci nezvládnout management paměti bez GC ...
btw. vysla ted java 8, zatim to na rootu moc velkou pozornost nemelo (melo by mit).
Začít s Javou je podle mne chyba, pokud bude někdy chtít přejít na jiný (-> efektivnější) jazyk (ať už z důvodu zájmu a nebo práce), bude to mít zbytečně těžké. Průměrný Javista je zlenivělí (takto to stačí říci abych nikoho neurazil) a má tendenci nezvládnout management paměti bez GC ...Kdyby jenom management paměti bez GC. Dokonce ani neumí používat pro ukládání dat páskovou mechaniku, a dokonce ani neumí pracovat s děrovačkou štítků!
Ahoj :-),java sa samozrejme pouziva, je to dlhodobo v top 3 najpouzivanejsich, jazykov. na desktope mozno nie (tam mozno vidiet akurat vyvojove prostredia v nej napisane), ale na serveri urcite, a to nehovorim o androide, kde je primarny jazyk.
začala jsem se učit Javu, ale slyšela jsem(místní blog), že se již nepoužívá. Je to pravda????
Děkuji ;)
minuly tyzden dokonca vysla vyznamna verzia Java 8, takze pouzivat sa rozhodne bude.
za tri roky vyslo pat novych verzii netbeansu + popracovalo sa aj na c/c++ integracii
samotny tomcat startne expresne rychlo, dlho trva redeployment celej aplikacie (30 sekund typicka doba pre velku aplikaciu). rozumni ludia pouzivaju class reloading zabudovany v jvm. ak vas limituju jeho obmedzenia, kupte si jrebel, tam mate deploymenty lusknutim prstu.
nehovoriac o tom, ze na mensie projekty pre lokalny vyvoj staci jetty a samozrejme posledne tomcaty (7,8) sa urychlili tiez
a má tendenci nezvládnout management paměti bez GC ...To je divný, co? :D Třeba ho totiž něco takového vůbec nezajímá. Mělo by?
Je to fakt sranda, stačí říct že Java není úžasná, že má i chyby a na člověka se vrhne hejno zažraných Javistů jež chrání svou modlu, protože kdyby jí nebylo, neměli by práci.a má tendenci nezvládnout management paměti bez GC ...To je divný, co? :D Třeba ho totiž něco takového vůbec nezajímá. Mělo by?
Mělo by, programy bez GC jsou zhruba o 100% rychlejší než ty s GC. To, že bez GC není programátor schopen pracovat ukazuje na jeho neschopnost, nikoli to že je moderní a de s dobou.
Mělo by, programy bez GC jsou zhruba o 100% rychlejší než ty s GC. To, že bez GC není programátor schopen pracovat ukazuje na jeho neschopnost, nikoli to že je moderní a de s dobou.A taky jsou programy bez GC zhruba o 200 % oranžovější. Když jste takový odborník a vyjadřujete to rovnou v procentech, jak jsou na tomdalší způsoby správy paměti - o kolik procent jsou programy bez nich rychlejší?
Je to fakt sranda, stačí říct že Java není úžasná, že má i chyby a na člověka se vrhne hejno zažraných Javistů jež chrání svou modlu, protože kdyby jí nebylo, neměli by práci.To špatně chápete. Problém není v tom, že byste říkal, že Java není úžasná. Problém je v tom, že plácáte nesmysly a ani se nepokoušíte předstírat, že byste je chtěl něčím doložit.
Je to fakt sranda, stačí říct že Java není úžasná, že má i chyby a na člověka se vrhne hejno zažraných Javistů jež chrání svou modlu, protože kdyby jí nebylo, neměli by práci.
Mě se třeba líbí NetBeans, ale pokud píšete a ta písmena se vám tak nějak na obrazovce objevují se zpožděním, je to takové trochu líné a pak si vyberete libovolné IDE napsané v C++, tak vidíte ten rozdíl v interakciKterá jsou ta IDE napsaná v C++, která umí aspoň to samé, co NetBeans?
Nejdůležitější je rychlost běhu programu, a ta je u Javy prostě mizerná no ... smiřte se s tímTo první je nesmysl. To že neumíte programovat a vaše programy jsou pomalé už víme, nemusíte to opakovat pořád dokola a snažit se z toho dělat všeobecné závěry.
To první je nesmysl. To že neumíte programovat a vaše programy jsou pomalé už víme, nemusíte to opakovat pořád dokola a snažit se z toho dělat všeobecné závěry.Dokaž to.
Dokaž to.No vida, takže jste zaznamenal, že bývá zvykem tvrzení dokazovat. Tak až po vás, těch nedokázaných tvrzení se vám nakupila pěkná spousta.
Nejdůležitější je rychlost běhu programu, a ta je u Javy prostě mizerná no ... smiřte se s tím
Já jsem za posledních 25 let prošel od 8-bitů až po současnost všemi assemblery pro všechny možné procesory, FigForthem, pak C, pak Pascalem, pak C++, pak Delphi s ObjectPascalem, PHP, JavaScriptem, HTML/CSS. Jediné, co jsem se učil a nebavilo mě to a řekl jsem si, že to prostě nemá cenu, protože se mi to nelíbí, byla Java. Byla zadarmo, ale radši jsem si koupil C++ nebo Delphi za peníze. Všechno je třída, pořád píšu, jak sekretářka strašně dlouhé názvy proměnných oddělených tečkou. Nějaký opravdu high vizuální návrh taky nikde. Hlavně, že máme v Javě GC, pro blbce, co neumí odalokovat paměť. Za břicho se popadám, když mi na seminářích líčí, jak novou verzi kompilují v noci, pak ji testují a pak posílají zákazníkům. Projekt v Delphi o 1.000.000 řádků kompiluji řádově v sekundách. Skončila podpora C#, v budoucnosti skončí i Java a všechny interprety kromě HTML5, protože budou žrát u zařízení baterku víc než čistý strojový kód. Mě se třeba líbí NetBeans, ale pokud píšete a ta písmena se vám tak nějak na obrazovce objevují se zpožděním, je to takové trochu líné a pak si vyberete libovolné IDE napsané v C++, tak vidíte ten rozdíl v interakci, prostě člověk, který dělá v IDE napsané v Javě a v prostředí napsaném v kompilátoru, vidí ten rozdíl. Pokud je někdo student a nemá peníze, tak ať programuje v Javě. Pokud někdo peníze má a živí ho to, tak ať si koupí profesionální prostředí RAD za cca 100.000 Kč. Rozdíl je velký, nicméně je dobře, aby se každý snažil s tím co má, každý podle svých možností.
Java je poražena v jakémkoli rychlostním testu. Zde http://developers-beta.slashdot.org/story/11/06/15/0242237/c-the-clear-winner-in-googles-language-performance-tests je důkaz. Teď ty.Na té odkazované stránce není nic o tom, že je Java poražena v jakémkoli rychlostním testu. Jinak kdybyste si v té sousední diskusi přečetl ty dvě stránky, kterým se pořád nějak vyhýbáte, dozvěděl byste se příklad toho, na čem rychlost programu opravdu záleží.
Nechápu k čemu je zkušenému programátorovi garbage collector. V každé serióznější aplikaci se stejně musí uvolňovat paměť (tedy odstraňovat reference). Přitom s GC nemůžete používat RAII, což mi přijde jako podstatná součást objektově orientovaného programování.
Měl bych další dotaz: neměl by být robustní, kvalitní a moderní jazyk kompilovaný do strojového kódu? Nějak nevidím výhody toho, aby byl jazyk podobného typu jako Java interpretovaný. Dnes už to má jen samé nevýhody.
Nechápu k čemu je zkušenému programátorovi garbage collector. V každé serióznější aplikaci se stejně musí uvolňovat paměť (tedy odstraňovat reference).GC nebo aspoň počitadla referencí jsou výhodné pro zkopírování pointeru na více míst, odkdu se budou odstraňovat v náhodném pořadí. GC prý je rychlejší než počitadla, i když mě to tak na našich serverech nepřijde. Po vypotřebování paměti Java na dlouho ztuhne.
Přitom s GC nemůžete používat RAII, což mi přijde jako podstatná součást objektově orientovaného programování.S tím 100% souhlasím. Největší opruz v Javě je "desktruktor" síťových a databázových connectionů v try..finally, které se někdy musí i opakovaně vnořovat. Je to podobná hrůza jako volání Release v COMu, pokud se nepoužijí smartpointery.
Měl bych další dotaz: neměl by být robustní, kvalitní a moderní jazyk kompilovaný do strojového kódu? Nějak nevidím výhody toho, aby byl jazyk podobného typu jako Java interpretovaný. Dnes už to má jen samé nevýhody.U Androidu jsem konečně pochopil k čemu to je. Těch procesorů v telefonech a tabletech je tolik, že asi není reálné pro každý to zkompilovat a otestovat u vývojáře. Na Linuxu je zase specifikum, že každá distribuce má jiné verze knihoven, takže nejuniverzálnější je kompilovat přímo na cílové distribuci. Tak to aspoň dělám na našich produkčních serverech.
IMHO hlavni vyhoda javy je v tom, ze se snadno ladi a hromadu chujovin uz nepusti prekladac. Je nejakej jinej jazyk, kde 90% chyb uz najde prekladac?Tak v odchytávání chyb při překladu IMO vede Haskell. Jeho typovému systému se vyrovná máloco. A taky jsem na tomhle jazyce zjistil, že GC spolu s referenční transparencí tvoří dost ultimátní kombinaci. Jen je to jazyk dost netradiční z pohledu běžných programátorů, takže naučit se ho je trochu těžší.
IMHO hlavni vyhoda javy je v tom, ze se snadno ladi a hromadu chujovin uz nepusti prekladac. Je nejakej jinej jazyk, kde 90% chyb uz najde prekladac?Tak v odchytávání chyb při překladu IMO vede Haskell. Jeho typovému systému se vyrovná máloco. A taky jsem na tomhle jazyce zjistil, že GC spolu s referenční transparencí tvoří dost ultimátní kombinaci. Jen je to jazyk dost netradiční z pohledu běžných programátorů, takže naučit se ho je trochu těžší.
Pokud se jedná o alternativu k NetBeans, tak si zkuste třeba C++Builder nebo Delphi, to jsou RAD prostředí s vizuálním návrhem, jinak další je třeba CodeBlocks.Mne zajímalo, s čím NetBeans srovnáváte ze stejné kategorie. C++ Builder nebo Delphi jsou sice také RAD nástroje, ale je to jiná liga. Je to jako srovnávat KOffice a OpenOffice. Obojí má své využití, ale je logické, že když jedno je spíš jednoúčelový nástroj a druhé komplexní systém, to druhé bude mít větší nároky.
Pokud se podívát například na TotalCommander, tak je napsaný buď v C++Builderu nebo v Delphi, proč to asi tak nepsali v Jave?Protože jeho autor dobře zná Delphi, tak to naprogramoval v Delphi. Na rozdíl od některých místních totiž asi věděl, že na volbě jazyka moc nezáleží, že mnohem podstatnější je, jak s tím jazykem a souvisejícími nástroji umí zacházet.
GUI aplikacie, co nemusia bezat na viacerych platformach, je zbytocne pisat v Jave.Pokud někdo umí Javu, je naopak velmi vhodné, aby to napsal v Javě, než aby to bastlil v něčem jiném.
Windows Vista měly mít nový souborový systém a další věci. Díky zdržení, pak neobsahovaly slibované věci.Chybějící WinFS nebyl důsledek zpoždění, naopak jeho špatný výkon byl jednou z příčin zpoždění.
GUI aplikacie, co nemusia bezat na viacerych platformach, je zbytocne pisat v Jave.Pokud někdo umí Javu, je naopak velmi vhodné, aby to napsal v Javě, než aby to bastlil v něčem jiném.
Prosím, neprogramuj.Nejdůležitější je rychlost běhu programu, a ta je u Javy prostě mizerná no ... smiřte se s tím
Co? Odkdy? To jsi trochu zaspal dobu.
To bude nádhera, jak krásně to zapadne do prostředí...Škoda, že to vůbec nesouvisí s programovacím jazykem. MS Word, Google Chrome, Mozilla Firefox, WinAmp - nic z toho není napsané v Javě, a přitom to používá jiné než nativní prostředí. Qt aplikace pod Gnome, GTK+ aplikace pod KDE také nezapadají do prostředí. vadí to někomu?
Jinak Jirsáku, důkaz už si dostal,Dostal, a ne jeden. Ale já jsem nechtěl další důkaz toho, že vůbec netušíte, o čem píšete. Já jsem chtěl důkaz některého z vašich tvrzení.
MS Word, Google Chrome, Mozilla Firefox, WinAmp - nic z toho není napsané v Javě, a přitom to používá jiné než nativní prostředí. Qt aplikace pod Gnome, GTK+ aplikace pod KDE také nezapadají do prostředí. vadí to někomu?
První Pentia (procesory od Intelu uvedené na trh začátkem devadesátých let) měla chybu v operacích s plovoucí řádovou čárkou. Tenkrát se vyprávěl tenhle vtip:Prosím, neprogramuj.Nejdůležitější je rychlost běhu programu, a ta je u Javy prostě mizerná no ... smiřte se s tím
Co? Odkdy? To jsi trochu zaspal dobu.
Akorát že nic z toho nevypadá jako posraná hajzlmísa na japonské skalce, narozdíl od "GUI" produktů napsaných v Javě. Naposled Javě v tomto ohledu konkuroval Motif ::)Aha, takže vy jste nikdy žádnou GUI aplikaci v Javě neviděl.
Já jsem za posledních 25 let prošel od 8-bitů až po současnost všemi assemblery pro všechny možné procesory, FigForthem, pak C, pak Pascalem, pak C++, pak Delphi s ObjectPascalem, PHP, JavaScriptem, HTML/CSS. Jediné, co jsem se učil a nebavilo mě to a řekl jsem si, že to prostě nemá cenu, protože se mi to nelíbí, byla Java. Byla zadarmo, ale radši jsem si koupil C++ nebo Delphi za peníze. Všechno je třída, pořád píšu, jak sekretářka strašně dlouhé názvy proměnných oddělených tečkou. Nějaký opravdu high vizuální návrh taky nikde. Hlavně, že máme v Javě GC, pro blbce, co neumí odalokovat paměť. Za břicho se popadám, když mi na seminářích líčí, jak novou verzi kompilují v noci, pak ji testují a pak posílají zákazníkům. Projekt v Delphi o 1.000.000 řádků kompiluji řádově v sekundách. Skončila podpora C#, v budoucnosti skončí i Java a všechny interprety kromě HTML5, protože budou žrát u zařízení baterku víc než čistý strojový kód. Mě se třeba líbí NetBeans, ale pokud píšete a ta písmena se vám tak nějak na obrazovce objevují se zpožděním, je to takové trochu líné a pak si vyberete libovolné IDE napsané v C++, tak vidíte ten rozdíl v interakci, prostě člověk, který dělá v IDE napsané v Javě a v prostředí napsaném v kompilátoru, vidí ten rozdíl. Pokud je někdo student a nemá peníze, tak ať programuje v Javě. Pokud někdo peníze má a živí ho to, tak ať si koupí profesionální prostředí RAD za cca 100.000 Kč. Rozdíl je velký, nicméně je dobře, aby se každý snažil s tím co má, každý podle svých možností.
Ja by som Scalu Groovy a Clojure hodil do jedneho vreca a nic by sa nestalo.
Jinak, vtip pěknej, ale ... netuším jak sem zapadá xDRAII, vy ste fakt epic level troll.
Já nejsem troll, troll se snaží ostatní vyprovokovat ale není osobně zainteresovaný v tom, za co bojuje. Já jsem a mým cílem není provokace, tím pádem nejsem troll.
Nejdůležitější je rychlost běhu programu, a ta je u Javy prostě mizerná no ... smiřte se s tímaj pri php webshope s nakupnym kosikom?
pokud si neakceptoval můj důkaz (dokonce vytvořen lidma z googlu, pokud se nemýlím)Jako důkaz, že netušíte, o čem píšete, jsem to akceptoval. Ale že by byla Java poražená v jakémkoli rychlostním testu, to ten dokument nijak nedokazuje.
Skusim nacat debatu trochu inym smerom ....Z těch čtyřech jazyků bych dnes doporučil především pátý - Javu 8. Je to zatím největší změna ve vývoji Javy, a bude nějakou dobu trvat, než se jí naučíte používat efektivně.
Ja uz Javu ako tak ovladam a zacinam pozerat na ine jazyky nad JVM. Co si o nich myslite? Najma o stvorici Scala, Ceylon, Groovy a Clojure.
vy vsetko robite v c/c++, lebo tam to pobezi najrychlejsie?"Niekto mi hovoril, nech sa pozriem na stranku http://example.com. Za 5 rokov som si v C naprogramoval http clienta a zobrazovaci toolkit; uz pracujem na jednoduchsom browseri. Bohuzial zda sa, ze ta stranka uz neexistuje. Ale zato mi to bezi naozaj rychlo :P."
Vyhoda Scaly je bezproblemova interoperabilita s Javou.
To bude nádhera, jak krásně to zapadne do prostředí... ::) ;D
. Ale ta interoperabilita s Javou neni rozhodne "bezproblemova".to je pravda, akka ma nie nadarmo scala verziu a java verziu
ať furt nezapomínám na mlíko a na rohliky, tak než to naběhlo, tak mi zavřeli Čongové ve večerce a počítač to zpomalilo tak, že už mi nenaběhla ani kalkulačka!malware na windows xp je svina
To je opravdu hrozne, jak ta Java vypada na win7 vic nativne nez neco v C#
Aha, už tomu začínám rozumět. Vývojáři v Javě viděli Windows naposled v roce 95. ::)
RAII.Řekl FLV xDD hej frajere, ty si dobrej debil. Jinak, nepochybuji že Jirsák je pouze jeho nick, nikoli skutečné jméno. A k tomu uhrovitému debilovy ... beďary mám no, za klávesnicí furt sedím, to je taky důvod proč mám znalosti oproti ... třeba tobě nebo Jirsákovy -> takže ten debil nesedí. A taky se mne tady někdo ptal jestli vše dělám v C++, no vzhledem ke svému zaměření ano ... třeba takový eshop bych dělal v PHP (možná python) ... ale já nedělám eshopy
Poslys ty hrdino. Kdyz uz tu suverene polemizuje s "Jirsakem", nechces rict treba svoje jmeno ?
Co ses zac, nejakej uhrovitej debil co sedi vecne doma za klavesnici ?
Jesus, tyhle kreteny fakt miluju :/.
třeba takový eshop bych dělal v PHP (možná python)
Vadilo. Naštěstí to nemusím dělat takže si ušetřím nervy.třeba takový eshop bych dělal v PHP (možná python)
A to by ti nevadilo, že jsou pomalejší než C++ a snad i pomalejší než Java?
jak je na tom HHVM?třeba takový eshop bych dělal v PHP (možná python)
A to by ti nevadilo, že jsou pomalejší než C++ a snad i pomalejší než Java?
A taky se mne tady někdo ptal jestli vše dělám v C++, no vzhledem ke svému zaměření ano ... třeba takový eshop bych dělal v PHP (možná python) ... ale já nedělám eshopyja som sa pytal nielen na eshopy, ale aj ine programatorske prace: napriklad shellskriptujete tiez v c++?
Vývojáři v Javě viděli Windows naposled v roce 95.ehm, co je vasa referencna aplikacia moderneho windowsu, s ktorou to porovnavate? office?
. beďary mám no, za klávesnicí furt sedím, to je taky důvod proč mám znalosti oproti ... t... take konkretne napriklad? na akych typoch aplikacii pracujete?
A to by ti nevadilo, že jsou pomalejší než C++ a snad i pomalejší než Java?Vadilo.
Vyhoda Scaly je bezproblemova interoperabilita s Javou.
No nevim. Chvili jsem delal na projektu, kde byla pouzivana Java a Scala zaraz a teda nektery casti kodu vypadaly fakt hnusne (napr. pristup k objektu scaly z javy [ne instanci tridy] - object A { val a = 4 } je z Javy dostupny jako A$.MODULE$.a(), bordel s michanim stylu setteru a getteru, nutne prevody mezi kolekcemi [java list vs. scala list]). Co za workaroundy se muselo delat, aby to prekladac pochopil - napr. problemy u dedeni java trida->scala trida s traity, generikou a self typem->java; problemy s "raw type" - musel se napsat wrapper v jave aby s tim scala mohla pracovat; problematicke pouziti frameworku pro modifikaci bytekodu za behu...
Scala se mi hodne libi, doufam ze se prosadi. Ale ta interoperabilita s Javou neni rozhodne "bezproblemova".
Já vás Javisty fakt nepochopím, modlím se abych se setkával s minimem Javistů v budoucích letech, zkracujete mi život svou demencí.ak sa nechcete stretavat, najlepsie je, ked nebudete chodit do tejto temy.
A proč bych vám to měl říkat, známe se snad?Mohl byste nám to říci proto, abychom mohli pochopit, co se pokoušíte sdělit. Na jednu stranu se totiž tváříte jako zkušený programátor. Na druhou stranu nechápete jeden z elementárních základů výrokové logiky, totiž že tvrzení s velkým kvantifikátorem (všeobecné tvrzení, "pro všechna x platí y"), nelze dokázat příkladem jedné věci x, pro kterou platí y. Přitom už jste na tuhle vaši chybu byl upozorněn různými lidmi asi desetkrát. A vy přijdete po jedenácté, a zase přijdete s příkladem jedné věci, pro kterou vaše tvrzení platí. A strašně se divíte, že jej nikdo nechce akceptovat jako důkaz toho vašeho všeobecného tvrzení.
Čtení PDFek? A co je na tom špatného? Napřed všichni chtěj důkaz, prej že vlastní zkušenosti nejsou důkaz. A když ho dostanou, tvářej se kysele a odmítaj ho akceptovat.
hejtujete vsetko, co nie je c++, pricom nic ine ste nevideliJá mám dost silné pochybnosti i o znalostech toho C++. Když se ve vedlejší diskusi objevil velmi neefektivní kód na násobení matic, měl být RAII - podle toho, jak se tady snaží sám sebe prezentovat - kdo proti tomu kódu vystartuje, protože procesorová cache, a kód přepíše. RAII si toho kódu ale vůbec nevšímal, a místo něj to opravovali javisti.
Jaké jiné generální informace chcete probohauplne si postacim, ked mi poviete, ci ste robili v jave alebo ste nerobili a co si myslite o programovani v shellskripte. nechcem od vas kompletne cv, ani telefonne cislo.
Co takhle dát repete?vyborne a teraz ja:
vybral sem úlohu na aplikování teorie grafů z toho důvodu že se jedná o výpočetně složitou operaci která porovná dobře výkon jazyků.
Ňáké programování obchodu mne nezajímá, není to má parketa a jako test rychlosti to stojí za starou bačkoru.pokial ste dorobili VS, nejake sockety a vlakna v c++ musite vediet.
za mna +1vybral sem úlohu na aplikování teorie grafů z toho důvodu že se jedná o výpočetně složitou operaci která porovná dobře výkon jazyků.
No, až sem dáš C++ kód, já se klidně na tu Javovskou vezi kouknu.
vybral sem úlohu na aplikování teorie grafů z toho důvodu že se jedná o výpočetně složitou operaci která porovná dobře výkon jazyků.Celou dobu vám tu x lidí tvrdí, že výkon jazyků nezáleží jen na rychlosti výsledné aplikace. A že i rychlost výsledné aplikace je zvoleným jazykem ovlivněna jen málo, daleko větší dopad má třeba zvolený algoritmus.
deploynite mi REST server pre fiktivny obchod, nad HTTP, payloady nech idu JSONom. nech mam operaciu pre zoznam tovarov (id, nazov, pocet kusov na sklade). a nech mam operaciu pre nakup, ktora ma na vstupe id tovaru, a vysledkom je znizenie poctu kusov daneho tovaru na sklade o jedna
To je hezké zadání. Použijeme třeba Casablancu (pro http a json) a kód vlastní business logiky bude zhruba stejný jako v Javě nebo C#. Rychlost bude dána sítí. Jen memory footprint bude nižší. Ještě nějaký pokus?
Použijeme třeba Casablancu (pro http a json) a kód vlastní business logiky bude zhruba stejný jako v Javě nebo C#. Rychlost bude dána sítí.zdrojaky? :-)
deploynite mi REST server pre fiktivny obchod, nad HTTP, payloady nech idu JSONom. nech mam operaciu pre zoznam tovarov (id, nazov, pocet kusov na sklade). a nech mam operaciu pre nakup, ktora ma na vstupe id tovaru, a vysledkom je znizenie poctu kusov daneho tovaru na sklade o jednaTohle mi připomíná jeden hezký citát z knihy Programátorské poklesky o komunikaci programátorů:
To je hezké zadání. Použijeme třeba Casablancu (pro http a json) a kód vlastní business logiky bude zhruba stejný jako v Javě nebo C#. Rychlost bude dána sítí. Jen memory footprint bude nižší. Ještě nějaký pokus?
Jak by se řešil přístup do databáze? V Javě existuje například hibernate, v podstatě stačí pár anotací a o zbytek se postará sám.
deploynite mi REST server pre fiktivny obchod, nad HTTP, payloady nech idu JSONom. nech mam operaciu pre zoznam tovarov (id, nazov, pocet kusov na sklade). a nech mam operaciu pre nakup, ktora ma na vstupe id tovaru, a vysledkom je znizenie poctu kusov daneho tovaru na sklade o jednaTohle mi připomíná jeden hezký citát z knihy Programátorské poklesky o komunikaci programátorů:
„Ten sort s apdejtovanejma opšnama mi vypliv mraky vórningů, tak jsem džob po čekpointu típnul, Svičnul jsem se pod sysmana a zkolektoval júzrhuky, ale hodilo to systém eror.“
„Zkus dylítnout vérkfajly a vyendovat se. Pak to exekni z meku do malýho beče s trasováním na olejblovanou pásku a autput esajnuj na flopáč. Jestli to krešne, vylistuj žurnál s dampem, kilni spůlfajly a před odlogováním vytancuj modulovou. Oukej?“
Snažím se tím jen říct, že pro většinu lidí, kteří se tomu denně nevěnují, to bude španělská vesnice, ale nic to nedokazuje o vhodnosti použit Javy/C++/čehokoliv jiného.
Snažím se tím jen říct, že pro většinu lidí, kteří se tomu denně nevěnují, to bude španělská vesnice, ale nic to nedokazuje o vhodnosti použit Javy/C++/čehokoliv jiného.na to by sa dalo reagovat analogicky, ze kolko ludi denne programuje dijkstrove algoritmy
Ovšem zvolením lepší technologie by třeba pro stejnou aplikaci stačil méně výkonný server a hravě by ji zvládl, do toho už ovšem málokdo vidí. Až budeme mít použitelné chytré hodinky s SDK, opět se ukáže rozdíl mezi různými platformami.urcite, akurat mnohokrat sa to neoplati financne, alebo na to neexistuju v teame ludia, vdaka ktorym by sa oplatilo pouzit rychlejsie beziacu technologiu.
Já dělal roky v Javě, C++ a ObjC (snad jen v .NET méně) a ze zkušenosti vím, že rozdíly mezi platformami (=jazyk+knihovna) se projeví při použití na omezeném hardwaru (pomalý procesor a/nebo málo paměti), například první iPhony nebo v poslední době Raspberry Pi apod. Na serveru s osmijádrem a 32GB paměti se případná nevýhoda projeví jen u velké aplikace a dost nedeterministicky. Ovšem zvolením lepší technologie by třeba pro stejnou aplikaci stačil méně výkonný server a hravě by ji zvládl, do toho už ovšem málokdo vidí. Až budeme mít použitelné chytré hodinky s SDK, opět se ukáže rozdíl mezi různými platformami.
Já dělal roky v Javě, C++ a ObjC (snad jen v .NET méně) a ze zkušenosti vím, že rozdíly mezi platformami (=jazyk+knihovna) se projeví při použití na omezeném hardwaru (pomalý procesor a/nebo málo paměti), například první iPhony nebo v poslední době Raspberry Pi apod. Na serveru s osmijádrem a 32GB paměti se případná nevýhoda projeví jen u velké aplikace a dost nedeterministicky. Ovšem zvolením lepší technologie by třeba pro stejnou aplikaci stačil méně výkonný server a hravě by ji zvládl, do toho už ovšem málokdo vidí. Až budeme mít použitelné chytré hodinky s SDK, opět se ukáže rozdíl mezi různými platformami.
On je ale i rozdíl v rychlosti vývoje. Takový server s osmijádrem a 32GB paměti vyjde asi levněji než programátor navíc.
Já dělal roky v Javě, C++ a ObjC (snad jen v .NET méně) a ze zkušenosti vím, že rozdíly mezi platformami (=jazyk+knihovna) se projeví při použití na omezeném hardwaru (pomalý procesor a/nebo málo paměti), například první iPhony nebo v poslední době Raspberry Pi apod. Na serveru s osmijádrem a 32GB paměti se případná nevýhoda projeví jen u velké aplikace a dost nedeterministicky. Ovšem zvolením lepší technologie by třeba pro stejnou aplikaci stačil méně výkonný server a hravě by ji zvládl, do toho už ovšem málokdo vidí. Až budeme mít použitelné chytré hodinky s SDK, opět se ukáže rozdíl mezi různými platformami.
On je ale i rozdíl v rychlosti vývoje. Takový server s osmijádrem a 32GB paměti vyjde asi levněji než programátor navíc.
na to by sa dalo reagovat analogicky, ze kolko ludi denne programuje dijkstrove algoritmyProgramuje asi málo, ale používá docela dost (já ano :) ). Když potřebuju dijkstru, použiju třeba tohle:
A v čem přesně se ta rychlost vývoje liší (za předpokladu, že vždy použijeme dostupné knihovny pro rutinní záležitosti)?
Pak tu může být ještě otázka snadnoti použití těch knihoven. Je třeba v C++ něco (a tu otázku myslím vážně, ne jako chyták), co lze použít tak snadno jako RMI?
Dodatek: Jaký programátor navíc? Předpokládám, že nám jde o shodnou funkčnost.on myslel to, ze server stoji 2000 eur, a to je cena, za ktoru si zaplatite mesiac programatora
rmi kde to je jednodušší než v Javěv jave je to uz tiez easy (jeden interface, jedna implementacia, tusim styri riadky bootstrapu pre server), aj ked zhodou okolnosti soap server deploynete este rychlejsie :-)
CitaceDodatek: Jaký programátor navíc? Předpokládám, že nám jde o shodnou funkčnost.on myslel to, ze server stoji 2000 eur, a to je cena, za ktoru si zaplatite mesiac programatora
onu moju rest ulohu si v pythone nasadite asi na 10 riadkov
lebo nejde len o rychlost do dodania, ale aj udrzovatelnost, a hlavne to, ake schopnosti a znalosti ma vas team, a co sa stane, ked team nebude.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Pentium(R) CPU G860 @ 3.00GHz
stepping : 7
microcode : 0x29
cpu MHz : 1830.000
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 5986.36
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Pentium(R) CPU G860 @ 3.00GHz
stepping : 7
microcode : 0x29
cpu MHz : 1830.000
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 5986.36
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Tak tady je ten program: http://uloz.to/xbxoSz7K/shortestpath-zip.
/home/mrw/programovani/shortestPath/lemon/list_graph.h|26|fatal error: lemon/core.h: No such file or directory|ale jinak budme radi za javu... aspon to vsude okolo neni php vs. asp/.net.
Pokud potřebujete systém s garantovanou maximální latencí, nemůžete vzít běžný OS, ale musíte použít realtime OS. Úplně stejně nemůžete použít běžnou desktopovou Javu od Oracle, ale musíte použít realtime JVM. Stop-the-world na potenciálně neomezenou dobu totiž není principiální vlastnost GC, je to vlastnost pouze některých implementací.
Java na tom vlastně není vůbec špatně, když většina její kritiky pramení z neznalosti.
http://www.azulsystems.com/technology/c4-garbage-collector
Tak tady je ten program: http://uloz.to/xbxoSz7K/shortestpath-zip.
Rychlost běhu programu je od 1000 ms až do 1200 ms.
Java na tom vlastně není vůbec špatně, když většina její kritiky pramení z neznalosti.Kritika všeho pramení obvykle z neznalosti. Pak je problém, když je založená na znalostech a zkušenostech a naváží se do ní trotli...
import java.util.Random;
public class Dijkstra
{
public static int compute(final int count, int start, int stop, final int weight[])
{
boolean[] invalid = new boolean[count];
int distance[] = new int[count];
for(int i = 0; i < count; i++)
distance[i] = Integer.MAX_VALUE;
int u = start;
distance[u] = 0;
while(u != stop)
{
invalid[u] = true;
int minDistance = distance[u];
int min = Integer.MAX_VALUE;
for(int v = 0; v < count; v++)
{
if(invalid[v])
continue;
int distanceThroughU = minDistance + weight[u * count + v];
if(distanceThroughU < distance[v])
distance[v] = distanceThroughU;
if(distance[v] < min)
{
u = v;
min = distance[v];
}
}
}
return distance[u];
}
public static void main(String[] args)
{
long time = System.currentTimeMillis();
final int count = 5000;
final Random rand = new Random();
int weight[] = new int[count * count];
for(int i = 0; i < count * count; i++)
weight[i] = rand.nextInt(100) + 1;
int res = compute(count, 0, count - 1, weight);
time = System.currentTimeMillis() - time;
System.out.println("result: " + res);
System.out.println("time : " + time);
}
}
Pokud potřebujete systém s garantovanou maximální latencí, nemůžete vzít běžný OS, ale musíte použít realtime OS. Úplně stejně nemůžete použít běžnou desktopovou Javu od Oracle, ale musíte použít realtime JVM. Stop-the-world na potenciálně neomezenou dobu totiž není principiální vlastnost GC, je to vlastnost pouze některých implementací.
Java na tom vlastně není vůbec špatně, když většina její kritiky pramení z neznalosti.
Jakub Galgonek: RAII si těžce naběhl tím, že vygeneroval graf, který má velký počet hrah (V^2).
daleko větší dopad má třeba zvolený algoritmus.
RAII tím ale (asi nechtěně) ukázal jednu pěknou věc.RAII tady opakovaně ukazuje, jaké má mezery v chápání, proč něco běží pomalu. Přijde mi jako typ, který je schopný pilovat superefektivní bubblesort a dokonale přehlížet "nedůležité" věci jako je asymptotická složitost, nebo posloupnost přístupů do paměti.
#include <vector>
#include <limits>
#include <chrono>
#include <iostream>
#include <cstdlib>
const int INT_MAX = std::numeric_limits<int>::max();
int compute (int count, int start, int stop, const std::vector<int> &weight)
{
std::vector<bool> invalid(count, false);
std::vector<int> distance(count, INT_MAX);
int u = start;
distance[u] = 0;
while(u != stop) {
invalid[u] = true;
int minDistance = distance[u];
int min = INT_MAX;
for (int v = 0; v < count; ++v) {
if (invalid[v]) {
continue;
}
int distanceThroughU = minDistance + weight[u * count + v];
if (distanceThroughU < distance[v]) {
distance[v] = distanceThroughU;
}
if (distance[v] < min) {
u = v;
min = distance[v];
}
}
}
return distance[u];
}
int main(int argc, char **argv)
{
auto start = std::chrono::high_resolution_clock::now();
const int COUNT = 5000;
std::vector<int> weight(COUNT * COUNT);
srand(time(0));
for (int i = 0; i < COUNT * COUNT; ++i) {
weight[i] = (random() % 100) + 1;
}
int res = compute(COUNT, 0, COUNT - 1, weight);
auto end = std::chrono::high_resolution_clock::now();
int duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
std::cout << "result: " << res << std::endl;
std::cout << "time : " << duration << std::endl;
return 0;
}
Java verziu som spustal len prikazom time java Dijkstra
Poznámka pro majo33. Když použiješ release mód (při kompilování tvé C++ verze), dostaneš se na 330 ms. 380 ms máš s debug módem.
C++ verzia (dufam ze tam nemam chybu):Kód: [Vybrat]#include <vector>
#include <limits>
#include <chrono>
#include <iostream>
#include <cstdlib>
const int INT_MAX = std::numeric_limits<int>::max();
int compute (int count, int start, int stop, const std::vector<int> &weight)
{
std::vector<bool> invalid(count, false);
std::vector<int> distance(count, INT_MAX);
int u = start;
distance[u] = 0;
while(u != stop) {
invalid[u] = true;
int minDistance = distance[u];
int min = INT_MAX;
for (int v = 0; v < count; ++v) {
if (invalid[v]) {
continue;
}
int distanceThroughU = minDistance + weight[u * count + v];
if (distanceThroughU < distance[v]) {
distance[v] = distanceThroughU;
}
if (distance[v] < min) {
u = v;
min = distance[v];
}
}
}
return distance[u];
}
int main(int argc, char **argv)
{
auto start = std::chrono::high_resolution_clock::now();
const int COUNT = 5000;
std::vector<int> weight(COUNT * COUNT);
srand(time(0));
for (int i = 0; i < COUNT * COUNT; ++i) {
weight[i] = (random() % 100) + 1;
}
int res = compute(COUNT, 0, COUNT - 1, weight);
auto end = std::chrono::high_resolution_clock::now();
int duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
std::cout << "result: " << res << std::endl;
std::cout << "time : " << duration << std::endl;
return 0;
}
Casy (priemer 50 spusteni, prvy stlpec je vypis casu s programu, druhy s programu time):
Java : 479ms, real 561ms
G++ : 373ms, real 384ms
Clang: 362ms, real 376ms
Java verziu som spustal len prikazom time java Dijkstra, mozno by to poladil nejaky parameter?
C++ verzie su kompilovane prikazmi (medzi -O2 a -O3 nieje podstatny rozdiel):
g++ -std=c++11 -O2 Dijkstra.cpp -o Dijkstra_gcc
clang++ -std=c++11 -O2 Dijkstra.cpp -o Dijkstra_clang
este pre zboja a python rest
https://gist.github.com/anonymous/9933517
Jakou jsi použil Javu?
Mno, jak vidno, posral sem to. Poznámka pro majo33. Když použiješ release mód (při kompilování tvé C++ verze), dostaneš se na 330 ms. 380 ms máš s debug módem.
nepoužil ... s ním mi vyšel stejný (+-10) čas jako tam napsal (384) ... bez něj 330 ms
nepoužil ... s ním mi vyšel stejný (+-10) čas jako tam napsal (384) ... bez něj 330 msAno, pokud vezmeš kód a spustíš ho na jiném počítači, tak obvykle naměříš jiné časy. Překvapení :P
srand(time(0));
Neříkej, proč sem asi dal výpis z /proc/cpuinfo...Jedno jádro mého procesoru má frekvenci 3Ghz, jeho má zřejmě také...
Neříkej, proč sem asi dal výpis z /proc/cpuinfo...Jedno jádro mého procesoru má frekvenci 3Ghz, jeho má zřejmě také...Mohl bys přidat i výpis z /dev/crystal_ball ? Na základě čeho usuzuješ, že jeho procesor má 3Ghz? Z toho, co tu napsal nejsem schopný ani určit, jestli má Intel nebo AMD.
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Spustal som to na AMD Phenom x4 945 3GHz.
Spustal som to na AMD Phenom x4 945 3GHz.Trefil se :o
-O3 + release mód. Byl to pouze odhad ... a trefil jsem se jak vidím. I když, z části se divím, typoval sem Intel.
AMD jádra obvykle potřebují vyšší frekvenci aby se vyrovnali Intel jádrům ze stejné "třídy".
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
<FileVersion major="1" minor="6" />
<Project>
<Option title="shortestPath" />
<Option pch_mode="2" />
<Option compiler="gcc" />
<Build>
<Target title="Debug">
<Option output="bin/Debug/shortestPath" prefix_auto="1" extension_auto="1" />
<Option object_output="obj/Debug/" />
<Option type="1" />
<Option compiler="gcc" />
<Compiler>
<Add option="-g" />
</Compiler>
</Target>
<Target title="Release">
<Option output="bin/Release/shortestPath" prefix_auto="1" extension_auto="1" />
<Option object_output="obj/Release/" />
<Option type="1" />
<Option compiler="gcc" />
<Compiler>
<Add option="-O2" />
</Compiler>
<Linker>
<Add option="-s" />
</Linker>
</Target>
</Build>
<Compiler>
<Add option="-Wall" />
<Add option="-fexceptions" />
</Compiler>
<Unit filename="main.cpp" />
<Extensions>
<code_completion />
<debugger />
</Extensions>
</Project>
</CodeBlocks_project_file>Tento CBP file je vygenerován když mám nastaveny optimalizace -O3. Schválně si to zkus, a použij prosím stejnou verzi IDE, v novější může být bug opraven. [12.11-1.el18]
hlupáku ... aspoň si otestuj svoje tvrzení:
Tento CBP file je vygenerován když mám nastaveny optimalizace -O3. Schválně si to zkus, a použij prosím stejnou verzi IDE, v novější může být bug opraven. [12.11-1.el18]
Kód: [Vybrat]
for(int v = 0; v < count; v++)
{
int distanceThroughU = minDistance + weight[u * count + v];
if(distanceThroughU < distance[v])
distance[v] = distanceThroughU;
if(distance[v] < min)
{
u = v;
min = distance[v];
}
}
int nextU = u;
for(int v = 0; v < count; v++)
{
int distanceThroughU = minDistance + weight[u * count + v];
if(distanceThroughU < distance[v])
distance[v] = distanceThroughU;
if(distance[v] < min)
{
nextU = v;
min = distance[v];
}
}
u = nextU;
Podle mne je v tom kódu chyba. Původně jsem si říkal, že je to nějaká pekelná optimalizace. Ale dává to špatné výsledky, takže se i přes pozdní hodinu přikláním spíš k tomu, že je to chyba. u by mělo být v rámci for cyklu neměnné, protože se používá pro přístup do pole vah (weight[u * count + v]). Zároveň se ale mění v případě, kdy je nalezena kratší vzdálenost (u = v).
Původně jsem to chtěl tedy přepsat do paralelního zpracování, a to u mi tam pořád překáželo. Takhle už to snad půjde líp :-)
hlupáku ... aspoň si otestuj svoje tvrzení:
Da sa to este o malinko zrazit, pretoze vo for cykle sa po kazdej iteracii rata count * countKód: [Vybrat]import java.util.Random;
public class Dijkstra
{
public static int compute(final int count, int start, int stop, final int weight[])
{
boolean[] invalid = new boolean[count];
int distance[] = new int[count];
for(int i = 0; i < count; i++)
distance[i] = Integer.MAX_VALUE;
int u = start;
distance[u] = 0;
while(u != stop)
{
invalid[u] = true;
int minDistance = distance[u];
int min = Integer.MAX_VALUE;
for(int v = 0; v < count; v++)
{
if(invalid[v])
continue;
int distanceThroughU = minDistance + weight[u * count + v];
if(distanceThroughU < distance[v])
distance[v] = distanceThroughU;
if(distance[v] < min)
{
u = v;
min = distance[v];
}
}
}
return distance[u];
}
public static void main(String[] args)
{
long time = System.currentTimeMillis();
final int count = 5000;
final Random rand = new Random();
int weight[] = new int[count * count];
for(int i = 0; i < count * count; i++)
weight[i] = rand.nextInt(100) + 1;
int res = compute(count, 0, count - 1, weight);
time = System.currentTimeMillis() - time;
System.out.println("result: " + res);
System.out.println("time : " + time);
}
}
...
final int count = 5000;
final int countcount = 25000000;
final Random rand = new Random();
final int weight[] = new int[countcount];
for(int i = 0; i < countcount; i++)
weight[i] = rand.nextInt(100) + 1;
...
RAII: kriticke casti kodu sa daju volat cez JNI
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping : 7
cpu MHz : 2266.095
cache size : 6144 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up rep_good nopl pni monitor ssse3 lahf_lm
bogomips : 4532.19
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
hlupáku ... aspoň si otestuj svoje tvrzení:... nekdo tu psal neco o jave & GC & telefonich systemech ze nechce cekat na full gc - proboha co to je za argumenty? podivejte se v cem eriksoni psali firmware do jejich ustreden a jak tam pracuje GC a pak mozna proc to tak pouzili
hlupáku ... aspoň si otestuj svoje tvrzení:... nekdo tu psal neco o jave & GC & telefonich systemech ze nechce cekat na full gc - proboha co to je za argumenty? podivejte se v cem eriksoni psali firmware do jejich ustreden a jak tam pracuje GC a pak mozna proc to tak pouzili
ericsoni erlang se rozebiral kdysi v minulosti v obdobne nesmyslenm hate vlakne. rozuzleni bylo to, ze struktura navrhu a pouziti erlangu umoznuje pouzit primocarejsi techniky GC, ktere ani v C++ ani v Jave nebudou fungovat bez dodatecnych berli kvuli kterym budou fungovat hur nez ty soucasne pouzivane. erlang jde mimo me, ale jestli to je pravda, tak na to bude urcite nejmin jeden dokument s dostatecne dobrym pagerankem.
Da sa to este o malinko zrazit, pretoze vo for cykle sa po kazdej iteracii rata count * count
mne sa to po tej uprave java kodu zacykli :-)
import java.util.Random;
public class Dijkstra
{
public static int compute(final int count, int start, int stop, final int weight[])
{
boolean[] invalid = new boolean[count];
int distance[] = new int[count];
for(int i = 0; i < count; i++)
distance[i] = Integer.MAX_VALUE;
int u = start;
distance[u] = 0;
while(u != stop)
{
invalid[u] = true;
int minDistance = distance[u];
int min = Integer.MAX_VALUE;
int next = -1;
for(int v = 0; v < count; v++)
{
if(invalid[v])
continue;
int distanceThroughU = minDistance + weight[u * count + v];
if(distanceThroughU < distance[v])
distance[v] = distanceThroughU;
if(distance[v] < min)
{
next = v;
min = distance[v];
}
}
u = next;
}
return distance[u];
}
public static void main(String[] args)
{
long time = System.currentTimeMillis();
final int count = 5000;
final Random rand = new Random();
int weight[] = new int[count * count];
for(int i = 0; i < count * count; i++)
weight[i] = rand.nextInt(100) + 1;
int res = compute(count, 0, count - 1, weight);
time = System.currentTimeMillis() - time;
System.out.println("result: " + res);
System.out.println("time : " + time);
}
}
Da sa to este o malinko zrazit, pretoze vo for cykle sa po kazdej iteracii rata count * count
S tím by si měl optimalizátor snad poradit sám.