Blender Java

Jason LaDere vytvořil funkční základ portu 3D modelovacího programu Blender do jazyka Java. Podporovány jsou souborové operace, manipulace s uživatelským rozhraním, renderování a základní editace modelu.

6.9.2009 17:50 | Pavel Křivánek | Zajímavý software

Komentáře

[cinan]

jezis to musi byt pomale :-P

[agre]

Nerekl bych "jezisi" ale "dekuji za praci". Nerekl bych "musi byt pomale" dokud nevyzkousim sam

 ;)

[cinan]

jasne, mas pravdu, to bol len moj prvy dojem :)

[Spike]

"Díky za nic"?

[jehovista]

Proboha kde se lihnete? Zjisti si nejaka fakta o rychlosti Javy.

[default]

To je jednoduché. Každý, kdo trošku přičuchnul k programování, se dostal i k Javě. Ale každý na to nemá. Java API je docela rozsáhlé. Metodiku a další postuláty okolo Javy člověk musí přijmout. A že nejsou špatný.

No — a přesně ti, kteří tohle nepobrali, z nich se líhnou tyto existence.

[Jardík]

Já bych uvítal nějaký vývojový prostředí pro javu, který má např. všechny fíčuru netbeans, ale který není tak pomalý při všem co děláte a jeho start netrvá půl minuty. Kolikrát se netbeans zasekne při načítání autocomplete listu a já už napsal další slovo.

[jehovista]

Zkusil bych nejakou novejsi verzi. Me prijde, ze se porad zrychluje.

[Jardík]

A taky bych uvítal rychlé GUI, to je hlavní problém java aplikací. Metal je ošklivý a né moc rychlý a GTK kreslení je snad ještě horší - pomalejší a navíc jsou některé widgety totálně spatně kreslené nebo jsou rozbité. (např. combobox, menu, taby, ...). Kde mi GUI javy přijde docela rychlé je ve Windows při emulaci "nativních" prvků (ale některé jsou taky špatně vykreslené) a v MacOSX (taky s nativnímy, ale taky bugy). Možná by to mohlo běhat svižně na solarisu, ale tam jsem to nezkoušel, jen to běhalo na sunrayích ve škole, ale ty jsou pomalý, i když tam nic neběží, natož po spuštění např. netbeansu

[eoj]

GUI je z těch rychlejších částí Javy.

[kyknos]

no nazdar

[ted]

+1 :D

[Algi]

Ty bugy ve vykreslování GUI v Mac OS X jsou doufám reportované. Ještě před pár týdny byla velmi dobrá šance je nahlásit, aby se oprava dostala do release verze Update 5. Developer Previews bylo na Apple až nezvykle moc. Pokud jsi tak neučinil, pak si v podstatě nemáš na co stěžovat

[msk]

A taky bych uvítal rychlé GUI, to je hlavní problém java aplikací.

A ja take, co neni implicitne hnusne. Ale QTJambi to ciastocne zachranuje.

[Michal Svatuška]

Eclipse + SWT SWT k vykreslovaní prvků GUI používá nativní knihovny operačních systémů prostřednictvím JNI (Java Native Interface) http://cs.wikipedia.org/wiki/Standard_Widget_Toolkit http://www.eclipse.org/swt/

[Filip Jirsák]

Mně třeba vždy připadalo SWT subjektivně pomalejší, než Swing.

[Michal Svatuška]

Eclipse

[default]

Zkus to pustit se server hotspotem. Ano — prvních pár kliků bude utrpením oproti Client HostSpot, ale pak to nabere takový rychlosti, že si tvá videa budeš moci strčit mezi půlky. Osobně vyzkoušeno a provozováno na velmi slabém stroji.

[kyknos]

ne ne, tihle lide se lihnou z tech, co pricuchli k jave jako uzivatele...

[Filip Jirsák]

Takže někomu připadá pomalé třeba Abíčko?

[JS]

I kdyby nebylo pomale (jako ze to nemuzeme posoudit, protoze nemame jeho implementaci v C++), webove aplikace jsou specialni pripad, protoze jsou (IMHO) pomerne snadnou JIT kompilovatelne. V zasade, ve webovych aplikacich se pousti neustale ten stejny kod se stejnymi parametry (protoze se vytvari stale tataz stranka). Tam uznavam, ze Java muze byt nekolikanasobne rychlejsi nez i C (ovsem je otazka, zda to tak bude, pokud styl programovani v Jave napr. vychvaluje ignorovani spravy pameti od programatora).

Ale na aplikaci typu Blender? Ten dukaz, ze tam JIT bude rychlejsi, chci videt!

[Filip Jirsák]

jako ze to nemuzeme posoudit, protoze nemame jeho implementaci v C++

To je aspirace na perlu týdne?

Ale na aplikaci typu Blender? Ten dukaz, ze tam JIT bude rychlejsi, chci videt!

