AMD CPU pro Javu

[anonym]

Mě notebooky nijak nezajímají, takže je mi to jedno. Ale pokud ten procák bere půlku stolního, tak prostě výkon nebude stejný. Hlavně se bavíme o běžných procesorech, do stanic se dávají daleko lepší. Já bych rád zkusil Ryzen, ale zatím nevím, jestli si pomůžu. Nechceš zkusit ten Spring? Build mi občas dojede a občas ne, ale test vždy. Další varianta je pustit dva najednou, což bude blíž běžné práci.

¨
Tak si kup starší AMD co žralo 300W, to musí být performance jako prase. Nevymýšlej s příkonem a podívej se na benchmarky. Jsou to porstě stejné procáky. Příkon roste exponenciálně s taktem. Dostaneš z desktopu v reálu 20% lepší perfromance pro kompilace, více ne.

[Reklama]

reklama

[anonym]

Spring je dobrý do korporátních zašíváren, kde pustíš build a jdeš na kafe. Mě se teď docela zalíbilo Node.js, na Spring už doma seru z vysoka, je to ztráta času, ty javovské frameworky jsou pomalu startující mrdky.

[Youda]

Ohledne testovani spring buildem, jestli tohle ma neco o necem vypovidat, tak nejspis o vykonu SSD disku a pameti.

Apropos, pokud se ti prace s Jawou zda pomala, jako prvni pokus bych zkusil reorganizovat format projektu.

Ted delam na macate webaplikaci  s primefaces (vysledek je 70MB fat JAR) a spring boot mi komplet startuje 8 sekund na obstaroznim Lenovo T430 z roku 2012.

Obecne v pripade Springu by nemel byt problem si vytvorit lehke vyvojove prostredi.
Pripadne jRebel, mozna postaci i hotswap.

[anonym]

A taky mě už nebaví srát se s 10 let starým blokující designem Javovských knihoven, ti sráči a darmožrouti z Oraclu co teprve v roce 2018 začali dělat neblokující obdobu JDBC mě už dlouho srát nebudou. Nemluvě o Servlet API, které je totální 20 let starý výsměch všem programátorům. Fuj a hnůj. V Node.js je budoucnost, bude to první smysluplná multiplatforma, ještě se to v Google trochu potuní a je to.

[Youda]

Spring je dobrý do korporátních zašíváren, kde pustíš build a jdeš na kafe. Mě se teď docela zalíbilo Node.js, na Spring už doma seru z vysoka, je to ztráta času, ty javovské frameworky jsou pomalu startující mrdky.

Je tu rec o tom, Node.js, jehoz autor se na nej uz vys*al a presel na Go?
A je tu rec o Springu, ktery v predzvykanem Spring Bootu nahazuje pod 10 sekund?

[Reklama]

reklama

[anonym]

Ohledne testovani spring buildem, jestli tohle ma neco o necem vypovidat, tak nejspis o vykonu SSD disku a pameti.

Apropos, pokud se ti prace s Jawou zda pomala, jako prvni pokus bych zkusil reorganizovat format projektu.

Ted delam na macate webaplikaci  s primefaces (vysledek je 70MB fat JAR) a spring boot mi komplet startuje 8 sekund na obstaroznim Lenovo T430 z roku 2012.

Obecne v pripade Springu by nemel byt problem si vytvorit lehke vyvojove prostredi.
Pripadne jRebel, mozna postaci i hotswap.

Jak uděláš lehké vývojeové prostředí, když jenom Jersey ti přidá 3 vteřiny k inicializaci? A když nepoužiješ tu, tak co místo ni na REST? Tam nic jiného není. Už jen embedded Jetty přidá ke startu 1 vteřinu. V Node.js zmáčku run a jedu. Je to mnohem lepší na ne-macaté aplikace, na doma.

[užnestudent]

Ohledne testovani spring buildem, jestli tohle ma neco o necem vypovidat, tak nejspis o vykonu SSD disku a pameti.

