Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: kupca2 01. 10. 2016, 13:22:53
-
Ahojte, aky notebook by ste odporucili Java developerovi? Moje kriteria su asi len 16gb ram, vykonny procesor a 15" display ... celkom klasika u javistov je macbook no nemam s nim este skusenost (windowsak) ... moji dvaja hlavni kandidati su MacPro 15" a Dell xps 15
-
Na Javu to chce pořádný stroj, tak NB bude vždy slabý a budeš pořád na něco čekat. Taková spíš hračka. 4jádrová i7 ale bude dobrý kompromis, kdy alespoň něco půjde. Za tu cenu ale už můžeš mít normální i7 a nebo Xeon.
-
A 16 GB je samozřejmě k ničemu, to zaplníš hned. Jako nouzovka to je ale OK.
-
Ja mam macbook pro 15'' a je to vpohode.
-
Mám 2GB RAM a také v pohodě.
-
Především záleží, co budeš vyvíjet a jakým způsobem. Pokud budeš celý řetězec na tom stroji spouštět, pak kolik si to vezme paměti pro svižný běh. Čas je drahý, zatímco HW je skoro zadarmo.
-
Právě proto vyvíjím rychlé programy místo pomalých, které jsou dnes v módě.
-
Ahojte, aky notebook by ste odporucili Java developerovi? Moje kriteria su asi len 16gb ram, vykonny procesor a 15" display ... celkom klasika u javistov je macbook no nemam s nim este skusenost (windowsak) ... moji dvaja hlavni kandidati su MacPro 15" a Dell xps 15
MacBook, jak zmiňují jiní, je hodně dobrá volba, ale s koupí je dobré počkat aspoň měsíc, Apple v říjnu přestaví nové modely.
-
Právě proto vyvíjím rychlé programy místo pomalých, které jsou dnes v módě.
A v PHP :D Java je výkonem jinde než tenhle paskvil, ale zase se v ní tak rychle dělá, že i malé programy mají obrovskou funkcionalitu a nároky.
-
Právě proto vyvíjím rychlé programy místo pomalých, které jsou dnes v módě.
A v PHP :D Java je výkonem jinde než tenhle paskvil, ale zase se v ní tak rychle dělá, že i malé programy mají obrovskou funkcionalitu a nároky.
Nezapomeň, že knihovny PHP jsou napsány v C/C++, takže ve finálním výsledku jsou programy v PHP méně náročné na prostředky a výkonnější než v Javě.
-
Tak to možná ve snu. Nějaký důkaz by byl?
-
Tak to možná ve snu. Nějaký důkaz by byl?
K čemu by ti byl můj důkaz? Ignoroval bys ho.
Když jsem si udělal plugin v Javě, tak jeho běh trval kolem 550 ms. Když jsem totéž udělal v PHP, zvládlo to za 60 ms. Algoritmus prakticky totožný. Vzhledem k tomu, že jsem si nemohl dovolit víc než 300 ms, musel jsem to nechat v PHP.
-
Jako to děláváš ty? :D
Tak asi neumíš programovat. Ale to vlastně víme. Výkonem nemá PHP šanci, takže jsi asi něco dělal špatně. Ale vlastně to chápeme. Takže ten důkaz, prosím :D
A nebo nechceš k tomu pluginu něco více říct? Takhle to totiž vypadá, žej si úplně mimo jako obvykle a začínáš vymýšlet ty svoje nesmysly, které budeš postupně akorát "vylepšovat". Nakonec z toho vyleze něco úplně jiného.
-
Jako to děláváš ty? :D
Tak asi neumíš programovat. Ale to vlastně víme. Výkonem nemá PHP šanci, takže jsi asi něco dělal špatně. Ale vlastně to chápeme. Takže ten důkaz, prosím :D
A nebo nechceš k tomu pluginu něco více říct? Takhle to totiž vypadá, žej si úplně mimo jako obvykle a začínáš vymýšlet ty svoje nesmysly, které budeš postupně akorát "vylepšovat". Nakonec z toho vyleze něco úplně jiného.
I obyčejný Hello, World ti poběží v Javě alespoň půl sekundy. Než se natáhne JRE, tak to prostě trvá.
HTTP server v PHP mi zabírá jen 3 MB RAM. Tomu Java nemůže konkurovat.
-
Dyť to říkám. Nejdřív to vypadá jako normální debata a po chvíli do toho začneš ty svoje píčoviny. Koho zajímá nějaké natahování, když to běží třeba měsíc? To je jako řešit, proč server startuje 10 minut, když se při startu dělají různé kontroly. Java není nějaká hračka, to je seriózní nástroj a pokud s ním neumíš, tak ti může být na obtíž.
Takže na Hello world si uděláš normální službu, která poběží rychle. Ale to nesplňuje tvoje luxusní požadavky na plugin, co? :D
-
Jako to děláváš ty? :D
Tak asi neumíš programovat. Ale to vlastně víme. Výkonem nemá PHP šanci, takže jsi asi něco dělal špatně. Ale vlastně to chápeme. Takže ten důkaz, prosím :D
A nebo nechceš k tomu pluginu něco více říct? Takhle to totiž vypadá, žej si úplně mimo jako obvykle a začínáš vymýšlet ty svoje nesmysly, které budeš postupně akorát "vylepšovat". Nakonec z toho vyleze něco úplně jiného.
I obyčejný Hello, World ti poběží v Javě alespoň půl sekundy. Než se natáhne JRE, tak to prostě trvá.
HTTP server v PHP mi zabírá jen 3 MB RAM. Tomu Java nemůže konkurovat.
Když už chceš rychlý start a paměťovou nenáročnost, tak Céčko by mělo oboje strčit do kapsy.
-
Mám 2GB RAM a také v pohodě.
Tohle mne nestaci ani na rozumny vyvoj v JS - 4GB je naproste minimum (pres 1GB si v pohode vezme build, pres 1GB IDE a na prohlizece a system moc nezbyva). Neni to ani nic obrovskeho, prumerny (mozna dokonce i mensi) JavaScriptovy front-end. Kdyz jsem pak musel zacit testovat proti realnemu BE na lokale, tak bylo potreba jeste mnohem vic (pustena DB, dalsi IDE a samotny BE).
Kdyz jsem si hral se sitovou aplikaci v Jave, tak to spolklo jeste podstatne vic - 2x IDE (klient a server; >2GB), 2x ta spustena aplikace (~1GB), build veci (1-2GB), emulator Androidu (necele 1GB).
Jak bylo napsano stokrat - HW je levny, pamet nestoji skoro nic - 8GB je za tisicovku, lepsi dat par susnu do HW, nez aby skudleni vedlo k opakovanym zpozdenim (=ztratam penez) pri kazdem otevreni projektu, prekladu, debugovani.
-
I obyčejný Hello, World ti poběží v Javě alespoň půl sekundy. Než se natáhne JRE, tak to prostě trvá.
HTTP server v PHP mi zabírá jen 3 MB RAM. Tomu Java nemůže konkurovat.
Když už chceš rychlý start a paměťovou nenáročnost, tak Céčko by mělo oboje strčit do kapsy.
Jistě, Céčko mi podobné věci zvládá za 2-4 ms, stejně jako Fortran. Jen ta pracnost vývoje v PHP je neporovnatelně nižší, než v C, Fortranu a Javě dohromady. Samozřejmě to platí jen pro určité kategorie programů, protože pro různé typy úloh se hodí různé jazyky. Často je výhodnější použít Python, Lisp nebo třeba Javascript.
-
Java je nejlepší skoro na všechno. A pokud ti C to dává za 2 ms, tak Java o moc horší nebude. Ale ty ne, ty radši vezmeš něco skriptovacího.
-
I obyčejný Hello, World ti poběží v Javě alespoň půl sekundy. Než se natáhne JRE, tak to prostě trvá.
Odpovedel sis sam, reseni je nenatahovat JRE pri kazdem spusteni - napr. staricky Nailgun (ale urcite jsou novejsi a lepsi reseni).
HTTP server v PHP mi zabírá jen 3 MB RAM. Tomu Java nemůže konkurovat.
To je naprosto smesne:
php: 3MB
java (tomcat, mozna jsou jeste mene narocne): 24MB
rozdil v cene za pamet: 2,35Kc ;D ;D ;D
Navic tyto rozdily, ktere dopadaji negativne pro Javu v tomto prikladu ala hello world, pri nenulovem vytizeni, netrivialni aplikaci a nutnosti ji i udrzovat budou dopadat pro Javu jen lepe a lepe (JIT = vykon, stabilita, rozsirenost, knihovny). Osobne bych se ridil pravidlem, ze cim vetsi aplikace to ma byt, tim vice pri zvazovani preferovat Javu na ukor PHP, Pythonu, JS, atd.
-
Takže na Hello world si uděláš normální službu, která poběží rychle. Ale to nesplňuje tvoje luxusní požadavky na plugin, co? :D
Musel bych to udělat jako službu, která by se startovala při spuštění počítače a většinu času by jen překážela v RAM. To mi nevyhovuje. Raději si počkám 60 ms na vyřízení požadavku v PHP i s jeho spouštěním.
Pokud bych potřeboval ještě něco rychlejšího, zvolil bych AWK, Perl, Dlang, Lisp či Haskell, ale určitě ne Javu.
-
I na malé aplikace se vyplatí Java, protože z malých aplikací se obvykle už menší nestávají.
Takže na Hello world si uděláš normální službu, která poběží rychle. Ale to nesplňuje tvoje luxusní požadavky na plugin, co? :D
Musel bych to udělat jako službu, která by se startovala při spuštění počítače a většinu času by jen překážela v RAM. To mi nevyhovuje. Raději si počkám 60 ms na vyřízení požadavku v PHP i s jeho spouštěním.
Pokud bych potřeboval ještě něco rychlejšího, zvolil bych AWK, Perl, Dlang, Lisp či Haskell, ale určitě ne Javu.
Když máš tolik času, tak proč ne. 60 ms je strašná doba.
Určitě, to jsou superrychlé jazyky se skvělými nástroji pro vývoj :D
-
Navic tyto rozdily, ktere dopadaji negativne pro Javu v tomto prikladu ala hello world, pri nenulovem vytizeni, netrivialni aplikaci a nutnosti ji i udrzovat budou dopadat pro Javu jen lepe a lepe (JIT = vykon, stabilita, rozsirenost, knihovny). Osobne bych se ridil pravidlem, ze cim vetsi aplikace to ma byt, tim vice pri zvazovani preferovat Javu na ukor PHP, Pythonu, JS, atd.
Byl to malý program, který mi slouží jako plugin do editoru. Sám jsi nyní uvedl, že se Java hodí zejména pro velké aplikace. To není případ, který jsem řešil. Ten plugin je malý a malým i zůstane.
-
To jsme vůbec nečekali, že přijdeš s nesmyslem, který vysvětlíš až po nějaké době a ještě mezitím změníš téma 8)
-
Když máš tolik času, tak proč ne. 60 ms je strašná doba.
60 ms mi na vygenerování stubu vyhovuje, protože to vizuálně nepoznám. Víc jak půl sekundy s Javou mi však vadilo.
-
To jsme vůbec nečekali, že přijdeš s nesmyslem, který vysvětlíš až po nějaké době a ještě mezitím změníš téma 8)
Od začátku tvrdím, že ten program je malý. V čem vidíš nesmyslnost? Máš snad pocit, že se malé programy nesmí psát a je se mají dělat jen líné a žravé molochy?
-
Skoro :D
Právě proto vyvíjím rychlé programy místo pomalých, které jsou dnes v módě.
A v PHP :D Java je výkonem jinde než tenhle paskvil, ale zase se v ní tak rychle dělá, že i malé programy mají obrovskou funkcionalitu a nároky.
Nezapomeň, že knihovny PHP jsou napsány v C/C++, takže ve finálním výsledku jsou programy v PHP méně náročné na prostředky a výkonnější než v Javě.
-
I obyčejný Hello, World ti poběží v Javě alespoň půl sekundy. Než se natáhne JRE, tak to prostě trvá.
Stare PC s CPU, ktere se davno nevyrabi (vyslo pred 7 lety) a HDD, ktere je urcene na data (tj. pomale):
$ time java HelloWorld
Hello World!
real 0m0.099s
user 0m0.093s
sys 0m0.016s
To mame 100ms. Podotykam, ze jsem nedelal zadne tuneni na vykon/rychlost spusteni, urcite to pujde doladit mnohem vic.
Pokud ti to dava >500ms, tak mas velky krap. Masina pro vyvoj by IMO mela mit alespon starsi i5, kotel pameti a SSD.
-
Pokud ti to dava >500ms, tak mas velky krap. Masina pro vyvoj by IMO mela mit alespon starsi i5, kotel pameti a SSD.
Možná mám starý a líný JVM.
-
Ale na odsouzení Javy to přece stačí, tak co :D
-
Ale na odsouzení Javy to přece stačí, tak co :D
Jistěže stačí. Ostatní jazyky mi dávají kratší časy a více funkčnosti.
-
Tobě asi jo, no...
-
To mame 100ms. Podotykam, ze jsem nedelal zadne tuneni na vykon/rychlost spusteni, urcite to pujde doladit mnohem vic..
100 ms je hodně. zkus na stejném počítači
time perl -le 'print "hello"'
-
Mám 2GB RAM a také v pohodě.
Tohle mne nestaci ani na rozumny vyvoj v JS - 4GB je naproste minimum (pres 1GB si v pohode vezme build, pres 1GB IDE a na prohlizece a system moc nezbyva). Neni to ani nic obrovskeho, prumerny (mozna dokonce i mensi) JavaScriptovy front-end. Kdyz jsem pak musel zacit testovat proti realnemu BE na lokale, tak bylo potreba jeste mnohem vic (pustena DB, dalsi IDE a samotny BE).
Kdyz jsem si hral se sitovou aplikaci v Jave, tak to spolklo jeste podstatne vic - 2x IDE (klient a server; >2GB), 2x ta spustena aplikace (~1GB), build veci (1-2GB), emulator Androidu (necele 1GB).
Jak bylo napsano stokrat - HW je levny, pamet nestoji skoro nic - 8GB je za tisicovku, lepsi dat par susnu do HW, nez aby skudleni vedlo k opakovanym zpozdenim (=ztratam penez) pri kazdem otevreni projektu, prekladu, debugovani.
Kdybys používal rozumné nástroje, tak ti pro vývoj stačí nejlevnější VPS s 500 mb paměti, na kterém může současně běžet i produkční aplikace.
-
To mame 100ms. Podotykam, ze jsem nedelal zadne tuneni na vykon/rychlost spusteni, urcite to pujde doladit mnohem vic..
100 ms je hodně. zkus na stejném počítači
time perl -le 'print "hello"'
Si děláte prd*l? Jedna lopata začne psát nesmysly a další se jako přidá a začne to rozvíjet? Really?
Chápeš, co noef naznačoval?
-
Mám 2GB RAM a také v pohodě.
Tohle mne nestaci ani na rozumny vyvoj v JS - 4GB je naproste minimum (pres 1GB si v pohode vezme build, pres 1GB IDE a na prohlizece a system moc nezbyva). Neni to ani nic obrovskeho, prumerny (mozna dokonce i mensi) JavaScriptovy front-end. Kdyz jsem pak musel zacit testovat proti realnemu BE na lokale, tak bylo potreba jeste mnohem vic (pustena DB, dalsi IDE a samotny BE).
Kdyz jsem si hral se sitovou aplikaci v Jave, tak to spolklo jeste podstatne vic - 2x IDE (klient a server; >2GB), 2x ta spustena aplikace (~1GB), build veci (1-2GB), emulator Androidu (necele 1GB).
Jak bylo napsano stokrat - HW je levny, pamet nestoji skoro nic - 8GB je za tisicovku, lepsi dat par susnu do HW, nez aby skudleni vedlo k opakovanym zpozdenim (=ztratam penez) pri kazdem otevreni projektu, prekladu, debugovani.
Kdybys používal rozumné nástroje, tak ti pro vývoj stačí nejlevnější VPS s 500 mb paměti, na kterém může současně běžet i produkční aplikace.
Technologie jsou zadane klientem, pouzivam nejrychlejsi a nejstabilnejsi varianty. Napr. pro takovy sass prekladac nic lepsiho neni, proste si to giga pameti ukousne (prekladac existuje i ve variante v Ruby a to je jeste horsi).
IDE, ne textovy editor, si take bezne 1GB vezme. Tech 500MB by mozna stacilo na spusteni prohlizece a web servru. Ale pokud bych nemohl psat kod a ani ho prekladat, tak je to k nicemu. Navic tahle levna VPS jsou vykonem casto horsi nez treba RPI, takze to doufam nemyslis vazne. On je "vyvoj" a vyvoj. Pri "vyvoji" ti IDE textovy editor nepomaha a musis casteji provadet preklad a manulani testovani. Pri vyvoji ti IDE pomaha - naznaci ti preklepy ve jmenech promennych, nevalidni kod, pomaha ti s refaktorovanim, dokumentaci atd.
-
javaman, kit, obaja ste vadni.
-
To mame 100ms. Podotykam, ze jsem nedelal zadne tuneni na vykon/rychlost spusteni, urcite to pujde doladit mnohem vic..
100 ms je hodně. zkus na stejném počítači
time perl -le 'print "hello"'
$ time perl -le 'print "hello"'
hello
real 0m0.009s
user 0m0.000s
sys 0m0.008s
$ time java Hello
Hello
real 0m0.236s
user 0m0.152s
sys 0m0.076s
-
Neni to malo, ale rozhodne na to, co chtel Kit, to s prehledem stacilo - 100ms pro generovani kodu je myslim celkem v poradku cas.
ok, udelame si tedy mensi srovnani:
JS - 102ms
java - 99ms
ruby - 48ms
php - 31ms
java + nailgun - 4ms ;)
perl - 3ms
haskell - 2ms
c - 1ms
Takze se ukazuje, ze Java muze klidne byt skoro 8x rychlejsi nez PHP, jen se musi chtit.
PS: Pametovou narocnost zcela zanedbavam, protoze resit nejakych 20MB je uplne mimo, kdyz to doslova stoji DVE koruny. To neberu jako validni argument :D.
-
IDE, ne textovy editor, si take bezne 1GB vezme. Tech 500MB by mozna stacilo na spusteni prohlizece a web servru. Ale pokud bych nemohl psat kod a ani ho prekladat, tak je to k nicemu. Navic tahle levna VPS jsou vykonem casto horsi nez treba RPI, takze to doufam nemyslis vazne. On je "vyvoj" a vyvoj. Pri "vyvoji" ti IDE textovy editor nepomaha a musis casteji provadet preklad a manulani testovani. Pri vyvoji ti IDE pomaha - naznaci ti preklepy ve jmenech promennych, nevalidni kod, pomaha ti s refaktorovanim, dokumentaci atd.
Editovat a kompilovat program v Javě se dá i na 256 MB RAM, jak jsem si nedávno vyzkoušel. Jistěže to bylo o něco pomalejší, ale co bych nechtěl po staré šunce, že?
Z Vimu se také dá přímo kompilovat a spouštět testy - není to nic časově náročného a také to mám na jedné klávese. Ve Vimu ani překlepy nevznikají, našeptávat a korigovat text umí dobře a pozná i nevalidní kód. S refaktorováním není problém a dokumentaci také umi vygenerovat. K čemu IDE?
-
Takze se ukazuje, ze Java muze klidne byt skoro 8x rychlejsi nez PHP, jen se musi chtit.
To bych tenkrát musel znát nailgun. Tuším, že neexistoval.
-
JS - 102ms
java - 99ms
ruby - 48ms
php - 31ms
java + nailgun - 4ms ;)
perl - 3ms
haskell - 2ms
c - 1ms
Jestli jsem to pochopil správně, tak nailgun je server. To nepotřebuji.
Z použitelných nástrojů mi tedy zbývá Perl a Haskell + pár dalších, které jsi neměřil, ale také dávají dobré výsledky.
-
A nebo se naučit programovat.
-
mohol by moderator premazat vlakno??? k otazke su asi len 2 odpovede, zvysok sami blast
-
Když neumíš ani psát, tak se nemůžeš divit. Všechny ostatní diskuze jsou normálně k tématu. Jen ta tvoje se zvrhla.
-
A nebo se naučit programovat.
Copak, Perl ani Haskell se ti nelíbí?
-
A nebo se naučit programovat.
Copak, Perl ani Haskell se ti nelíbí?
Pokud je pro tebe užitečný Hello world, tak asi budeš tak někde na straně 30 knížky pro začátečníky. Ale to přijde, dej tomu 20 let a uvidíš věci jinak. Ještě se budeš smát, jak jsi jako malý používal textový editor na vývoj.
-
A nebo se naučit programovat.
Copak, Perl ani Haskell se ti nelíbí?
Pokud je pro tebe užitečný Hello world, tak asi budeš tak někde na straně 30 knížky pro začátečníky. Ale to přijde, dej tomu 20 let a uvidíš věci jinak. Ještě se budeš smát, jak jsi jako malý používal textový editor na vývoj.
Ty se snad taky jednou budeš smát, jak jsi ve 13 letech troloval na diskuzích.
-
A nebo se naučit programovat.
Copak, Perl ani Haskell se ti nelíbí?
Pokud je pro tebe užitečný Hello world, tak asi budeš tak někde na straně 30 knížky pro začátečníky. Ale to přijde, dej tomu 20 let a uvidíš věci jinak. Ještě se budeš smát, jak jsi jako malý používal textový editor na vývoj.
"Hello world" je jen test, který dává všem jazykům stejné vstupní podmínky pro změření latence při spuštění. U náročných aplikací se prvně začne zpomalovat Perl a Java ho dožene. U Haskellu jí to bude trvat ještě déle.
Cílem programátora není psát rozsáhlé molochy. Nejsem placen za řádky, ale za výsledek. Když je má aplikace 100× rychlejší než aplikace konkurenta, tak jsem spokojen dvojnásobně.
-
Javamane ty kokot, radsej sa venuj niecomu rozumnejsiemu, ako trollingu na rootu. Zivot je kratky aby si ho premarnil takymito nezmyslami. Dobre ti radim. A porovnavat C s Javou, co sa rychlosti tyka, tak to je uz ina salka kavy :D. Mozno aj assembler by bol na urovni javy podla tvojich domnienok :D. Btw chod sa spytat do zbrojarskych, vesmirnych firiem, v com maju naprogramovane satelity, pilotovanie lietadiel, zameriavanie cielov. Urcite tam najdes javu :D
-
Btw chod sa spytat do zbrojarskych, vesmirnych firiem, v com maju naprogramovane satelity, pilotovanie lietadiel, zameriavanie cielov. Urcite tam najdes javu :D
Oblíbený je Lisp.
-
Když neumíš ani psát, tak se nemůžeš divit. Všechny ostatní diskuze jsou normálně k tématu. Jen ta tvoje se zvrhla.
on se zeptal normalne, diskuze se nezvrhla, ale jeden dementni javaman (( ji zvrhnul... tobe staci kdyz vidis slovo java a hned pribehnejs blejt... tvuj tatinek vlastni Oracle nebo proc se chovas jako lopata?
-
"Hello world" je jen test, který dává všem jazykům stejné vstupní podmínky pro změření latence při spuštění. U náročných aplikací se prvně začne zpomalovat Perl a Java ho dožene. U Haskellu jí to bude trvat ještě déle.
Cílem programátora není psát rozsáhlé molochy. Nejsem placen za řádky, ale za výsledek. Když je má aplikace 100× rychlejší než aplikace konkurenta, tak jsem spokojen dvojnásobně.
Ano, ty podmínky zajímají jen začátečníky a speciální případy, kterých je velice málo. Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat. Java je o něco málo pomalejší než céčko, takže nemá moc konkurenci. A jde v ní psát i velké věci a brutálně rychle. Proto je to král.
Pokud ji píšeš v PHP, tak konkurent by musel použít brainfuck.
-
Když neumíš ani psát, tak se nemůžeš divit. Všechny ostatní diskuze jsou normálně k tématu. Jen ta tvoje se zvrhla.
on se zeptal normalne, diskuze se nezvrhla, ale jeden dementni javaman (( ji zvrhnul... tobe staci kdyz vidis slovo java a hned pribehnejs blejt... tvuj tatinek vlastni Oracle nebo proc se chovas jako lopata?
Až doděláš základku, tak se stav a uvidíš, že nic nekazím. Pouze podporuji rozvoj tématu.
-
Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat.
Tím bych si nebyl tak jistý. FlowViewer (https://sourceforge.net/projects/flowviewer/) je psaný jako sada perlových CGI skriptů. Bohužel rychlost nad větším množstvím dat celkem upadá (konkrétně FlowGrapher Analysis s velkým časovým rozsahem).
-
Až doděláš základku, tak se stav a uvidíš, že nic nekazím. Pouze podporuji rozvoj tématu.
zakladku sem dodelal v druhe polovine minulem stoleti, ty nepodporujes rozvoj tematu, snazis se o podporu sveho zdegenerovaneho ega...
-
Cílem programátora není psát rozsáhlé molochy. Nejsem placen za řádky, ale za výsledek. Když je má aplikace 100× rychlejší než aplikace konkurenta, tak jsem spokojen dvojnásobně.
Vy mozna, ale zakaznik zaplati treba za 10x vice hodin, nez kdyby to nekdo udelal v Jave. Navic podle dost lidi ve velkych aplikacich je Java pomalejsi pouze o 0-1x nez C++, ale za vyvoj Javovske verze zakaznik zaplati zlomek penez (vyviji se velmi rychle, skoro vse je standardizovane, zajete nastroje, Java programatori na kazdem rohu) a je to pak snazsi na udrzbu (tusim ze u C++ byly problemy s konvencemi - knihovnami a programatory a napr. stylem pointeru, vse slo resit [a resilo se] mnoha zpusoby v jedne code base; v Jave mate zajete velke knihovny, ktere se pouzivaji na ty molochy, v C++ myslim takoveho nic ani neni). Pokud zvolite spatny nastroj (PHP, C, assembler) a sice dosahnete vyssiho vykonu, ale za cenu napr. o rad vice hodin, tak jste spokojen vy, ne nutne zakaznik. Co tak sleduji vyvoj projektu v Jave, tak vykon se resi spise spravnym navrhem, vhodnymi knihovnami, nastavenim db, optimalizaci dotazu a velmi vyjmecne se meri kazda instrukce a spada se k optimalizaci na urovni bytekodu. Nikdy jsem nevidel, ze by to nekdo resil prepisem do C++. IMO to bude tim, ze takovy vykon potrebuje jen par gigantu na planete, vetsina malych a strednich firem si vystaci s tim, ze to funguje a kdyztak poridi silnejsi zelezo za par supu, protoze se proste nevyplati to cpat do optimalizaci na urovni SW.
Jestli jsem to pochopil správně, tak nailgun je server. To nepotřebuji.
Protoze nemate 2Kc na pamet? Pak tedy nepiste hlouposti, ze v Jave by ten plugin nesel napsat, protoze to pomalu startuje, kdyz by ten start Javovskeho programu mohl byt skoro o rad rychlejsi nez standardni interpret PHP.
Z použitelných nástrojů mi tedy zbývá Perl a Haskell + pár dalších, které jsi neměřil, ale také dávají dobré výsledky.
Kdyz mate poradne IDE, tak mate neco ala live templaty z IDEA a neni potreba zadny dalsi plugin, ktery si musite sam psat. Podle me jen resite neexistujici problemy. Pokud nemate 2Kc na pamet, tak asi ani nepracujete, protoze i s minimem ze zakona by nebyl problem si ji dokoupit (po par mesicich, prece jen s minimem nasetrit tisicovku na pamet, kde rozjedete az 340 instanci weboveho servru v Jave, chvili trva :P).
-
"Hello world" je jen test, který dává všem jazykům stejné vstupní podmínky pro změření latence při spuštění. U náročných aplikací se prvně začne zpomalovat Perl a Java ho dožene. U Haskellu jí to bude trvat ještě déle.
Cílem programátora není psát rozsáhlé molochy. Nejsem placen za řádky, ale za výsledek. Když je má aplikace 100× rychlejší než aplikace konkurenta, tak jsem spokojen dvojnásobně.
Ano, ty podmínky zajímají jen začátečníky a speciální případy, kterých je velice málo. Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat. Java je o něco málo pomalejší než céčko, takže nemá moc konkurenci. A jde v ní psát i velké věci a brutálně rychle. Proto je to král.
Pokud ji píšeš v PHP, tak konkurent by musel použít brainfuck.
Zapomněl jsi na Haskell...
Ten konkurent použil špagetové PHP. V tom PHP jsem to jen zkrátil a přepsal do OOP. Takže i po doplnění chybějící funkčnosti to mělo třetinovou délku proti původnímu řešení + uvedené zrychlení. Ovšem to byl extrém, obvykle PHP skripty zrychlím jen 2× - 5×.
-
Jeste k tomu, ze nailgun musi bezet jako server a tedy porad zabirat pamet. Existuje i napr. drip (https://github.com/ninjudd/drip), ktery se spusti s prvnim spustenim javovske aplikace a nechava pripravenou VM pouze urcity cas. Takze jakmile prestanete programovat, tak to po chvili sam vypne. Ale stejnak si myslim, ze je to zbytecne resit, protoze i kdyby vam ten mini plugin jel stale v pameti, tak tech par megabajtu se zcela ztrati vedle gigabajtu na prohlizec, desitek az stovek megabajtu pro aplikaci, db server, IDE/textovy editor atd.
Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).
-
Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat.
Tím bych si nebyl tak jistý. FlowViewer (https://sourceforge.net/projects/flowviewer/) je psaný jako sada perlových CGI skriptů. Bohužel rychlost nad větším množstvím dat celkem upadá (konkrétně FlowGrapher Analysis s velkým časovým rozsahem).
Ta pomalost může mít spoustu důvodů. Nejspíš bude problém na straně databáze. CGI skript by měl zpracovávat jen tolik dat, kolik se zobrazí.
-
Cílem programátora není psát rozsáhlé molochy. Nejsem placen za řádky, ale za výsledek. Když je má aplikace 100× rychlejší než aplikace konkurenta, tak jsem spokojen dvojnásobně.
Vy mozna, ale zakaznik zaplati treba za 10x vice hodin, nez kdyby to nekdo udelal v Jave. Navic podle dost lidi ve velkych aplikacich je Java pomalejsi pouze o 0-1x nez C++, ale za vyvoj Javovske verze zakaznik zaplati zlomek penez (vyviji se velmi rychle, skoro vse je standardizovane, zajete nastroje, Java programatori na kazdem rohu) a je to pak snazsi na udrzbu (tusim ze u C++ byly problemy s konvencemi - knihovnami a programatory a napr. stylem pointeru, vse slo resit [a resilo se] mnoha zpusoby v jedne code base; v Jave mate zajete velke knihovny, ktere se pouzivaji na ty molochy, v C++ myslim takoveho nic ani neni). Pokud zvolite spatny nastroj (PHP, C, assembler) a sice dosahnete vyssiho vykonu, ale za cenu napr. o rad vice hodin, tak jste spokojen vy, ne nutne zakaznik. Co tak sleduji vyvoj projektu v Jave, tak vykon se resi spise spravnym navrhem, vhodnymi knihovnami, nastavenim db, optimalizaci dotazu a velmi vyjmecne se meri kazda instrukce a spada se k optimalizaci na urovni bytekodu. Nikdy jsem nevidel, ze by to nekdo resil prepisem do C++. IMO to bude tim, ze takovy vykon potrebuje jen par gigantu na planete, vetsina malych a strednich firem si vystaci s tim, ze to funguje a kdyztak poridi silnejsi zelezo za par supu, protoze se proste nevyplati to cpat do optimalizaci na urovni SW.
Jenže já toho výkonu nedosahuji přepisem do C++ nebo Javy. Dělám to formou objektového návrhu. Už použitím samotného objektového přístupu se aplikace významně zrychlí. Zrychlení nebývá mým cílem, ale dostavuje se tak nějak automaticky právě použitím vhodné architektury. Tím, že mám ten kód výrazně kratší než kdyby byl v Javě, mám aplikaci hotovou dříve.
-
Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat.
Tím bych si nebyl tak jistý. FlowViewer (https://sourceforge.net/projects/flowviewer/) je psaný jako sada perlových CGI skriptů. Bohužel rychlost nad větším množstvím dat celkem upadá (konkrétně FlowGrapher Analysis s velkým časovým rozsahem).
Ta pomalost může mít spoustu důvodů. Nejspíš bude problém na straně databáze. CGI skript by měl zpracovávat jen tolik dat, kolik se zobrazí.
Určitě, DB to zabila :D
(http://blog.carlesmateo.com/wp-content/uploads/2014/10/blog-carlesmateo-com-performance-several-languages-php7-phantomjs-nodejs-java-bash-go-perl-luajit-hhvm3_9-scale_mod5.png)
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/ (http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/)
-
Tím, že mám ten kód výrazně kratší než kdyby byl v Javě, mám aplikaci hotovou dříve.
To zase asi ve snu. Java má jedny z nejlepších knihoven vůbec, které v PHP budeš mít až tak za 5 let.
-
Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).
Jenže to často vyvíjím pro zákazníky, kteří ani ty 4 GB nemají. Nemůžu pro ně dělat něco, co jim na jejich mašinách nepojede. Za to by mi nezaplatili.
-
Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat.
Tím bych si nebyl tak jistý. FlowViewer (https://sourceforge.net/projects/flowviewer/) je psaný jako sada perlových CGI skriptů. Bohužel rychlost nad větším množstvím dat celkem upadá (konkrétně FlowGrapher Analysis s velkým časovým rozsahem).
Ta pomalost může mít spoustu důvodů. Nejspíš bude problém na straně databáze. CGI skript by měl zpracovávat jen tolik dat, kolik se zobrazí.
Máte pravdu, návrh v tom také bude mít prsty.
Databáze je kolekce souborů s flows z NetFlow kolektoru, nad kterými se spouští céčkové utility. Ty jsou brzděné jen rychlostí IO (cache kromě souborové není). Horší je pak zpracování do grafu (https://sourceforge.net/p/flowviewer/discussion/general/thread/cc1f02d5/).
-
to je šulín... jsem ho do ted jen podezrival, ale on se priznal - tvari se, ze neco vyviji a pritom pracuje se 2GB RAM - to staci stezi na prohlizec a IDE. Zbytek te omacky jen svedci o tom jaky je asocial ktery navic uctuje zakaznikum vlastni neefektivitu pouzivanim obskurnich nastroju. Kite ty dneska davas teda bomby.
-
Určitě, DB to zabila :D
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/ (http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/)
Tím, že někdo udělá test na nějaké cykly, jasně upřednostní imperativní jazyky, jakým je např. Java. Vsadil bych se, že v testu nebyl použit ani jeden objekt, proto jsou ty výsledky zcela nesmyslné.
-
Určitě, DB to zabila :D
To je hodně debilní benchmark, který není v rozporu s tím, co jsem psal. Pokud potřebuješ smyčku o 10 * 32000 * 32000 krocích pro vygenorování jedné stránky, tak děláš něco špatně. A psát takovou smyčku v bashi? LOL
-
Určitě, DB to zabila :D
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/ (http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/)
Tím, že někdo udělá test na nějaké cykly, jasně upřednostní imperativní jazyky, jakým je např. Java. Vsadil bych se, že v testu nebyl použit ani jeden objekt, proto jsou ty výsledky zcela nesmyslné.
Přesně. Chudák objektový Bash, vůbec se nedostal ke svému :D
-
Každé fórum má čas od času nějakého stálého retardovaného kašpara, který se časem vyčerpá a zmizí.
Tady je to teď "javaman".
-
Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).
Jenže to často vyvíjím pro zákazníky, kteří ani ty 4 GB nemají. Nemůžu pro ně dělat něco, co jim na jejich mašinách nepojede. Za to by mi nezaplatili.
Ehm, co je to za logiku? Podle tohoto tvrzeni by muselo platit:
Protoze pri vyvoji front-endu pouzivam 16GB pameti tak to znamena, ze vysledny JavaScript pro stranku bude vyzadovat 16GB pameti.
To jako myslite vazne? WTF?
-
Každé fórum má čas od času nějakého stálého retardovaného kašpara, který se časem vyčerpá a zmizí.
Tady je to teď "javaman".
Jen Kit s bráchou jsou tu navždy!
-
Určitě, DB to zabila :D
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/ (http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/)
Tím, že někdo udělá test na nějaké cykly, jasně upřednostní imperativní jazyky, jakým je např. Java. Vsadil bych se, že v testu nebyl použit ani jeden objekt, proto jsou ty výsledky zcela nesmyslné.
Přesně. Chudák objektový Bash, vůbec se nedostal ke svému :D
Bash na cykly vůbec není stavěný, proto v takovém testu logicky propadl. Síla Bashe je v něčem úplně jiném - používá se jako lepidlo mezi drobnými utilitkami, kterých je v linuxových systémech hromada a které jsou rychlé.
Bash má k OOP blíž než Java.
-
Jako třeba Systemd :D
Java je normální objektový jazyk a Bash k tomu asi blíže bude mít těžko :D Ale to bude zase nějaká specialita! Povídej!
-
Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).
Jenže to často vyvíjím pro zákazníky, kteří ani ty 4 GB nemají. Nemůžu pro ně dělat něco, co jim na jejich mašinách nepojede. Za to by mi nezaplatili.
Ehm, co je to za logiku? Podle tohoto tvrzeni by muselo platit:
Protoze pri vyvoji front-endu pouzivam 16GB pameti tak to znamena, ze vysledny JavaScript pro stranku bude vyzadovat 16GB pameti.
To jako myslite vazne? WTF?
Používám tolik RAM, kolik mají zákazníci. Bohatě mi to stačí, víc nepotřebuji. Je na tom snad něco špatně?
-
Bash má k OOP blíž než Java.
Wut? Nejsem fanda PowerShellu ani MS, ale ten je aspoň integrovaný do .NETu a umí OOP. Nespletl jste si to?
-
Jako třeba Systemd :D
Java je normální objektový jazyk a Bash k tomu asi blíže bude mít těžko :D Ale to bude zase nějaká specialita! Povídej!
Co bych měl povídat? Ukaž mi třeba na GitHubu aplikaci v Javě, která je napsána objektově. Většina z toho má do OOP hodně daleko.
Naproti tomu Bash skutečně pracuje s linuxovými utilitami objektově. Při spuštění jim jako parametry předá konfiguraci (ve stylu konstruktoru) a pak do nich rourou cpe data (vstup). Z druhé strany ta data odebírá a přesměruje je do další utility (objektu) nebo do souboru (výsledek). Takže v Bashi můžeš parádně dělat objektově. Dokonce každý ten objekt může běžet na jiném jádře procesoru. Stačí?
-
Ty mi ukaž na GH neobjektový kód v objektové Javě. To by mě zajímalo.
Už ty houby fakt nejez. Vím, že teď je sezóna, ale bacha na to :D
-
Ty mi ukaž na GH neobjektový kód v objektové Javě. To by mě zajímalo.
Už ty houby fakt nejez. Vím, že teď je sezóna, ale bacha na to :D
Moment... Marně hledám něco užitečného.
-
Spíše marně hledáš něco neobjektového v objektovém jazyce :D
-
Spíše marně hledáš něco neobjektového v objektovém jazyce :D
Pokud si myslíš, že najdeš v Javě něco objektového, tak hledej také. Třeba to budeš mít dřív :)
-
Java je objektový jazyk, takže se v ní píše objektově.
-
Nemůžu si pomoct :D
https://bitbucket.org/tuxovatardis/robo2015-zs/src/2a2fb0b6c5ce9ae7d7c8a8f60a72c9964853dad8/program-rewrite/src/TuxTARDIS/Rewrite/?at=master
-
Takže jsem našel něco, co by mohlo být užitečné, ale objektově je jen z malé části:
https://github.com/pierrelemee/yaml-parser (https://github.com/pierrelemee/yaml-parser)
-
Nemůžu si pomoct :D
https://bitbucket.org/tuxovatardis/robo2015-zs/src/2a2fb0b6c5ce9ae7d7c8a8f60a72c9964853dad8/program-rewrite/src/TuxTARDIS/Rewrite/?at=master
Vypadá to zajímavě, něco málo je i objektově, ale většina z toho je imperativní jak z doby Pascalu. Proč je např. metoda Pos.directionOf() statická, když k tomu není žádný důvod? Operátor instanceof také není zrovna objektový - polymorfismus je přece mnohem výhodnější. Metoda Pos.modify() je také podivná - proč je statická a k čemu ten switch?
Je to však hezká úloha, zítra se na ni podívám trochu podrobněji.
-
Nemůžu si pomoct :D
https://bitbucket.org/tuxovatardis/robo2015-zs/src/2a2fb0b6c5ce9ae7d7c8a8f60a72c9964853dad8/program-rewrite/src/TuxTARDIS/Rewrite/?at=master
Vypadá to zajímavě, něco málo je i objektově, ale většina z toho je imperativní jak z doby Pascalu. Proč je např. metoda Pos.directionOf() statická, když k tomu není žádný důvod? Operátor instanceof také není zrovna objektový - polymorfismus je přece mnohem výhodnější. Metoda Pos.modify() je také podivná - proč je statická a k čemu ten switch?
Je to však hezká úloha, zítra se na ni podívám trochu podrobněji.
Ad static v Pos – už nevím, zpětně to vypadá, jako bych vyráběl cosi jako POD, i když to nemá smysl.
Ad Pos.modify – má to dělat posun souřadnice v daném směru (NSEW); přijde mi lepší switch než magie s modulem.
Ad instanceof – preferoval jsem centralizovanou implementaci oproti kódu rozdělenému do více tříd; zase to vypadá jako tendence k POD.
Tohle už by nemuselo být tak imperativní: UI pro Swing a leJOS EV3 (https://bitbucket.org/thinklikeone/robo2015-ss/src/6da6ab9dcaf2ca60774638da267a4576592bea49/program/microgui/src/thinklikeone/gui/?at=master)
-
To jsem asi ještě neznal objektový enum, protože to by vlastně bylo elegantní řešení. :D
-
To jsem asi ještě neznal objektový enum, protože to by vlastně bylo elegantní řešení. :D
Přesně :)
-
Je to Java. Je pre nu jedno, ci vyvijas na Linux, Windows ci OS X. Najpohodlnejsie je to na linuxe. Avsak linux je na notebooku nepouzitelny v pripade, ze ho chces pouzivat aj na osobne veci a nie iba cisto na pracu. Pri OS X budes konfiguracie riesit jednoduchsie ako na Windowse.. Najrozumnejsia volba je asi Macbook.
-
Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).
Jenže to často vyvíjím pro zákazníky, kteří ani ty 4 GB nemají. Nemůžu pro ně dělat něco, co jim na jejich mašinách nepojede. Za to by mi nezaplatili.
Ehm, co je to za logiku? Podle tohoto tvrzeni by muselo platit:
Protoze pri vyvoji front-endu pouzivam 16GB pameti tak to znamena, ze vysledny JavaScript pro stranku bude vyzadovat 16GB pameti.
To jako myslite vazne? WTF?
Používám tolik RAM, kolik mají zákazníci. Bohatě mi to stačí, víc nepotřebuji. Je na tom snad něco špatně?
Pokud to zhorsuje tvoji produktivitu, tak ano, je na tom neco spatne. To stejne plati pro textovy editor versus IDE - si pamatuju, ze z tebe minule vypadlo, ze vlastne ani netusis, co za refaktorovani IDE opravdu umi; pro Javu opravdu hodne: napr. zmena poradi parametru metody [vsude tam, kde se opravdu dedi, ne jen trapne pouze podle jmena], presunuti tridy mezi baliky [automaticky to upravi vsechny importy], presun members do predka/potomka [nemusi byt v jednom souboru]*. Argument, ze to nepouzivas (to jsi myslim minule napsal, ale mozna se pletu), opravdu nepouzivej, protoze to znamena, ze delas pouze na nejakych trivialitach, kde se nikdy nemeni pozadavky v prubehu vyvoje (to jsem jeste nezazil :D) a kde vysledny kod je pouze napis a zapomen, nikdy se do vysledne aplikace nebude nic pridavat/opravovat/upravovat (take jsem take nezazil). Predchozi veta navic pocita s tim, ze pises hned napoprve dokonaly kod, coz jsem opet v praxi take nikdy nevidel.
Vsimni si, ze podle tve logiky by kazdy, kdo si prohlizi stranky s JavaScriptem, ktery jsem napsal, by mel mit alespon 16GB pameti**, protoze tolik bylo pouzito pri jeho napsani (realne staci par desitek megabajtu). Vzdyt to je uplne na hlavu, proc by se podle pametove narocnosti dev nastroju mela jakkoliv ridit pametova (nebo jakakoliv) narocnost vysledne aplikace?
**: Pripadne "pouze" nejakych 6GB, pokud pocitas pouze pamet zabranou programy, ktere byly pouzity pri vyvoji samotnem.
*: A to bych rad pripomnel, ze se psanim kodu v Jave nezivim a ani v ni nepisu ve volnem case, takze jsem urcite mnoho pripadu pouziti vynechal. Takovy pristup, jako mas ty, bych cekal spis od studenta, co potrebuje nejak slepit tech par radku na zapocet a v podstate se mu ani nevyplati se ucit ovladat a pouzivat, pripadne i platit, plnohodnotne IDE.
-
V praci mam na vyvoj v Jave Thinkpad rada T5xx (bohuzel Windows 7) doma pro soukrome ucely Macbook a Thinkpad T4xx s Win 10 a Linuxem. Doporucuji zamerit se na velikost ram a opravdu rychle SSD (samozrejmosti je i7 cpu).
Co jsem tak vysledoval z diskuzi na netu tak mezi starou serii T530 a novymi T5xx neni vykonostne az tak moc vysoky rozdil - co me, ale stve je velikost upgradovatelne RAM. Ocenil bych tak 32GB - uvazuji tedy o prechodu na W5xx
Take by me zajimalo zda nekdo pouzivate m.2 SSD v Raid0 - stoji to za ten narust vykonu? je to bezpecne?
-
Používám tolik RAM, kolik mají zákazníci. Bohatě mi to stačí, víc nepotřebuji. Je na tom snad něco špatně?
Pokud to zhorsuje tvoji produktivitu, tak ano, je na tom neco spatne. To stejne plati pro textovy editor versus IDE - si pamatuju, ze z tebe minule vypadlo, ze vlastne ani netusis, co za refaktorovani IDE opravdu umi; pro Javu opravdu hodne: napr. zmena poradi parametru metody [vsude tam, kde se opravdu dedi, ne jen trapne pouze podle jmena], presunuti tridy mezi baliky [automaticky to upravi vsechny importy], presun members do predka/potomka [nemusi byt v jednom souboru]*. Argument, ze to nepouzivas (to jsi myslim minule napsal, ale mozna se pletu), opravdu nepouzivej, protoze to znamena, ze delas pouze na nejakych trivialitach, kde se nikdy nemeni pozadavky v prubehu vyvoje (to jsem jeste nezazil :D) a kde vysledny kod je pouze napis a zapomen, nikdy se do vysledne aplikace nebude nic pridavat/opravovat/upravovat (take jsem take nezazil). Predchozi veta navic pocita s tim, ze pises hned napoprve dokonaly kod, coz jsem opet v praxi take nikdy nevidel.
Popsal jsi jen kosmetické úpravy v kódu, které by mi na plnohodnotné refaktorování nestačily a stejně bych ho musel dělat ručně. Na to mi stačí Vim s 2GB RAM.
Pokud se mění požadavky během vývoje, tak jen dopíši chybějící třídy, případně staré vyměním za nové, ale architekturu aplikace neměním.
-
Na jaře jsem si koupil Thinkpad P50 (Pčka jsou nové portable workstation, místo řady W).
takže mám
Xeon E3-1535M - https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E3-1535M+v5+%40+2.90GHz&id=2667
64 GB RAM
Samsung 950 PRO NVMe m2 - http://www.samsung.com/uk/consumer/memory-storage/ssd/950-pro/MZ-V5P512BW
Do 4K displaye jsem nešel, obaval jsem se, že podpora hidpi je pořád nic moc, tak mám FullHD.
Velka ramka je užitečná pro virtuálky a clusterovaní databazí nebo app serveru. Mit vlastni java vyvojare jako zamestnance, kterym platim 70k nebo vic kazdy mesic tak bych nic jineho nekupoval.
-
Co bych měl povídat? Ukaž mi třeba na GitHubu aplikaci v Javě, která je napsána objektově. Většina z toho má do OOP hodně daleko.
Namátkou..
https://github.com/JetBrains/intellij-community
https://github.com/neo4j/neo4j
https://github.com/hazelcast/hazelcast
-
Co bych měl povídat? Ukaž mi třeba na GitHubu aplikaci v Javě, která je napsána objektově. Většina z toho má do OOP hodně daleko.
Osobně bych spíš uvítal nějakou repository s kvalitním php kódem. Čistě pro studijní účely.
-
Používám tolik RAM, kolik mají zákazníci. Bohatě mi to stačí, víc nepotřebuji. Je na tom snad něco špatně?
Pokud to zhorsuje tvoji produktivitu, tak ano, je na tom neco spatne. To stejne plati pro textovy editor versus IDE - si pamatuju, ze z tebe minule vypadlo, ze vlastne ani netusis, co za refaktorovani IDE opravdu umi; pro Javu opravdu hodne: napr. zmena poradi parametru metody [vsude tam, kde se opravdu dedi, ne jen trapne pouze podle jmena], presunuti tridy mezi baliky [automaticky to upravi vsechny importy], presun members do predka/potomka [nemusi byt v jednom souboru]*. Argument, ze to nepouzivas (to jsi myslim minule napsal, ale mozna se pletu), opravdu nepouzivej, protoze to znamena, ze delas pouze na nejakych trivialitach, kde se nikdy nemeni pozadavky v prubehu vyvoje (to jsem jeste nezazil :D) a kde vysledny kod je pouze napis a zapomen, nikdy se do vysledne aplikace nebude nic pridavat/opravovat/upravovat (take jsem take nezazil). Predchozi veta navic pocita s tim, ze pises hned napoprve dokonaly kod, coz jsem opet v praxi take nikdy nevidel.
Popsal jsi jen kosmetické úpravy v kódu, které by mi na plnohodnotné refaktorování nestačily a stejně bych ho musel dělat ručně. Na to mi stačí Vim s 2GB RAM.
Problem je, ze i tyto "kosmeticke upravy" by jste delal dlouhe hodiny, ve vetsim projektu klidne dny, zatimco poradne IDE by je melo hotove za par vetrin ;D.
Pokud se mění požadavky během vývoje, tak jen dopíši chybějící třídy, případně staré vyměním za nové, ale architekturu aplikace neměním.
Nemusi se menit cela architektura, staci hloupe upravy v interfacu, prave treba ty zminene presuny parametru v metode napric vsemi implementacemi, ale i trivialni prejmenovani metody rozhrani ve vsech implementacich (ne nahrazeni textu "update" za "updateUser", protoze to pochopitelne rozbije vsechny metody v projektu pojmenovane "update", ne jen ty, ktere implementuji dane rozhrani nebo dedi).
Upripmne, cim vic pisete, tim vice mam pocit, ze se realnym vyvojem moc nezabyvate a spise delate male write-only one-man-show veci, kde to, co popisujete, asi muze fungovat.
K tematu - planuji si poridit 4k kvuli praci, myslite, ze na to os/aplikace jeste nejsou pripravene (jde mi o widle 10 tak i o tucnaka)?
Velka ramka muze byt pouzita i jako ramdisk, pokud v nejake aplikaci je ssd pomale.
Pamet 4GB je naproste minimum, i s tim se bude v Jave vyvijet nepohodlne. 2GB budou sotva stacit na OS a prohlizec. Poradne IDE si napr. cachuje vsechny objekty v projektu, takze lze rychle navigovat a vyhledavat, o cem doufam nikdo nepochybuje, ze produktivitu zvysuje - samozrejme za cenu pameti, ale to uz jsem napsal nekolikrat, ze ta investice tisicovky do 8GB se brzy vrati. Osobne doporucuji tech 16GB a vic, protoze nikdy nevite, kdy bude potreba pustit virtualku, dalsi instanci aplikaci, dalsi prohlizec, dalsi instanci IDE se souvisejicim projektem atp.
-
Co bych měl povídat? Ukaž mi třeba na GitHubu aplikaci v Javě, která je napsána objektově. Většina z toho má do OOP hodně daleko.
Osobně bych spíš uvítal nějakou repository s kvalitním php kódem. Čistě pro studijní účely.
Takových je málo, neboť PHP objektové programování nijak nevnucuje (Java ostatně také ne). Mnoho programátorů jednoduše napíše pár špaget s tím, že je to dobrý. Aspoň se nesnaží dělat gettery/settery. Dokud není potřebný redesign, tak kvalita kódu v PHP dohromady nikoho nezajímá.
-
Co bych měl povídat? Ukaž mi třeba na GitHubu aplikaci v Javě, která je napsána objektově. Většina z toho má do OOP hodně daleko.
Osobně bych spíš uvítal nějakou repository s kvalitním php kódem. Čistě pro studijní účely.
Takových je málo, neboť PHP objektové programování nijak nevnucuje (Java ostatně také ne). Mnoho programátorů jednoduše napíše pár špaget s tím, že je to dobrý. Aspoň se nesnaží dělat gettery/settery. Dokud není potřebný redesign, tak kvalita kódu v PHP dohromady nikoho nezajímá.
Takze getry uz dneska byly...
-
Na vývoj v javě jsem si pořídil http://www.importpc.cz/dell-precision-m4600-01-b-g4dtwl1.html Nechal jsem si tam dát SSD a rozšířit RAM na 16GB.
Výkon CPU jsem porovnával na http://www.cpubenchmark.net/CPU_mega_page.html - určitě se vyplatí se podívat, jaký výkon který typ procesoru přesně dává. Pro orientaci v procesorech jsem ještě nahlížel do https://en.wikipedia.org/wiki/Intel_Core
Reálný výkon odpovídá očekávání a testům na cpubenchmark. V biosu je potřeba mít povolené hyperthreading, bez něj jde výkon rapidně dolů. V linuxu pak vidím 8 jader (místo 4 fyzických bez hyperthreadingu). Paměť zaplním celou jen zřídka. S vyšším rozpočtem by šlo jít s výkonem nahoru, ale v praxi je i stávající konfigurace použitelná. Používám IntelliJ IDEA a Eclipse, Tomcat, aplikace v BrightspotCMS nebo Playframework, HIbernate, Spring, Javalite. Občas spouštím ve virtuálu i Windows pro otestování komunikace s Windows softwarem. Výdrž notebooku bez sítě je kolem 4h, většinu doby pracuju ale s napájením ze sítě.
Tolik zpráva z praxe :-)
-
Takových je málo, neboť PHP objektové programování nijak nevnucuje (Java ostatně také ne). Mnoho programátorů jednoduše napíše pár špaget s tím, že je to dobrý. Aspoň se nesnaží dělat gettery/settery. Dokud není potřebný redesign, tak kvalita kódu v PHP dohromady nikoho nezajímá.
Takže je na tom PHP vlastně stejně jako Java? Už delší dobu jsem hledal nějaký materiál kde je použití PHP promyšlené a pořád se mi to nedaří. Všechno je to jenom špagetový balast.
-
Takových je málo, neboť PHP objektové programování nijak nevnucuje (Java ostatně také ne). Mnoho programátorů jednoduše napíše pár špaget s tím, že je to dobrý. Aspoň se nesnaží dělat gettery/settery. Dokud není potřebný redesign, tak kvalita kódu v PHP dohromady nikoho nezajímá.
Takze getry uz dneska byly...
Sláva. Tušil jsem, že se nějaký troll na mé gettery chytí.
-
Takových je málo, neboť PHP objektové programování nijak nevnucuje (Java ostatně také ne). Mnoho programátorů jednoduše napíše pár špaget s tím, že je to dobrý. Aspoň se nesnaží dělat gettery/settery. Dokud není potřebný redesign, tak kvalita kódu v PHP dohromady nikoho nezajímá.
Takže je na tom PHP vlastně stejně jako Java? Už delší dobu jsem hledal nějaký materiál kde je použití PHP promyšlené a pořád se mi to nedaří. Všechno je to jenom špagetový balast.
Jistě, prasit se dá v každém jazyce, PHP nevyjímaje. Jsem také znechucen těmi hromadami špagetového balastu v PHP stejně jako v Javě a dalších jazycích.
-
na javu 16gb
pustite si ide
pustite si mysql
pustite si tomcat
pustite si nejaky nosql
a mate po ramke
---
Jistě, prasit se dá v každém jazyce, PHP nevyjímaje
toto je jubilejny 30 thread kde masturbujete nad negettrami a kde odmietate ukazat nejaky svoj projekt
-
Jistě, prasit se dá v každém jazyce, PHP nevyjímaje
toto je jubilejny 30 thread kde masturbujete nad negettrami a kde odmietate ukazat nejaky svoj projekt
Druhý...
-
Jistě, prasit se dá v každém jazyce, PHP nevyjímaje
toto je jubilejny 30 thread kde masturbujete nad negettrami a kde odmietate ukazat nejaky svoj projekt
Druhý...
Když někdo plácne svou oblíbenou hovadinu a pak se diví, že to někdo čte (moje chyba, uznávám) a poznamená, že je dnes Kit už má hotovo.
-
Když někdo plácne svou oblíbenou hovadinu a pak se diví, že to někdo čte (moje chyba, uznávám) a poznamená, že je dnes Kit už má hotovo.
Jsem rád, když někdo mé příspěvky čte. Ještě jsem raději, když ně něko reaguje.
Stejně je s podivem, že mé antigettery fungují jako bezvadný spouštěč místních trollů.
-
Když někdo plácne svou oblíbenou hovadinu a pak se diví, že to někdo čte (moje chyba, uznávám) a poznamená, že je dnes Kit už má hotovo.
Jsem rád, když někdo mé příspěvky čte. Ještě jsem raději, když ně něko reaguje.
Stejně je s podivem, že mé antigettery fungují jako bezvadný spouštěč místních trollů.
Tomu tradicne nerozumis. To neni spousteni trolovani, to je trolovani.
-
Když někdo plácne svou oblíbenou hovadinu a pak se diví, že to někdo čte (moje chyba, uznávám) a poznamená, že je dnes Kit už má hotovo.
Jsem rád, když někdo mé příspěvky čte. Ještě jsem raději, když ně něko reaguje.
Stejně je s podivem, že mé antigettery fungují jako bezvadný spouštěč místních trollů.
Tomu tradicne nerozumis. To neni spousteni trolovani, to je trolovani.
Pokud jsi přesvědčen, že jsem troll, tak proč mě krmíš?
-
Pokud jsi přesvědčen, že jsem troll, tak proč mě krmíš?
Protoze tu casto placas nesmysly a neni dobre je nechat jen tak, aby se toho nejaky junior nechytil
-
Pokud jsi přesvědčen, že jsem troll, tak proč mě krmíš?
Protoze tu casto placas nesmysly a neni dobre je nechat jen tak, aby se toho nejaky junior nechytil
Ukaž mi jediný svůj příspěvek v této debatě, který je k věci.
-
Pokud jsi přesvědčen, že jsem troll, tak proč mě krmíš?
Protoze tu casto placas nesmysly a neni dobre je nechat jen tak, aby se toho nejaky junior nechytil
Ukaž mi jediný svůj příspěvek v této debatě, který je k věci.
Uplne jsem zapomnel, ze tu radis s notebookem.
Fakt zacinam byt unaveny z toho, jak chlapci, co ani nepoznaji datovou strukturu od kusu kodu, prudej a vsude sirej porad dokolaty same nedopochopene poucky.
-
for the record, na otazku aky notebook pre javu
- Mám 2GB RAM a také v pohodě.
nabuduce na otazku "cim hnojit vinice" odpovie "na kytky mam vodu a take v pohode, kytky jsou lepsi nez vinice"
-
for the record, na otazku aky notebook pre javu
- Mám 2GB RAM a také v pohodě.
nabuduce na otazku "cim hnojit vinice" odpovie "na kytky mam vodu a take v pohode, kytky jsou lepsi nez vinice"
Vida, našel jsi to, ale svůj názor jsi nenapsal. Určitě potřebuješ té RAM minimálně 8× tolik.
-
Vida, našel jsi to, ale svůj názor jsi nenapsal. Určitě potřebuješ té RAM minimálně 8× tolik.
http://forum.root.cz/index.php?action=post;topic=13938.105;last_msg=180419#postmodify
bezny java vyvoj nie je ako vas endemit kde si pod "vyvijam v jave" predstavujete spustenie vim, hello world, zmazanie getterov a setterov, a zistenie ze to funguje o 100 ms pomalsie a odidete si k php
vasa rada s 2gb v tejto teme je hovadina
vyhrali ste vsak preteky v "spustil som javu na najmensom pocte gigabajtov v tomto threade".
-
Pokud není potřeba při vývoji mobilita, dávám vždy přednost desktopu. Jasně, že kdo potřebuje pendlovat a vyvíjet na více místech, musí mít ntb. To naštěstí není náš případ.
Můj soukromý pohled na věc vývojáře a současně toho, kdo vývoj platí: hw je levný, čas/lidi jsou drazí. Pokud HW ušetří čas, vždy se vyplatí.
Vyvíjíme/provozujeme sadu databázových a zpravodajských webů, server v javě. Paměť na vývojářské stanici je potřeba pro:
* několik oken prohlížeče při googlování aktuálních otázek - téměř pořád otevřené
* několik oken prohlížeče pro zobrazení vyvíjených funkcí - často několik různých prohlížečů pro přepínání mezi různými přihlášenými uživateli
* obvykle jeden spuštěný virtuál s win kvůli základnímu zkouknutí v IE
* IDE (idea) pro vývoj serveru
* pro vývoj androidího klienta (webaplikace) - Android studio (tedy idea) na další ploše
* mail klient pro komunikaci ve firmě
* spuštěná db s čerstvými ostrými (obfuskovanými) daty (100GB mysql)
* terminály se sešnami na CI/ostatní servery - to už nic nezabere
Rychle se zaplní prvních 30GB, zbylých 30 - 40GB se někdy využije komplet, někdy jen částečně (včetně diskových keší kernelu). Určitě se hodí při občasné analýze dumpu z ostrého serveru, kde má java přiděleno dost paměti.
Pro efektivitu potřebuji, aby spuštění celé aplikace při ladění v IDE trvalo řádově sekundy, ne minuty. Máme 8 xeon jader (2 x quad), ale 4 by asi taky stačily.
SSD považuji pro vývojáře, který se tím živí, za samozřejmost. Používáme dva (systém, db), ale stíhal by to i 1 větší.
Monitory jsou dnes rovněž levné, každý prostor navíc omezující přepínání oken urychluje a usnadňuje práci. Centrální monitor na editor (nejlépe dostatečně velký na plnohodnotné zobrazení dvou panelů editoru vedle sebe - velice užitečné). Jeden boční monitor na pomocné panely IDE (structure, project, git, verzování, Find, atd.). Druhý boční monitor na prohlížeč se zobrazeným výsledkem.
Díky dostatku paměti se nikdy ani při největším zatížení nestane, že by vývojář musel čekat, až se něco odswapne, okna naskakují stejně rychle, jako při nulové zátěži.
Celý setup se ani nepřiblízí jednoměsíčním nákladům na jeho uživatele - vývojáře a zaplatí se do pár měsíců, o tom jsem přesvědčený. HW je náš každodenní pracovní nástroj a nemá smysl při dnešních cenách trávit drahocený čas čekáním/přepínáním oken.
2GB si vezme skoro jen prohlížeč s pár otevřenými okny/taby....
Bohužel jsem nepřispěl k diskusi o ntb, ale třeba tazatel zjistí, že jej pro vývoj nepotřebuje a použije desktop.
-
vyhrali ste vsak preteky v "spustil som javu na najmensom pocte gigabajtov v tomto threade".
Mýlíš se. Nikoli gigabajů, ale megabajtů. Už jsem napsal a odladil javovský program i na 256 MB RAM. Dodnes spolehlivě funguje.
-
vyhrali ste vsak preteky v "spustil som javu na najmensom pocte gigabajtov v tomto threade".
S leJOSem jsem spouštěl javu na EV3 s 64 MB RAM, akorát teda jen JRE, ne JDK.
-
A leJOS NXJ se svojí vlastní JVM funguje i na 64 KB RAM a 256 KB Flash.
-
Java Card nekdo?
Ne ze by to nejak tazateli pomohlo, samozrejme...
-
Mýlíš se. Nikoli gigabajů, ale megabajtů. Už jsem napsal a odladil javovský program i na 256 MB RAM. Dodnes spolehlivě funguje.
ak ste to napisali v roku 2003 tak blahozelam
ak ste to napisali v roku 2016 tak uz som blahozelal.
za tie peniaze co ste si usetrili na ramke si verim kupite veyron
-
@dustin: Hezke shrnuti. Jak velke jsou ty monitory a jake maji rozliseni?
Co se tyce tech 3 monitoru tak teda nevim, jestli to neni uz moc. Nekde jsem videl studii, ze pri prechodu 1->2 monitory se produktivita zvysila, naopak ale pri prechodu 2->3 monitory poklesla. Podobne negativne produktivitu ovlivnila prilis velka uhlopricka (myslim >24).
-
Java Card nekdo?
Ne ze by to nejak tazateli pomohlo, samozrejme...
The minimum system requirement is 16 kilobytes of read-only memory (ROM), 8 kilobytes of EEPROM, and 256 bytes of random access memory (RAM).
To je ještě lepší! :D
-
Pro efektivitu potřebuji, aby spuštění celé aplikace při ladění v IDE trvalo řádově sekundy, ne minuty. Máme 8 xeon jader (2 x quad), ale 4 by asi taky stačily.
Konečně někdo, kdo to s vývojem myslí vážně. Je to jak píšeš. Ale s tím mě napadá otázka, které je těžkou zodpovědět bez reálných testů. Myslíš, že je lepší Xeon s více jádry, více cache paměti a menší taktem a nebo i7 s vyšším taktem může být na Javu stejné? Bych nerad pořídil na takové to domácí vyvíjení Xeon za 30 a byl by stejný jako i7 za půlku :D
-
O Java Card slysim prvne, zajimave.
Specifically, the Java Card does not support:
...
* Large primitive data types (float, double, long, and char)
Neni ale tohle problem? (Hm, proc je char brany jako large?)
-
@dustin: Hezke shrnuti. Jak velke jsou ty monitory a jake maji rozliseni?
Co se tyce tech 3 monitoru tak teda nevim, jestli to neni uz moc. Nekde jsem videl studii, ze pri prechodu 1->2 monitory se produktivita zvysila, naopak ale pri prechodu 2->3 monitory poklesla. Podobne negativne produktivitu ovlivnila prilis velka uhlopricka (myslim >24).
Ty testy jsou píčoviny. Na Javu potřebuješ alespoň 32"+ 1440p+ a nebo více monitorů. Kdo dneska nedělá něco, co je vidět v prohlížeči? A kam ho nacpeš?
-
[...]Avsak linux je na notebooku nepouzitelny v pripade, ze ho chces pouzivat aj na osobne veci a nie iba cisto na pracu.[...]
to je problem pro tebe (mozna ses gambler), normalni clovek ani na osobni veci nema s Linuxem problem... ;)
-
patologický hráč, pociťuje velmi silné nutkání ke hře, které lze těžko ovládnout, toto často doprovází myšlenky s představami hraní.
-
vyhrali ste vsak preteky v "spustil som javu na najmensom pocte gigabajtov v tomto threade".
S leJOSem jsem spouštěl javu na EV3 s 64 MB RAM, akorát teda jen JRE, ne JDK.
A leJOS NXJ se svojí vlastní JVM funguje i na 64 KB RAM a 256 KB Flash.
Doufal jsem, že mě trumfneš, i když jen s JRE. Zkusím učesat to tvé řešení dle mých zvyklostí, abys viděl, jak si OOP představuji. I když s roboty to možná bude trochu jiné, tam se asi hodně dělá ve statice, které se vyhýbám.
-
[...]Avsak linux je na notebooku nepouzitelny v pripade, ze ho chces pouzivat aj na osobne veci a nie iba cisto na pracu.[...]
to je problem pro tebe (mozna ses gambler), normalni clovek ani na osobni veci nema s Linuxem problem... ;)
To jako ze si nemuze pustit online automaty v prohlizeci pod Linuxem? Snad flash uz davno neni problem a ted se dost prechazi na ciste JS reseni. Nespletl sis pojmy?
gambler != gamer ;)
K tomu "normalni", napr. v ameru jsou hraci na 42% (deti do 17 let na 91%), takze tam uz to je zcela normalni byt hrac. U nas netusim, my jsme vecne pozadu, ale verim, ze i tady se to obrati.
-
Nespletl sis pojmy?
nespletl ;) zavislost na hrach je zavislot na hrach, pokud nekdo pouziva Windows aby mohl hrat hry ktere jsou dostupne jen pro Windows a povazuje to za svoji osobni potrebu a nepouzitelnost Linuxu je to zavislak na hrach, nic vic nic min...
otazka co povazujes za normalni, jestli pocitas prevahu nebo pouzijes selskej rozum...
-
@dustin: Jak velke jsou ty monitory a jake maji rozliseni?
Základním požadavkem pro mě bylo umožnit provoz dvou panelů editoru v plnohodnotné šířce vedle sebe. Z toho mi vyšlo QHD 2560x1440. 27" měla příliš hustý pitch a stejně se musely zvětšit fonty, takže se tam dva panely pro mě nevešly. Takže 32". Tomu pitchem odpovídá 24" Full HD po stranách - stejný pitch, aby seděly linie všech tří monitorů na sebe.
Kolegovi ty velké rozměry centrálního nevyhovují, tak zvolil 27" FullHD (to 27" WQHD má opravdu moc malé fonty) a tomu relativně odpovídající 2 x 22" 1680x1050. Pořád mu nabízím větší, ale nechce, což chápu.
Dva monitory mi nevyšly ergonomicky uspořádat. Chci velký centrální, kde píšu, napřímo před sebou, nechci být při psaní pořád natočený na jednu polovinu. Na ten centrální se na šířku už žádné panely nevejdou, takže šly na levý monitor. Debug/watch je dole na centrálním, protože je potřeba mít v zorném poli zdroják s kurzorem běhu a aktuální hodnoty. Tam by se hodil monitor ještě o kus vyšší, takhle si při psaní musím skrývat dolní debug panely (naštěstí je to jedna zkratka). Idea si rozložení panelů po uložení pamatuje, takže najede vždycky stejně.
IMO je tohle lepší než 40+" 4k, protože je to do oblouku (odlesky, změna jasu/barev) a tříhlavá grafika na to vyjde na 1100 Kč. I když, o kousek vyšší ten centrální by se hodil, to rozhodně.
-
To, ze nekdo racionalne zvoli OS, protoze umoznuje provozovat cinnost, ktera ho bavi, neznamena, ze je na te cinnosti nezdrave zavisly (viz citace od javaman). Takze budto iwtu dobre znas, ze muzes tvrdit, ze je nezdrave zavisly na hrani (z tvrzeni, ze hraje hry, nevyplyva, ze je na nich zavisly), nebo, coz je pravdepodobnejsi, ad hominem.
Podle tve logiky bych mohl rict, ze nobody je nezdrave zavisly na pocitaci (pripadne i na Linuxu samotnem), protoze pouziva pocitac s Linuxem ;). Takovou logiku za normalni nepovazuju.
PS: Selskym rozumem bych prave rekl, ze je to normalni (bezne), hrat. Stejne, jako je normalni sportovat, cist nebo hackovat. Ostatne vetsina hracu jsou dospeli lide, ne deti, jak casto zpatecnici/ignoranti tvrdi. Stejne tak vetsina video her je cilena na starsi publikum (logicky).
-
Pro efektivitu potřebuji, aby spuštění celé aplikace při ladění v IDE trvalo řádově sekundy, ne minuty. Máme 8 xeon jader (2 x quad), ale 4 by asi taky stačily.
Konečně někdo, kdo to s vývojem myslí vážně. Je to jak píšeš. Ale s tím mě napadá otázka, které je těžkou zodpovědět bez reálných testů. Myslíš, že je lepší Xeon s více jádry, více cache paměti a menší taktem a nebo i7 s vyšším taktem může být na Javu stejné? Bych nerad pořídil na takové to domácí vyvíjení Xeon za 30 a byl by stejný jako i7 za půlku :D
Pro desktop bývá výhodnější i7.
-
Pro efektivitu potřebuji, aby spuštění celé aplikace při ladění v IDE trvalo řádově sekundy, ne minuty. Máme 8 xeon jader (2 x quad), ale 4 by asi taky stačily.
Konečně někdo, kdo to s vývojem myslí vážně. Je to jak píšeš. Ale s tím mě napadá otázka, které je těžkou zodpovědět bez reálných testů. Myslíš, že je lepší Xeon s více jádry, více cache paměti a menší taktem a nebo i7 s vyšším taktem může být na Javu stejné? Bych nerad pořídil na takové to domácí vyvíjení Xeon za 30 a byl by stejný jako i7 za půlku :D
Pro desktop bývá výhodnější i7.
Myslím normální stanici na vývoj. Takže tam běží třeba 20 serverů, build by měl být rychlý a normální práce také. Myslím, že i7 by měla být lepší, ale zase větší cache dřív bývala vždy výhoda. Dnešní architektura je ale trochu jiná. Všude v práci jsem míval i7, což je v pohodě, ale Xeon láká.
-
Myslíš, že je lepší Xeon s více jádry, více cache paměti a menší taktem a nebo i7 s vyšším taktem může být na Javu stejné? Bych nerad pořídil na takové to domácí vyvíjení Xeon za 30 a byl by stejný jako i7 za půlku :D
IMO je od nějakých 4 jader lepší vyšší rychlost než počet jader. V panelu mám applet vytížení CPUs a nad 4 jádra to vyleze jen při kompilaci/spouštění (to si pak vezme všech 8). Ale bohužel zatím moc nepoužíváme stream().parallel a podobné, abychom vytížili ostatní jádra. Na produkčním serveru máme 32 jader a taky se to fláká. Jen při startu aplikace to na nějakých 25 jader jede...
Už roky kupujeme značkové repasy, máme s tím výborné zkušenosti z pohledu cena/výkon/spolehlivost. Celý ten setup (Dell T5500 2x X5570 repasy z DE, 72GB DDR3-1333 ECC RAM used GB, Čína, 32" z alzy nový rozbalený, 2x fullhd s perfektními masivními nastavitelnými stojany mají teď všichni prodejci repasů za 2k, grafika 1100 Kč alza, 2x SSD nový) vyjde tak na cca 30k Kč bez DPH.
Záruky neřeším, nedávno se u nás Dellu v rámci NBD Pro po sedmi návštěvách technika a šesti vyměněných základních deskách podařilo za měsíc vrátit serverovou workstation R7610 hlásící v linuxu stovky EDAC errorů za sekundu do původního stavu, v jakém jsem tu závadu nahlásil. Server konečně bootuje (technici netušili, jak přinesené vymazané desky správně nakonfigurovat - ten relativně nestandardní stroj z nich dle jejich slov žádný nikdy neměl v ruce), vidí všechny DIMMy (jedna z přinesených desek měla vadný slot), chladiče pasují na desku (jedna z přinesených desek měla větší matice na chladiče) a jaderný modul EDACu je stejně jako na začátku zakázaný, ale se neulogoval k smrti. Nikdo z Dellu vůbec netušil, co s tím. Když jsme objevili, jak zprovoznit bootování na těch deskách a chtěl jsem po technickém servisu Dellu, aby to napsali servisákům do nějaké knowledge base pro příště, tak následný technik vůbec o ničem nevěděl a musel jsem mu to ukázat, co s tím má dělat. Takže místo záruky máme náhradní stanici ve skladu, nějaké sliby záruky mě vůbec nezajímají.
-
Pro desktop bývá výhodnější i7.
Myslím normální stanici na vývoj. Takže tam běží třeba 20 serverů, build by měl být rychlý a normální práce také. Myslím, že i7 by měla být lepší, ale zase větší cache dřív bývala vždy výhoda. Dnešní architektura je ale trochu jiná. Všude v práci jsem míval i7, což je v pohodě, ale Xeon láká.
Pokud hodláš Xeon využívat sólo, tak jsou to vyhozené peníze.
Xeon má význam až ve dvojici či ve čtveřici, protože pak se ty procesory začnou chovat jako jeden mnohojádrový procesor. Toho s i7 nedocílíš.
Dělal jsem na obojím - 4× Xeon i 1× i7. Jednovláknová javovská aplikace běžela na i7 mnohem lépe - síla Xeonu je v meziprocesorové komunikaci. Naproti tomu se i7 na dálku konfiguruje docela blbě, ale to není tvůj problém.
-
Myslíš, že je lepší Xeon s více jádry, více cache paměti a menší taktem a nebo i7 s vyšším taktem může být na Javu stejné? Bych nerad pořídil na takové to domácí vyvíjení Xeon za 30 a byl by stejný jako i7 za půlku :D
IMO je od nějakých 4 jader lepší vyšší rychlost než počet jader. V panelu mám applet vytížení CPUs a nad 4 jádra to vyleze jen při kompilaci/spouštění (to si pak vezme všech 8). Ale bohužel zatím moc nepoužíváme stream().parallel a podobné, abychom vytížili ostatní jádra. Na produkčním serveru máme 32 jader a taky se to fláká. Jen při startu aplikace to na nějakých 25 jader jede...
...
Super, dík za info. Právě aplikace píšu vždy dost paralelní a build je také paralelní, tak si říkám, jestli třeba 10 jader s menším taktem to netrumfne, ale nevím. Zase by to bylo dobré na testování.
Pro desktop bývá výhodnější i7.
Myslím normální stanici na vývoj. Takže tam běží třeba 20 serverů, build by měl být rychlý a normální práce také. Myslím, že i7 by měla být lepší, ale zase větší cache dřív bývala vždy výhoda. Dnešní architektura je ale trochu jiná. Všude v práci jsem míval i7, což je v pohodě, ale Xeon láká.
Pokud hodláš Xeon využívat sólo, tak jsou to vyhozené peníze.
Xeon má význam až ve dvojici či ve čtveřici, protože pak se ty procesory začnou chovat jako jeden mnohojádrový procesor. Toho s i7 nedocílíš.
Dělal jsem na obojím - 4× Xeon i 1× i7. Jednovláknová javovská aplikace běžela na i7 mnohem lépe - síla Xeonu je v meziprocesorové komunikaci. Naproti tomu se i7 na dálku konfiguruje docela blbě, ale to není tvůj problém.
Ale jednovláknové aplikace nikdo nepoužívá. Právě protože se používá masivní paralelizace, tak by Xeon mohl mít výhodu.
-
Ale jednovláknové aplikace nikdo nepoužívá. Právě protože se používá masivní paralelizace, tak by Xeon mohl mít výhodu.
:D :D :D To bys musel vysvětlit tomu autorovi aplikace, který na nějakou masivní paralelizaci zvysoka ...
-
Xeon neni jenom poctu jader (i u i7 se da dostat 10C/20T) ale i to takovych tech nezajimavych zkratkach jako je ECC.
(btw: existuji i Xeony pro notebooky odvozene od Skylake H)
-
Ale jednovláknové aplikace nikdo nepoužívá. Právě protože se používá masivní paralelizace, tak by Xeon mohl mít výhodu.
:D :D :D To bys musel vysvětlit tomu autorovi aplikace, který na nějakou masivní paralelizaci zvysoka ...
Napriklad vim az do minuleho mesice, ze?
-
Ale jednovláknové aplikace nikdo nepoužívá. Právě protože se používá masivní paralelizace, tak by Xeon mohl mít výhodu.
:D :D :D To bys musel vysvětlit tomu autorovi aplikace, který na nějakou masivní paralelizaci zvysoka ...
Napriklad vim az do minuleho mesice, ze?
Zase provokuješ, co? Pokud vím, tak Vim jede jen v jednom vláknu a stačí to.
-
Zase provokuješ, co? Pokud vím, tak Vim jede jen v jednom vláknu a stačí to.
To jen protoze jsi jim zatim neukazal ten jediny spravny objektovy pristup s kvalitnim navrhem a nevyhazel getry a setry.
-
Zase provokuješ, co? Pokud vím, tak Vim jede jen v jednom vláknu a stačí to.
To jen protoze jsi jim zatim neukazal ten jediny spravny objektovy pristup s kvalitnim navrhem a nevyhazel getry a setry.
Ukazoval jsem to na fóru několikrát. Akorát jsem se setkal s nepochopením.
-
Zase provokuješ, co? Pokud vím, tak Vim jede jen v jednom vláknu a stačí to.
Ve vimu to uz castecne fixnuli. (predtim to fixnul uz neovim)
-
Zase provokuješ, co? Pokud vím, tak Vim jede jen v jednom vláknu a stačí to.
Ve vimu to uz castecne fixnuli. (predtim to fixnul uz neovim)
AFAIK jen přidali možnost asynchronní komunikace s podprocesem.
-
Určitě, DB to zabila :D
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/ (http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/)
Tím, že někdo udělá test na nějaké cykly, jasně upřednostní imperativní jazyky, jakým je např. Java. Vsadil bych se, že v testu nebyl použit ani jeden objekt, proto jsou ty výsledky zcela nesmyslné.
Přesně. Chudák objektový Bash, vůbec se nedostal ke svému :D
Ono se to moc nevi, a vlastne se neni cemu divit, ale on "existuje" i OOP bash:
http://hipersayanx.blogspot.cz/2012/12/object-oriented-programming-in-bash.html
Mimochodem, povedlo se celkem vtipne overeni tohoto prispevku:
https://postimg.org/image/8wseux7bn/
-
Zase provokuješ, co? Pokud vím, tak Vim jede jen v jednom vláknu a stačí to.
Ve vimu to uz castecne fixnuli. (predtim to fixnul uz neovim)
AFAIK jen přidali možnost asynchronní komunikace s podprocesem.
Tak, tak.