Aplikace typu Blender podle mne také vykonává neustále dokola ten samý kód. Přičemž JIT má tu výhodu, že může optimalizovat na instrukční sadu konkrétního stroje a dokonce i na konkrétní zpracovávaná data. To jde samozřejmě naprogramovat i v čemkoli jiném (přinejhorším si vždy můžete naprogramovat JIT). Každopádně je ta debata o rychlosti nesmyslná. Buď je to neúnosně pomalé, pak by to autor asi nezveřejňoval a jenom by oznámil, že to zkusil a bylo to pomalé. Nebo je rychlost dostačující, a pak je zbytečné se tím zabývat. Těch pár lidí, kterým opravdu na rychlosti záleží, pak budou dál používat C Blender pod Gentoo.

[JS]

Nemuzeme to posoudit, protoze nemame nic, s cim bychom to mohli porovnat. Samozrejme, ja bych server typu ABCLinuxu psal v Pythonu, ale o tom vim, ze je pomalejsi. Proto si myslim, ze nejblizsi alternativa k cemu to porovnat je C++. Kazdopadne, to je nepodstatne, protoze jak uz jsem rekl, u  webovych stranek JIT muze mit svuj vyznam.

Kazdopadne, muzete mi vysvetlit, v cem GUI editor vykonava ten stejny kod (treba asi v jakych funkcich)? Prece uzivatel neustale klika na jine funkce nad jinymi objekty. Cela vec, kterou editujete, se neustale meni. A v renderovani doufam nepocitaji tytez veci dvakrat. Bohuzel, slysim ten samy obecny argument, jak je to v Jave lepsi. Ale abyste aspon nejak zduvodnil, ze trasovani (nutne k optimalizaci za behu) bude stat mene nez optimalizace, ktere se tim ziskaji, to ne. Stejne tak nezduvodnujete, zda se vyplati za timto ucelem sezrat vice pameti (a ta je dost vzacnym zdrojem pro programy tohoto typu).

Take samozrejme, prelozit si to pro svou architekturu muzete i v C. Dokonce muzete prekladaci podat i vystup z profileru.

[Filip Jirsák]

Kazdopadne, muzete mi vysvetlit, v cem GUI editor vykonava ten stejny kod (treba asi v jakych funkcich)? Prece uzivatel neustale klika na jine funkce nad jinymi objekty. Cela vec, kterou editujete, se neustale meni.

GUI editor volá typicky stále tytéž funkce, pouze s různými parametry. To, že se mění editovaná věc, s optimalizací kódu skoro vůbec nesouvisí – vykonává se pořád ten samý kód. Když editujete textový soubor, data se také pořád mění, ale to ještě neznamená, že se po každém přidaném písmenku musí překompilovat celý editor…

Bohuzel, slysim ten samy obecny argument, jak je to v Jave lepsi.

A to jste slyšel od koho? Já jsem tady zaznamenal jenom argument, že je to v Javě pomalejší, s odůvodněním „protože proto“.

[trekker.dk]

vykonává se pořád ten samý kód

Akorát s různými parametry občas dělá něco jiného, takže ho optimalizace připravuje maximálně na předchozí válku.

[Filip Jirsák]

Aha, takže optimalizace vestavěné v kompilátorech jsou vlastně úplně k ničemu, spíš situaci jenom zhoršují. Co se tady člověk všechno nedozví…

[trekker.dk]

Co se tady člověk všechno nedozví…

Dost často to, co sám chceš slyšet.

A když jsme u toho, jestliže je nějakou optimalizaci možné vestavět do kompilátoru, pravděpodobně s ní není potřeba čekat do doby, než ten program poběží.

[Filip Jirsák]

JIT je také kompilátor. Přesto existují optimalizace, které je možné provádět až na základě údajů o běhu programu.

[JS]

Ano. Jednim moznym druhem takovych optimalizaci je specializace funkci, kdy se pro casto volanou funkci s castecne shodnymi parametry se tato funkce prelozi jakoby tyto parametry byly konstatni (tedy ve specialnim pripade, kdy se funkce bez vedlejsich efektu vola se shodnymi parametry, se prelozi rovnou jako konstanta).

Problem je, ze toto jednak vyzaduje dost pameti (nekam musime schovavat vsechna ta data o volanich a prelozene varianty funkce), a za druhe funguje jen tehdy, pokud lze duvodne predpokladat, ze se bude tataz funkce volat casto se shodnymi nebo podobnymi parametry. Coz u weboveho serveru predpokladat lze, protoze je tam spousta funkci, ktere nahrazuji predem znamy text do predem zname sablony. Ale u grafickeho editoru? Opravdu byste musel blize popsat, jak by se to mohlo vyplatit.

Nebo byste musel uvest, jakou dalsi optimalizaci (ktera je ucinna za behu, ale nelze provest pri kompilaci) mate na mysli.

[Filip Jirsák]

Třeba přerovnání instrukcí, aby lépe fungovala predikce skoků procesoru.

[JS]