Apropos, pokud se ti prace s Jawou zda pomala, jako prvni pokus bych zkusil reorganizovat format projektu.

Ted delam na macate webaplikaci  s primefaces (vysledek je 70MB fat JAR) a spring boot mi komplet startuje 8 sekund na obstaroznim Lenovo T430 z roku 2012.

Obecne v pripade Springu by nemel byt problem si vytvorit lehke vyvojove prostredi.
Pripadne jRebel, mozna postaci i hotswap.

Normální projekty jsou závislé na procesoru, ale nevím, který vybrat z těch OSS, který se lehce staví.

Práce s Javou je vždy pomalá, proto na ní testuju CPU. Nemusím pak dělat Javu, ale jako test pro CPU programátora je to fajn.

Mě nezajímá ani moc start, protože potřebuju spíš build a Docker dohromady. To by AMD mohlo dávat s přehledem.

Nepotřebuju ani lehké vývojové prostředí, protože mám těžké prostředí a vyhovuje mi. Potřebuju ale vybrat dobrý CPU pro to

[anonym]

Spring je dobrý do korporátních zašíváren, kde pustíš build a jdeš na kafe. Mě se teď docela zalíbilo Node.js, na Spring už doma seru z vysoka, je to ztráta času, ty javovské frameworky jsou pomalu startující mrdky.

Je tu rec o tom, Node.js, jehoz autor se na nej uz vys*al a presel na Go?
A je tu rec o Springu, ktery v predzvykanem Spring Bootu nahazuje pod 10 sekund?

Zdroj?

Kazdopadne me se Go libi, ale vetsi vyhodnejsi pro me na doma je, kdyz mam jeden jazyk. On ten Javascript na male veci neni tak spatny a na vetsi veci se da pouzit Babel, ktery umi i classy, importy a dokonce i nejake typechecky.

Ovladat dobre Javu, ktera me zivi, k tomu Javascript a jeste k to Go, to uz je na moje mozkove zavity prilis. Jo jeste C#, ten jsem taky jeste nezapomel.

[mmm]

On ten Javascript na male veci neni tak spatny a na vetsi veci se da pouzit Babel, ktery umi i classy, importy a dokonce i nejake typechecky.

trochu jste ohledně javascriptu zaspal dobu. Už jsem si toho všiml v jiné diskuzi. Snad vás tu nikdo nebere vážně.

[Youda]

Spring je dobrý do korporátních zašíváren, kde pustíš build a jdeš na kafe. Mě se teď docela zalíbilo Node.js, na Spring už doma seru z vysoka, je to ztráta času, ty javovské frameworky jsou pomalu startující mrdky.

Je tu rec o tom, Node.js, jehoz autor se na nej uz vys*al a presel na Go?
A je tu rec o Springu, ktery v predzvykanem Spring Bootu nahazuje pod 10 sekund?

Zdroj?

Kazdopadne me se Go libi, ale vetsi vyhodnejsi pro me na doma je, kdyz mam jeden jazyk. On ten Javascript na male veci neni tak spatny a na vetsi veci se da pouzit Babel, ktery umi i classy, importy a dokonce i nejake typechecky.

Ovladat dobre Javu, ktera me zivi, k tomu Javascript a jeste k to Go, to uz je na moje mozkove zavity prilis. Jo jeste C#, ten jsem taky jeste nezapomel.

Tak situace se meni kazdym tydnem.
Minuly rok se Ryan Dahl vysral na Node.js, ze prechazi na Go.
A ted rozjel novy projekt "deno", ktery ma byt obdobou Node.js, ale postaveny na TypeScriptu a Rustu.
https://github.com/denoland/deno

[Youda]

Ohledne testovani spring buildem, jestli tohle ma neco o necem vypovidat, tak nejspis o vykonu SSD disku a pameti.

