Portál AbcLinuxu, 2. května 2025 17:35
while(! konec){
aktualizuj_model_sceny();
renderuj_screen_do_bufferu();
prohod_buffery();
}
A to opravdu sezere veskery vykon procesoru at to piste v cemkoli.
A co se trhani tyka .. proste to nestiha (alpha blending a antialiasing si zadaji sve) - coz ovsem nestihaji ani nativni C dema (viz gl 2D xscreensaver renderovany pres MESA), pokud nemaji k dispozici HW akceleraci.
-server, jsem zvedav, jak se to projevi na vykonu 
.
Malý testík -- mám dva miniprográmky, které se připojí na můj MySQL server spustí jeden (stejný) SELECT, uvolní zdroje a skončí -- jeden v C, druhý v Javě. Ten v C běží při opakovaném spouštěním (time mysql_pokus) asi real 0.004 s, Ten v Jave asi real 0.52 s). Věřím, že většinu času zabere start JVM a samotný kód se vykoná už vcelku rychle. Ale ošetřování vyjímek, tvorba objektů, volání virtuálních funkcí je prostě _pomalejší_ než volání běžných funckí, kontrola návratových hodnot apod.
Program je sice v Javě hezčí, lépe se spravuje a dodává se mu nová funkčnost, ale platí se za to.
Nicméně -- nic proti Javě -- osobně ji mám rád a s potěšením kvituji, že takový jazyk je (JSP, aplety, java.net.*).
| Test | GCC | SUN | SUN -server | SUN -client | IBM |
| Composite score | 301.74 | 118.5 | 170.3 | 137.3 | 230.9 |
| FFT | 257.26 | 57.6 | 131.9 | 58.0 | 190.5 |
| SOR | 272.17 | 247.8 | 240.1 | 273.9 | 267.6 |
| MonteCarlo | 91.0 | 24.2 | 45.8 | 24.3 | 55.6 |
| Sparse matmult | 393.61 | 63.2 | 109.1 | 130.5 | 220.2 |
| LU | 494.69 | 199.6 | 324.3 | 199.7 | 420.5 |
Verze 1.5 má mít rozsáhlou podporu procesorů AMD Opteron.
| Test | ICC | GCC | SUN | SUN -server | SUN -client | IBM |
| Composite score | 524.6 | 493.3 | 189.7 | 436.2 | 195.5 | 390.3 |
| FFT | 306.0 | 281.3 | 49.6 | 249.0 | 73.1 | 261.6 |
| SOR | 582.2 | 365.0 | 324.6 | 601.4 | 324.5 | 360.6 |
| MonteCarlo | 58.1 | 136.3 | 37.4 | 58.2 | 41.1 | 63.6 |
| Sparse matmult | 593.1 | 782.5 | 126.0 | 404.7 | 127.8 | 373.5 |
| LU | 1083.6 | 901.2 | 410.6 | 868.0 | 411.2 | 892.1 |
.
Muj zaver je, ze az bude mit java dostatecne kvalitni (rozumej rychle) knihovny pro praci s GUI tak bude pouzitelna i pro normalni programy a ne jen na server, nebo jednoucelove konzolove aplikace.
pro gcc jsem pouzil tyto parametry:
-O3 -ffast-math -fomit-frame-pointer -march=athlon -mcpu=athlon
Na stroji v tu chvili nebezelo nic jineho, co by mohlo zatezovat CPU a swap byl vypnuty. Kazdy test jsem udelal 2x a vysledna hodnota je prumer.
3.10.2003 13:03
CIJOML | skóre: 58
| Praha
3.10.2003 13:16
CIJOML | skóre: 58
| Praha
3.10.2003 13:29
CIJOML | skóre: 58
| Praha
3.10.2003 14:13
CIJOML | skóre: 58
| Praha
Kdyby se tým rozhodoval takhle, tak bude dodnes programovat v pascalu, protože učit se nový jazyk by se během nejbližšího projektu nezaplatilo.
Sam pouzivam Javu na desktopu i serveru uz hezkych par let, stejne jako se profesionalne venuji programovani v tomto jazyce (takze jsem "zaujaty"). Rozhodne si nemyslim, ze se Java vykonostne vyrovna reseni v kompilovanem jazyce. Je skvele, ze se ten rozdil kazdy rok snizuje, ale existuje.
Podle mne je nejvetsim problemem narocnost na pamet. I ta nejmensi aplikace zabira nekolik megabajtu, co teprve XML editor XXE ci moc hezke IDE IntelliJ IDEA? To jde do desitek mega. I kdyby samotny beh byl srovnatelne rychly, tak naroky na spravu pameti budou Javu vzdy srazet dolu.
JDK 1.5 ma pry prinest sdileni VM, takze kazda nove spustena aplikace nebude vyzadovat novy VM. To bude fajn, ale stejne - Sun by se mel spise nez na pridavani novych vlastnosti soustredit na snizeni narocnosti na pamet. A dalsi optimalizace na rychlost. (Nove jazykove vlastnosti jako generics vypadaji skvele a uz se na ne tesim).
Nicmene abych se vratil zpet, tak hlavni bodem je efektivita programatora a ta je IMHO v Jave nejlepsi. Proto se velka cast serverovych aplikaci realizuje prave v ni. Vsichni, kdo mame mobil nebo bankovni ucet, jsme de facto uzivateli Javy. Oskar, Eurotel, T-Mobile - Java. Pocet bank (s castmi nebo celymi IS implementovanymi v Jave) take rychle roste. Na strane serveru Java dominuje, to je fakt (tim nemyslim SMTP, HTTP apod, ale enterprise reseni).
To ovsem neznamena, ze Java je nejlepsi jazyk a ostatni jsou spatne. Napriklad jsem rad, ze KDE ci Mozilla neni napsano v Jave Kazdy pouzivejme, co nam vyhovuje a neurazejme se navzajem, jak to predvadi Cijoml.
BTW, zarovnavani v Pythonu je mozna divne, ale pokud srovnate citelnost s treba s Perlem tak je to naprosto genialni napad.
Hrozne se mi libi cistota navrhu (vetsiny rozhrani java.*). napriklad takovy InputStream ci Collection - parada. I to, ze vsechno je potomkem tridy Object - matne si vzpominam, ze C++ spolecneho predka nema.
Taky se mi libi, ze java developeri (ktere znam) se snazi o sebevzdelavani, hledaji best practices, nasazuji patterny .. Ach jo, kde jsou ty casy 12snap, to byl skvely tym!
Upozornuji na prisny zakaz pouzivani sprostych slov (kam aspon ja "sracky" zarazuju). Takove prispevky budou bez ohledu na relevantnost zbytku textu smazany!
Jinak k tvemu prispevku: pausalne shazujes vsechny javisty do jednoho pytle. Kdyby sis precetl poradne tuto diskusi, najdes tu spoustu reakci programatoru v Jave, kteri tak necini. Takze jsem matematicky dokazal, ze tvuj konstrukt neni pravdivy (dukaz sporem)
* _velmi silna_ a rychla std. knihovna (napr. String ma cca 100 metod, vsechny v C), takze 99% programu vykonavaji rychle C metody.
* binding na vsechny mozny C knihovny
* velka komunita uzivatelu
* docela jednoduse by sel preklad Ruby kodu -> C kod pouzivajici libruby.so -> gcc -> spustitelna binarka (kdyby o to nekdo stal ;)
Rychly start, rychly beh i u hodne slozitych projektu (mam v nem napsany server o nekolika tisici radcich kodu a beha jako vino), opravdu jednoduse rozsiritelny pomoci C kodu (mozne tedy psat cast kodu v Ruby, cast v C/C++), podpora threadu i v DOSu (kdyby o to nekdo stal , atd.
Zda se mi to jako systemovejsi pristup - pouzivat co nejvic knihoven, ktere uz existuji, nez si vsechno psat znovu - pro Javu. Napr. existuje temet 100% binding na vsechny gnome knihovny. A hodne z tech knihoven vam pobezi i na Widlich, takze porad pisete multiplatforme .
). Navic dokumentace (online) a knizek je myslim dost a dost ...
Dokonce s verzi 1.8 je uz i nativni Ruby celkem rychly A stejne pokud by nebyl, je prevod Ruby->extenze_v_C jednoduchy (jak uz tu bylo zmineno).
) ale v praxi se potkávám s výsledky takového programování - s hotovými produkty. A jako systémák vidím, kolik to potřebuje systémových zdrojů a jak rychle to funguje. Stejně tak vím své o čistotě kódu v java aplikacích, se kterými se setkávám. (Jejich tvůrci jsou např. Oracle.) Často je vůbec problém najít odkud se berou vstupní parametry.
Také se potkávám s mnoha lidmi, kteří o sobě tvrdí, že jsou programátoři (v javě) a já přitom vidím jejich kód. Jak snadné je "splácat" pár tříd a nemít ani ponětí o časové či paměťové náročnosti. To vám nemusí souviset článkem, ale dává to další střípek k odpovědi na otázku o rudém praporu. Daň za módnost. Doufejme, že se to časem upraví.
Proto článek beru spíše informativně a z tohoto pohledu autorovi děkuji za dobrý nápad ukázat nové možnosti javy. Rozhodně stojí za to zamyslet se, jak java aplikace urychlit, když jsou opravdu skoro všude kolem nás.
))))))))))
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.