Jo, to se taky tvrdiva. Ale ja osobne si myslim, ze to ma vliv jenom v mizivem procentu pripadu. Rad bych videl nejaky priklad, kde to ma zasadni vliv, a kde to zaroven neumi vyresit standardni kompilator. A to nemluvim o tom, ze proto ty procesory tu predikci maji, a ta zvladne hrave 90% tohoto problemu (typickym prikladem muze byt test v kratke smycce).

Fakt bych to rad videl. Osobne tohle nepovazuji vubec za podstatny druh optimalizace (daleko efektivnejsi mi prijde prave treba eliminace podvyrazu, specializace funkci nebo vytahovani konstantnich vyrazu mimo smycku).

[Filip Jirsák]

if (test) {
  …
} else {
  …
}

Pokud JIT zjistí, že se větev else prakticky nikdy neprovádí, může kód uspořádat tak, že se rovnou začnou zpracovávat instrukce z ifu, kód pro else se ani nemusí nahrávat do paměti atd. Jenom se někde na vhodném místě udělá test, zda ta podmínka opravdu platí. Statický kompilátor na tohle bez nějaké nápovědy nemá šanci přijít.

[JS]

No, tohle je trochu jiny priklad nez predikce skoku, ale budiz. Pokud by JIT zjistil, ze test je v podstate konstanta, muze neco takoveho udelat. To uz nema daleko ke specializaci, o ktere mluvim vyse.

Kazdopadne, ja bych rad videl priklad s analyzou kdy je to lepsi nez bezny kompilator. Me totiz pripada, ze to ve vetsine pripadu bude kod zpomalovat, protoze se bude muset pro kazdy takovy if neustale ukladat hodnota test, aby se zjistilo, zda nahodou nebyva konstatni. Proste, pripada mi to jako tradeoff, ktery ve vetsine pripadu program zpomali, aby ho v nejakem specialnim pripade o neco malo zrychlil. Pokud byste ukazal, ze v grafickem editoru dochazi casto k te druhe moznosti, pak to beru. Ale ja nic takoveho nevidim.

[trekker.dk]

Statický kompilátor na tohle bez nějaké nápovědy nemá šanci přijít.

Ano, od toho je tu buď profiling nebo (v GCC) __builtin_expect

kód pro else se ani nemusí nahrávat do paměti

Jak často je ten kód, co se nemusí nahrát, dost velký na to, aby to mělo nějaký význam?

(+ námitky o příspěvek výš)

[Filip Jirsák]

Jak často je ten kód, co se nemusí nahrát, dost velký na to, aby to mělo nějaký význam?

Myslím, že často. Keš procesoru není nafukovací.

[trekker.dk]

Paměť a cache procesoru je něco jiného. A pokud se kód nemá vykonat, pravděpodobně se do cache nedostane

[vlastikroot]

optimalizace vestavěné v kompilátorech jsou vlastně úplně k ničemu, spíš situaci jenom zhoršují

To je ale nahodou pravda! Do kodu pridavaji magicke schopnosti (sam jsem se o tom ted presvedcil pri 3hodinovem hledani chyby v obsluze preruseni v kernelu co ted pisu).

[kyknos]

tak zrovna abicko je jeden ze serveru (z tech co pravidelne navstevuji) s nejvetsim poctem vypadku

navic mi web neprijde jako zrovna dobry argument v diskusi o gui aplikaci

[Filip Jirsák]

tak zrovna abicko je jeden ze serveru (z tech co pravidelne navstevuji) s nejvetsim poctem vypadku

Jste si jist, že závada není na vašem přijímači? Nebo že to souvisí se serverovou aplikací? Já si na nějaký výpadek v poslední době nevzpomínám. A i kdyby k nějakým výpadkům došlo, s největší pravděpodobností to s Javou vůbec nesouvisí. Já si tedy alespoň nepamatuju na žádnou chybu v JVM, která by něco takového mohla způsobit.

Nediskutuje se o GUI aplikaci, ale o Javě. Ostatně rychlost GUI nebude úzké místo renderovací aplikace.

[kyknos]

Jsem si zcela jist. Vypadky (at uz delsi, ci jen nekolikasekundove) pozoruji doma i v praci, v ruznych prohlizecich, na ruznych systemech. A v dobe kdy ostatni weby nemaji problem. Cim jsou zpusobene mi je jedno. Jen rikam, ze abicko je zrovna z tech produktu, ktere mi neposkytuji zrovna nejlepsi uzivatelsky zazitek. (A nejen kvuli vypadkum, vrazdil bych napriklad kvuli povinnym nahledum komentaru a relationid - uzasne feature pri pouziti z mobilu, zvlaste pres roaming - ale za tohle java nemuze urcite :)

Kdyz jsem se jednou bavil o javovych aplikacich s nejakym javistou u obeda, rikal mi, ze java je dobra, jen javovi vyvojari jsou prasata jeste casteji nez v pripade ostatnich jazyku. I to je mozne. Kazdopadne ja jako clovek co v zivote nenapsal ani radku javoveho kodu a o jejich technickych vlastnostech nevi v podstate nic, mam podmineny reflex - javove aplikace ne.