Apropos, pokud se ti prace s Jawou zda pomala, jako prvni pokus bych zkusil reorganizovat format projektu.

Ted delam na macate webaplikaci  s primefaces (vysledek je 70MB fat JAR) a spring boot mi komplet startuje 8 sekund na obstaroznim Lenovo T430 z roku 2012.

Obecne v pripade Springu by nemel byt problem si vytvorit lehke vyvojove prostredi.
Pripadne jRebel, mozna postaci i hotswap.

Normální projekty jsou závislé na procesoru, ale nevím, který vybrat z těch OSS, který se lehce staví.

Práce s Javou je vždy pomalá, proto na ní testuju CPU. Nemusím pak dělat Javu, ale jako test pro CPU programátora je to fajn.

Mě nezajímá ani moc start, protože potřebuju spíš build a Docker dohromady. To by AMD mohlo dávat s přehledem.

Nepotřebuju ani lehké vývojové prostředí, protože mám těžké prostředí a vyhovuje mi. Potřebuju ale vybrat dobrý CPU pro to

Build a docker je prevazne zavisly na vykonu IO subsystemu. Zvetsenim RAM a rychlejsim SSD diskem pomuzes mnohem vic, nez vykonem procesoru.
Proto jsem nahore psal, ze ten tvuj test testuje spis SSD, nez CPU.

Java neni pomala, ma pomaly start z duvodu nabehu JVM a pomaly startup s duvodu slozitosti prostredi, napr Spring IOT injektaze. Vlastni beh v Jave je rychlejsi, nez treba GO.

Lehkym vyvojovym prostredim jsem mel namysli, ze si ve Spring Bootu udelas lehky development profil postaveny na lehkych mock komponentach typu MySQL pro DB backend, teprve finalni build bude urcen pro plnotucnou produkci.

Standardni prace se springem je, ze develotri maji na svem NTB par lehkych mocku, pisou svuj kot aby obstal proti unit testum, vecer commitnou do GITu a pres noc to Bamboo schroupe na opravdovem test prostredi.

 

[užnestudent]

Build a docker je prevazne zavisly na vykonu IO subsystemu. Zvetsenim RAM a rychlejsim SSD diskem pomuzes mnohem vic, nez vykonem procesoru.
Proto jsem nahore psal, ze ten tvuj test testuje spis SSD, nez CPU.

Java neni pomala, ma pomaly start z duvodu nabehu JVM a pomaly startup s duvodu slozitosti prostredi, napr Spring IOT injektaze. Vlastni beh v Jave je rychlejsi, nez treba GO.

Lehkym vyvojovym prostredim jsem mel namysli, ze si ve Spring Bootu udelas lehky development profil postaveny na lehkych mock komponentach typu MySQL pro DB backend, teprve finalni build bude urcen pro plnotucnou produkci.

Standardni prace se springem je, ze develotri maji na svem NTB par lehkych mocku, pisou svuj kot aby obstal proti unit testum, vecer commitnou do GITu a pres noc to Bamboo schroupe na opravdovem test prostredi.

Letos jsem měl SSD na reklamaci a dal do NB starý HDD. Doba buildu s integračními testy byla skoro stejná, takže SSD fajn, ale jak na co.

Nezajímá mě start, protože ji třeba ani nepouštím. Potřebuju rychlou kompilaci, rychlé poladění závislostí v buildu a podobné věci, které se z IDE dělají každou chvíli. A normální build to testuje lépe než testy Handbrake

To asi dělávám. Prostě v Dockeru mám nějaké minimální servery, abych otestoval funkčnost a v produkci jsou pak jiné konfigurace.

To jo, takhle se pracuje třeba v korporaci. Chápu to a může to fungovat. Ale nedělám jen v Javě a potřebuju mít vše i u sebe. Je to nejrychlejší možnost, i když pak potřebuješ dobré vybavení.

[Youda]