[msk]

Dlhodobo som bol odporca Javy ako takej. Dnes som Java programator. Po rocnej skusenosti mozem povedat, ze Java ako jazyk neni az tak hrozna, aj ked su v nej veci, ktore ma ako c++-kara neskutocne seru a nedokazem ich stravit. Co sa tyka rychlosti, je to pripad od pripadu. Je URCITE pomalsia, ako ekvivalent v C++, niekde viac, niekde menej. U Javy a komunity okolo vidim akurat zasadny problem v tom, a zo spravania nejedneho Java programatora (alebo skor architekta) som sa v tom uistil, ze viac podliehaju modnym vlnam bez toho, aby sa nad problemom hlbsie zamysleli. Vid. pouzivanie Hibernate v prostredi citlivom na DB vykon, nechutne naduzivanie webservices na veci, na ktore nikdy neboli stavane, kecy o tom, ze hardware je lacnejsi ako programator atd atd...

[Espinosa]

> Java ... Je URCITE pomalsia, ako ekvivalent v C++, niekde viac, niekde menej.

Není tomu tak.

Dá se to shrnout asi takhle:

"In some cases Java is significantly slower, in others, significantly faster"

Zdroje:

http://en.wikipedia.org/wiki/Java_performance

http://scribblethink.org/Computer/javaCbenchmark.html

Jediné co lze říci že URČITĚ Java oproti C:

1) Java spotřebuje více paměti. S tou Java moc nepárá. Často ale vede agresivnější použití paměti k vyšším výkonům.

2) Java program bude startovat pomaleji. I spuštění triviálního programu vyvolá poměrně složitý zaváděcí proces a načítání knihoven (minimálně rt.jar) V Javě tak nemá cenu dělat jednoúčelovky, jako GUI jednoduchý textový editor. Projekty jako JEdit nemají moc šancí na masovou popularitu. Naopak u IDE jako Eclipse, kde aplikaci ráno spustíte a vypínáte s ukončením pracovní doby pár sekund navíc při startu nehraje velkou roli.

 

[Algi]

 Ad 2) Nejsem si úplně jistý, zda neběží Java na pozadí. Nevím jak funguje na Windows/Linuxu, ale mám ověřeno že na Macu její první start zabere docela dost (v 64-bitovém režimu na 32-bitovém systému). Avšak spustím-li jí podruhé, je spuštění aplikace okamžité. Možná to tak bude i na ostatních systémech. Avšak protože mám k dispozici pouze tragicky pomalé PC s Windows XP, takže nemůžu efektivnost spuštění Javovské aplikace objektivně posoudit. Jednoduše na něm trvá vše dlouho (řádově sekundy, až minuty).

[Espinosa]

Opakovane spusteni bude urcite rychlejsi, uz jen kvuli nakesovanym HDD datum, tj. rt.jar bude v pameti, to urychli vec hodne. Od verze Java 1.6 pracuji na cachingu naparsovanych informaci, takze by se stale dokola nacitane a vyhodnocovane knihovny (rt.jar) nemuseli parsovat a vyhodnocovat stale dokola ale vyuzila by se nakasovana data. 

[JS]

Jo. Jenze GUI editory jsou prave oblasti, kde se ta rychlost Javy neprojevi, spis naopak (protoze, narozdil od treba webserveru, pousteji kod na nepredvidatelna data). Pokud mate jiny pocit, rad se poucim (ostatne, bylo by pekne, kdybyste upresnil, v jakych presne pripadech je Java rychlejsi).

Naopak, u GUI editoru je rychlost uzce svazana s co nejmensim pouzitim pameti (spoustu provazanych malych objektu, ktere nelze nijak predpocitat, protoze se neustale meni). Agresivnejsi pouziti pameti muze teoreticky vest i u takove aplikace k vyssim vykonum, volbou vhodnych datovych struktur. Ale neni uroven, na jake se pohybuji JIT optimalizace Javy - ty maximalne prelozi trochu jinak nejakou funkci.

JIT je zkratka tradeoff, ktery drive nebo pozdeji narazi na svuj limit.

Mimochodem, zajimave na tom 2. odkazu, ktery uvadite, je, ze vetsina tech vysvetleni (proc je Java rychlejsi) spociva v tom, ze Java nabizi lepsi abstrakci, ktere davaji kompilatoru vetsi prostor pro implementaci. Je to v souladu s mym vlastnim presvedcenim, ze budoucnosti neni ani tak JIT, jako spis lepsi abstrakce v jazycich, ktera nam dovoli delat slozitejsi optimalizace. V tomto smeru Java zadnym velkym pokrokem bohuzel neni, protoze je na temer stejne urovni, jako C++.

[Espinosa]

Ano GUI editory jsou oblast kde se rychlost neprojevi, hlavne ty jednoucelove, casto otvirane a zavirane. Naopak v serverovych aplikacich s nepretrzitym provozem je misto kde Java exceluje a ne nahodou je tam realne nasazovana. Z sve praxe mohu potvrdit ze takove aplikace (Java a Net) drtive prevazuji nad aplikacemi v C++, na desktopu je tomu naopak.

GUI aplikace jako IDE jako Eclipse, neco co rano spustite a s koncem pracovni doby vypnete, tam je rychlost sposteni relativne zanedbatelna, ma to pak blize paradoxne prave k serverovym aplikacim. Tam opet muze Java a jeji JIT opet excelovat. Jakmile se to spusti, trochu "rozehreje", jede to pekne.

kazda technologie ma svuj limit :) Snad mozna proto jich mame tolik.

Ano, odkazovany clanek (2) je zajimavy hlavne merenim, ohledne vyhodnoceni proc uz autor mlzi a tape. Doporucuji shrnuti a dalsi odkazy na wikipedia strance.

[kyknos]

Nediskutuje se o GUI aplikaci, ale o Javě.

diskutuje se o naprosto nesmyslnem prepisu gui apliakce do javy

Ostatně rychlost GUI nebude úzké místo renderovací aplikace.

Blender neni jen renderer. GUI je jeho klicovou casti. A rychlost je zde kriticka stejne jako u rendereru. Blender neni textovy editor ci podobna ptakovina.

[aubi]

Prosimte, uzivatele jakych aplikaci?

Ja tady posloucham narky nad NB, ze dlouho startuji. Kdyz to srovnam s konkurenci (MSVC), tak start je stejny a mnozstvi funkci radove vetsi.

Ktere srovnatelne aplikace jsou v Jave pomalejsi?

Teda ne, ze bych videl v tom prepisu smysl.

[Jardík]

Tak já schválně nahraju nějaký video jako důkaz, že je netbeans pomalej.

[Jardík]

Takže slíbená videa. Obsahuje:

První start netbeans (odstartováno hned po započatí nahrávání enterem, tak nehledejte kliknutí). Všimněte si např. lagu při otevření menu a jeho samovolné zavření, protože netbeans nebyl tak úplně načtenej. Dokuď si totiž nenačte autocomplete a spol, laguje a je nepoužitelný. Takže čas počítám od startu videa až do zmizení progressbaru = cca 23s. Aktivní pluginy pro Javu SE (s GUI builderem) a C++.

Druhý start netbeans, cca 19s.

První start QtCreatoru (žádná Qt aplikace předtím spuštěna nebyla, takže Qt knihovny nejsou v paměti, aby někdo neměl řeči, že java+knihovny poprvé nebyly v paměti) - 7s. Počítám od čtvrté sekundy (klik na nabídku) do jedenácté (tam už je prostředí plně použitelné a nelaguje a stejně jako v netbeansu je načten projekt).

Druhý start QtCreatoru - 2s (je to o trochu míň, ale abych nebyl zlej na ostatní ).

Druhý start Monodevelopu (to aby někdo neměl řeči, že QtCreator je jen pro C++, v monodevelopu mám pluginy pro C#, C++, Valu a VB.NET)- 4s. První start jsem zapomněl nahrát a nechce se mi už restartovat. Ale můžu prozradit, že to bylo o dost rychlejší než netbeans a jen o trochu pomalejší než první start QtCreatoru.

Tímto testem tedy dokazuju, že moloch jako netbeans je nehorázně pomalý (a na rozdíl od ostatních je netbeans při psaní kódu náladově pomalej/rychlej, podle toho, jak se mu chce, ostatní už jsou pak stále rychlé a nedochází k různým lagům). To, že je ale pomalý netbeans pro mě neznamená, že je java tak pomalá, ale GUI v javě je (a hlavně na Linuxu, asi to pěkně pomršili) pomalost, obzvláště, když v aplikaci běží další thread - jako u netbeansu např. načítání autocomplete.

[jehovista]

Netbeans startuji pomalu? No to je toho. Stejne to zapinam jednou za den a mezitim si prectu zpravy/udelam kafe, takze me to vůbec netrapi. A pri praci mi teda rychlost omezujici neprijde. Pravda, obcas se mi nechce treba prepnout zalozka, ale to se stava jenom pri hodne vytizenem procesoru. Jinak si nemam na co stezovat.

[Jardík]

Jó, ale někdo takhle brouzdá po netu, najde tam java soubor s úkazkou, jak něco udělat, chce si ho otevřít, pak ho zase zavřít, najít další, ... ale když kvůli každému souboru spouští 30s netbeans, tak se mu to zhnusí ...

[Ladicek]

V takovém případě není potřeba IDE, úplně stačí jenom obarvování, a to udělá i blbý KWrite Já to tak dělám, stažené zdrojáky prohlížím v normálním textovém editoru, a teprve když s nimi chci nějak vážně pracovat, otevírám je v IDEi. Která mimochodem startuje možná ještě dýl než NetBeans

[mirec]

Ja si postupne začínam zvykať na vim (či už na PHP, Javu, alebo C++) :P

[Filip Jirsák]

To je jako byste si na každý kus textu, který najdete na webu, pustil OpenOffice, nebo jej proháněl TeXem a prohlížel v PDFku. Nebo jako byste pro každé URL pouštěl znovu prohlížeč. Nebylo by jednodušší použít jen nějaký prohlížeč (pokud jde jen o obarvování zdrojáku), nebo alespoň IDE nevypínat a nestartovat znova pro každý soubor?

[kyknos]

Nebylo by lepsi programovat tak, aby uzivatel nemusel takoveto veci resit? Ja jako uzivatel nechci resit podobne problemy a premyslet, kdy si muzu dovolit aplikaci zapnout ci vypnout.

[Ladicek]

Ale jó! Otevírejte všechno ve vimku a máte to

[kyknos]

vsak ja jakove bazmeky nepouzivam, bez obav :)