Build a docker je prevazne zavisly na vykonu IO subsystemu. Zvetsenim RAM a rychlejsim SSD diskem pomuzes mnohem vic, nez vykonem procesoru.
Proto jsem nahore psal, ze ten tvuj test testuje spis SSD, nez CPU.

Java neni pomala, ma pomaly start z duvodu nabehu JVM a pomaly startup s duvodu slozitosti prostredi, napr Spring IOT injektaze. Vlastni beh v Jave je rychlejsi, nez treba GO.

Lehkym vyvojovym prostredim jsem mel namysli, ze si ve Spring Bootu udelas lehky development profil postaveny na lehkych mock komponentach typu MySQL pro DB backend, teprve finalni build bude urcen pro plnotucnou produkci.

Standardni prace se springem je, ze develotri maji na svem NTB par lehkych mocku, pisou svuj kot aby obstal proti unit testum, vecer commitnou do GITu a pres noc to Bamboo schroupe na opravdovem test prostredi.

Letos jsem měl SSD na reklamaci a dal do NB starý HDD. Doba buildu s integračními testy byla skoro stejná, takže SSD fajn, ale jak na co.

Nezajímá mě start, protože ji třeba ani nepouštím. Potřebuju rychlou kompilaci, rychlé poladění závislostí v buildu a podobné věci, které se z IDE dělají každou chvíli. A normální build to testuje lépe než testy Handbrake

To asi dělávám. Prostě v Dockeru mám nějaké minimální servery, abych otestoval funkčnost a v produkci jsou pak jiné konfigurace.

To jo, takhle se pracuje třeba v korporaci. Chápu to a může to fungovat. Ale nedělám jen v Javě a potřebuju mít vše i u sebe. Je to nejrychlejší možnost, i když pak potřebuješ dobré vybavení.

Ze ti NTB s plotnovym HDD buildoval stejne rychle jako SSD je pro me dost nepredstavitelne, ale budiz.
Kdyz teda neresis build ani startup, co teda v pripade Javy resis?
V bezne Java IDE (Eclipse/STS) se java class zkompiluje hned pri ulozeni souboru a trva to radove milisekundy. Java, jak samozrejme vis, nema zadny EXE ci DLL format, pro kazdou tridu existuje zvlastni class soubor, to znamena, ze pri editaci tridy se okamzite prekompiluje pouze dana trida a zbytek se nesaha.

[bigfoot]

A ted rozjel novy projekt "deno", ktery ma byt obdobou Node.js, ale postaveny na TypeScriptu a Rustu.

TypeScript je sice celkem fajn, ale třeba na TIOBE není ani v první padesátce. Tož to přeju hodně úspěchů se stavěním protivníka node.js na tak rozšířeném jazyce.

[užnestudent]

Právě každý build je dost jiný a i ten Spring je blbý v tom, že moc vláken nepoužije. Ale pořád lepší než Handbrake.

Upravuješ větší projekt a pokud třeba neděláš kompletní refactoring, tak si něco přejmenuješ a pak se díváš, co se rozbilo. To je v každém IDE docela rychlé. Pak build závislosti přepočítání je vždy dost náročné a pokud toho dáváš víc a trochu si s tím hraješ, tak je to dost opruz. Integrační testy by mohly být rychlejší, takže celý build a jejich spuštění. Tam jde o kompilaci, postavení něčeho spustitelného, spuštění, spuštění testů, provoz serverů a to je asi vše. To nemusí být časté, ale čím rychlejší to je, tím lépe. Normální unit testy co nejrychlejší také. Debug puštění je vždy pomalé, tak také asi co nejlepší CPU? Prostě normální vývoj, ale v Javě vše trvá a IDE tomu moc nepomáhá, protože asi samo žere docela dost prostředků.

A mám problém s tím, jestli je lepší Intel, který v náročných aplikacích jako hry ukazuje, že i 8700K se 6 jádry si dá s přehledem 8jádrový Ryzen. Ale třeba u Javy by to bylo jiné.