[default]

Tak se někdy podívej do Apple Storu.

[Filip Jirsák]

Nebylo. Nebo máte pocit, že když si uživatel stáhne z internetu nějaké náhodné smetí a spustí si k tomu program na řízení CNC stroje, je ten program povinen do jedné sekundy se spustit a s tím smetím něco rozumného udělat? Já myslím, že ne, že postačí, když bude program plnit účel, k jakému je navržen. A IDE není navrženo pro prohlížení jednotlivých souborů. Ta kritika je asi stejná, jako kdyby si stěžoval, že slyší webovou adresu v televizi, a trvá to pokaždé minutu, než mu naběhne počítač a webový prohlížeč. Na stránku se podívá, počítač vypne a za chvilku slyší další adresu, a zase spuštění počítače trvá minutu.

[kyknos]

Nevim jaka je filosofie IDE a vlastne ani nevim, k cemu slouzi, mne na programovani vzdycky bohate stacil vim. V Jave se ale pise i spousta normalnich aplikaci pro bezne pouziti, u kterych je zdlouhave spousteni velmi otravne. Tahle diskuse zacala zpravickou o jedne takove aplikaci a jejim naprosto nesmyslnem prevodu do javy.

[Filip Jirsák]

Jenže ty „normální aplikace pro běžné použití“ se samozřejmě nespouští tak dlouho, jako IDE, které při startu nahrává desítky modulů, ověřuje jejich závislosti, otvírá a kontroluje projekty a aktualizuje si informace o nich atd.

[kyknos]

to by me tedy zajimalo, kde jsem prisel k te zkusenosti, kdyz jsme ide v zivote nepouzil :)

je to problem mezi javovymi aplikacemi rozsireny

[Filip Jirsák]

Stejně rozšířený problém je to i mezi C++ aplikacemi, Python aplikacemi atd.

[kyknos]

to prave neni pravda

[Filip Jirsák]

Mně tedy takové KDE, OpenOffice, Firefox, Adobe Reader, MS Outlook a další také startují pomalu.

[kyknos]

ze jmenovanych aplikaci pouzivam jen acroread a firefox. Firefox povazuji za kram a psal jsem o tom uz nekolikrat. acroread mi funguje dobre, problemy s nim nemam.

[Algi]

 Víš, tohle je ale problém pouze Windowsového přístupu, který drtivá většina programů (včetně Linuxových) bezmyšlenkovitě přebrala. Dobrým příkladem budiž XCode na Macu, kde i když zavřete všechna okna, tak program stále běží, dokud vyloženě neřeknete, že jej chcete vypnout. Jinde to je okno = program. Zavřete okno, zavřete program. Stupidní, co?

Podle mě to ale na Windows ani jinak udělat nelze. Jakmile Vám totiž zmizí okno z nabídky, tak se k programu prostě nedostanete. Leda, že by běželo něco v system tray a to už je dost netypický případ. Btw. to je důvod, proč je menu aplikace mimo okno. Ne, aby se měli windowsáci/linuxáci čemu divit a případně co napodobovat, ale aby bylo možné se k aplikaci bez oken vůbec dostat

[Daniel Kvasnička ml.]

...a taky aby kdyz je na obrazovce 10 okne jedne aplikace, aby 9 (vetsinou) redundantnich menu zbytecne nezabiralo prostor.

[kyknos]

vis, u kvalitnicha dobre napsanych aplikaci by mi nevadilo, pokud by bezely i po zavreni okna... jenze u tech to neni potreba

predstava, ze mi javove bazmeky zerouci nesmyslna mnozstvi ram v pameti zustavaji je jeste desivejsi nez cekat na jejich spusteni

[Algi]

Asi tě teď překvapím, ale existují Javovské aplikace, co nežerou příšerné množství paměti, běhají rychle a rychle i startují. A světe div se, jsou i použitelné a účelné. Nechávám je standardně zapnuté a vůbec mě to netrápí. Pochopitelně musím zmínit Esmsku, avšak i takový muCommander, jEdit a Cyberduck jsou malé a paměť nežerou. A to jsem kdysi měl jenom 2 giga ramky, teď mám 4 (aby mě neswapovaly grafický programy, když si pustím gamesu ). Na nedostatek paměti jsem si nikdy stežovat nemohl, to už víc žralo Safari díky načteným filmečkům z Youtube. A že zabírá NetBeans více paměti? To je přece logické, když musí držet naindexované třídy a všemožné další informace, aby se v něm rychle a pohodlně psalo...

[kyknos]

tak zrovna jedit jsme se kdysi snazil pouzivat, a rozhodne to nebyla svizna aplikace

[Daniel Kvasnička ml.]

muCommander a Cyberduck jsem zabil jednou ranou... ForkLiftem. Nativni aplikace a zastane praci obou. Cyberduck, pokud vim, je Java app jen z casti. Pametove a rychlostni problemy jsem s nim taky nemel, ale funkcni ano :/

[Jardík]

No zrovna esmsku bych nezmiňoval - ten splashscreen na tak malou aplikaci je tam nějak dlouho a přitom tam je 8 bran (mám nějakou starší verzi, ale asi se to moc nezměnilo) a v kontaktlistu nemám nikoho, takže to skoro nic nemůže načítat. Doufám, že tam schválně není nějaký timer, který to zdržuje To když spustím PSI s transportem na smsky a s 50 kontakty tak je to sekunda i s přihlášením (možná dvě, ať nežeru). A eSMSka má minimálně 15, alespoň, že narozdíl od netbeansu je další už podstatně rychlejší (asi to tu javu hold musí načíst, ale PSI taky "musí načíst" Qt ...). A paměť mě ani netrápí, 6GB RAM mi to jen tak nesežere.

[Algi]

Až budu mít někdy chvíli, proženu to profilerem. Také se mi zdá, že to zrovna rychle nenabíhá... Ale může to být způsobeno např. kontrolou aktualizací bran, apod. Díky za připomínku. Na druhou stranu, 15s to opravdu nezabírá. Mě se to spouští 4 vteřiny, nicméně uznávám, že i to je docela dlouhá doba. Přitom Java se spustí okamžitě, takže problém bude někde u nás v kódu... Btw jak to, že jí vůbec vypínáš?

[Jardík]

Říkám, mám možná nějakou starší verzi (píše se tu 0.12.0), třeba je novější rychlejší (jestli je). Jí kdyžtak stáhnu, vyzkouším a když to bude tak pomalé, tak vám to i rád nahraju

[default]

Tak se přesuň z představy do reality. Denně mi tu běží (celou pracovní dobu vkuse):

• Virtuální PC, 1GB RAM
• NetBeans IDE (Java aplikace)
• Oracle SQL Developer (též Java aplikace)
• JEdit (též Java aplikace)

Někdy ještě navíc:

• Visual Paradigm for UML (Java aplikace)

A stále mám dostatek systémových prostředků pro mailového klienta, Safari, iTerm a další blbosti. Bez ztráty výkonu.

Co dělám špatně?

[kyknos]

pokud ti to vyhovuje, nedelas spatne nic :)

jen si uvedom, ze existuji uzivatele s ponekud vyssimi naroky

[Daniel Kvasnička ml.]

Visual Paradigm for UML

OT: znas jeste nejaky jiny pouzitelny CASE/UML tool pro Mac krome VP? (predpokladam, ze jsi mluvil o OS X)

[Daniel Kvasnička ml.]

Myslim se schopnosti generovat kod v Jave...

[JS]

Treba tato?

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=gpp&box=1

Pokud byste chtel vazne tvrdit, ze Java (respektive jakykoli JIT kompilator) je na aplikaci typu Blender vhodnejsi, musel byste to IMHO dolozit nejakym solidnim argumentem. Pomerne rad bych si takovy poslechl.

[pozortucnak]

4. Testovací skript pro zjištění rozdílu mezi Lua a LuaJ v rychlosti interpretace skriptů

[Filip Jirsák]

Teď by to ještě chtělo porovnání implementací, tj. zda obě implementace jsou zhruba stejně dobře naprogramované.

[Ladicek]

Ono totiž argumentovat srovnáním céčkové Luy s LuaJ je těžký nesmysl. Myslím, že to tam i Pavel Tišnovský píše, ale teď jsem líný ten článek číst znova. LuaJ je totiž "přímý" port Luy do Javy, čili implementace virtuální mašiny pro Luu v Javě. Kdyby LuaJ byl překladač do javovského bajtkódu, jako to dělá třeba JRuby nebo Groovy, je jisté, že by byla mnohem rychlejší než originální Lua (a pochopitelně mnohem náročnější na naprogramování ).

[Ivan]

 Kdyz ctu takovyhle prispevky tak si pripadam absolutne menecennej. Vypada to, ze kdyz neumim vyresit memory leak za 10 minut a neznam "Thinking in C++" nazpamet tak vubec nemam pravo programovat. Mezi takovyhle vyvojare se teda neradim, ale presto vyvijim OSS software. 

[jehovista]

Kliiid. Tohle jsou ti echt programatori, kteri sice za dva dny nabastli v Ccku kus deraveho kodu ale ten kod je porad pomalejsi nez kdyby to nejaka ta "cvicena opice" napsala za pul hodky v jave :)

[...............23]

Btw. kecy o rýchlosti vývoja v Jave sú na tom podobne ako kecy o jej pomalosti - trocha pravdy na tom je, ale výrazný rozdiel je tam len v špecifických prípadoch...

[A]

A taky rychly program to bol... :(

[Lukáš Zapletal]

Blender byl delan v Pythonu, ktery je nekolikrat pomalejsi nez Java. Pravda, startuje o neco rychleji, ale...

[JS]

Nevim, jestli to byl vtip nebo ne, ale Blender je samozrejme napsany v C++, v Pythonu je jenom skriptovaci API, kde na rychlosti tolik nezalezi (protoze to hlavni, jako renderovani a vykreslovani, se dela z C++).

[...............23]

A to je akože na čo dobré? Keby namiesto toho radšej nakódil niečo užitočné. Takto ho to po chvíli prestane baviť, vysere sa na to, a ďalšia kopa mŕtveho kódu je na svete...

[bash]

Přesně. U projektů jako tento mi hlavou proběhne jen velké "PROČ?" ...

[mirec]

Ach dokážem pochopiť všeličo ... ale prečo portovať program, ktorý skvele (a veľmi rýchlo) funguje do Javy? Mať dve paralelné verzie v rôznych jazykoch (jeden kvôli tomu aby cvičené opice moderní programátori mohli do toho niečo naprogramovať) je absolútne kontraproduktívne. Fakt moc nemusím programy, ktoré sa rozdelia, jeden bude vedieť nieč, druhý niečo iné, žiaden z nich poriadne ...

[freshmouse]

1) Nauč se číst a přečti si sám, k čemu je to dobré.

2) Tento program užitečný je; až vykonáš domácí úkol z bodu 1, pochopíš.

3) Jestli ho to přestane bavit, je to jeho věc. Nechceš, nepoužívej, nikdo tě nenutí.

[...............23]

1) Pár dôvodov tam má, ale z toho 2 sú "niečo sa na tom naučím" (čo je síce dobré, ale to neznamená že je to užitočné aj pre ostatných), tretí je veľmi slabý a špekulatívny a štvrtý je podľa mňa nezmysel, pretože človek, ktorý má dostatočný skill na prispievanie do projektu ako je Blender, to je schopný spraviť prakticky v ľubovolnom programovacom jazyku.

2) viď bod 1, aj keď ako vec na učenie a hranie sa pre autora je to dobrá vec, proti tomu nič nemám

3) tak ale skritizovať to snáď môžem. Teba tiež nikto nenúti čítať moje príspevky, môžeš ich jednoducho blokovať.

[Ladicek]

Jedno kliknutí a pár odstavců textu. Je to moc? Táži se: je to moc, pro neurvalé kverulanty vašeho typu? JE TO MOC?

[...............23]

Keby si tam klikol, tak by si si všimol že som to nielen prečítal, ale aj okomentoval...

[Ladicek]

Komentáře obvykle nečtu, takže toho jsem si samozřejmě nevšiml Všichni ostatní to mimochodem komentují úplně opačně (great work, awesome, fantastic, interesting project), dokonce jeden z pochvalných a konstruktivních příspěvků zní jako od nějakého vývojáře Blenderu.

Nicméně to opět výborně ilustruje jednu věc: absolutní nepochopení skutečnosti, že lidi ve svém volném čase zcela přirozeně dělají právě to, co je baví, a neexistuje způsob, jak to změnit. Že výsledky svojí práce dávají veřejně k disposici je k téhle lidské přirozenosti zcela ortogonální.

[microcz]

stalo by za zminku uvest, ze porty je mozne vytvaret diky tomu, ze si dal Jeroen Bakker ( www.atmind.nl/blender/mystery_ot_blend.html )  tu praci s vytvorenim specifikace pro blend file, na jeho zaklade jsem cca pred 4 mesici vytvoril port pro C++ a OpenGL jako soucast sve bakalarske prace, ale to jen tak na okraj.

 

[microcz]

ale musim uznat ze autogenerovani DNA struktur blend souboru diky genericite javy ma neco do sebe, v tomhle pripade uznavam ze java ma pro podobnou ulohu jista pozitiva, jen by bylo slusne pana Bakkera, ktery stravil mnoho casu vytvarenim specifikace citovat ve svem dile

[kyknos]

apage satanas

[balki]

Zasa diskusia o nicom. Ti, co tvrdia, ze java je pomala, by mali prestat pouzivat verziu 1.2 a svoje pp06-ky uz konecne zahodit do kybla  :-/

[ted]

přesně... java je tak rychlá, že to prostě monitory nestačí vykreslovat...