Názory k článku
Bude energie dražší než hardware?

vynikajici clanek, uplne se naskyta otazka, jestli prilisny technologicky boom IT az prilis nenici zivotni prostredi...
rovnez mozna internet i pres svou informacni hodnotu prohlubuje spolecensko-komunikacni propast mezi lidmi, protoze rozhovor v f2f je preci o necem jinem, nez idlovani na irc nebo forech, kde spousta lidi se predvadi a hraji si na neco, co nejsou...

muj novy stroj bude asi via epia, i kdyz bych rad i nejaky procesor s hw virtualizaci, co je energeticky malo narocny (na xen).

taky se mi moc clanek libil...
hlavne nerikejte nic pred panem prezidentem....

Clanek ujde. Autor se docela trefil, coz nebylo moc tezke, jelikoz se o tom uz delsi dobu hodne diskutuje. Ale co, dal si praci a sepsal to tak, aby to bylo jasne a citelne. Co ale nechapu je tahle oslavna diskuze. Napsat takovy clanek pote co Intel vyda usporne procesory a AMD ohlasi ze s nimi prijde co nevidet, to neni velky kumst.
Nejvic me ale dostal nd. Rekneme si to uprimne, Bursik je relativne mlady politik s urcitymi ekologickymi sklony, ktery se pokousi dat Strane zelenych (svoji) tvar. To se mu ale nepodari, pokud bude delat stejne hloupoucka prohlaseni blizke jeho nedavne narazce na spotrebu reprezentativnich prostor prazskeho hradu. CO si vubec myslel, ze se Klaus chytne za hlavu a da tam vsude zarivky? Tak to by slo misto vsech ambasad co mame v zehranici poridit jen nejake byty (v panelacich) v pronajmu a hned usetrime nejake ty penizky danovych poplatniku. O zelene se ale nebojim, protoze jak vidno, stale budou mit oporu v lidech, kteri si vystaci s jejich "zelenou pozou" a fakta je moc netrapi.
Dovetek: Autor se povazuje za ekologa. Auto nema, pouziva u sebe doma vyhradne "Ackove" zarivky a v zime vytapi s rozumem.

musim odpovedet, ze auto opravdu nemam, a jen tak ho nechci, zarivky jsou skoro vsude, kde to jen jde a nevadi a v zime se u nas topi plynovym kotlem.

no kdyby se topilo jenom rozumem, tak spousta lidi zmrzne ;-)))

Co se tyce hradu, vlady a podobnych uradu, vubec by mi nevadilo je nastehovat do zemljanek. Na to, co v praci predvadi, by jim to muselo stacit.

Nahodou, me se to s temi zarivkami docela libilo. Jednak to bylo takove prijemne osvezeni mezi plky o nicem, jednak si z prezidenta tak trochu vystrelil a ten se na to navic chytil, a jednak si jeste udelal zadarmo reklamu mezi potencialnimi volici. Jako sranda dobry.

Jako sranda dobry, ale jen jestli to jako srandu myslel ...

Jen na okraj. O ekologičnosti zářivky by se dalo dlouze polemizovat.

Klaus není můj prezident. (oficiálně bohužel ano)

Stručný dotaz: ty VIA procesory se tváří jako x86?

Jo, VIA C3 a VIA C7 je i386 kompatibilni

Oblibena fama. CMOV naposledy nepodporovala tusim VIA Samuel, coz je tak 5 let stary procesor taktovany na max. 800MHz. Sice se jeste da koupit, ale nepocitam ze byste si ho daval do cehokoliv jineho nez do nejakeho specializovaneho embedded zarizeni kde si stejne budete kompilovat a optimalizovat vlastni binarky.

Od VIA Nehemiah (a nejspis uz od VIA Ezra) cili to co se bezne prodava jako VIA C3 je v procesoru uplna i686 instrukcni sada vcetne CMOV, MMX a SSE a od VIA C7 ma i SSE2.

Je pravda ze na stejne frekvenci je VIA znatelne pomalejsi nez Intel/AMD, hlavne proto ze ma malou L2 cache (64kB, resp. 128kB u C7). Jenze tim ze je mala cache je mnohem mensi i samotny chip a tim padem to cele vyrazne min zere.

Tohle pisu na notebooku s C7 @ 1.8GHz a rychlost je pro me naprosto dostatecna. 3D hry nehraju, audio / video na tom bezi bez problemu, kompilovani je samozrejme o neco pomalejsi nez u "velkych" CPU, ale zas tak casto kernel nekompiluju abych si nemohl tech par minut navic pockat. A u malych prgramku je mi uplne fuk jesti se zkompilujou za minutu nebo za minutu a ctvrt. Pro desktop / notebook uplne idealni procesor.

Vetsinu casu se CPU stejne flaka na 400MHz a to nejlepsi - baterka mi vydrzi na pet hodin prace i se zapnutym displejem ;-)

Ja jsem premyslel proc treba nedelaji ve velkych serverhousech vymeniky a nevytapi tim okolni ctvrte, protoze stejnak vetsina energie konci v teple. Castecne by se usetrilo za klimatizaci a castecne by se na tom jeste vydelalo. Myslim ze treba casablanca nebo sitel by uz neco zvladly vytopit :)

Problemem je maly rozdil teplot - ony by se ty kompy sice rozzhavili i na nekolik set stupnu Celsia, takze by to odpadni teplo bylo zajimave, ale zase by neplnily svoji hlavni funkci. :P

Ked sa da vyuzit rozdiel teplot v radoch 10-15 stupnov tak sa musi dat vyuzit aj 30-50 stupnove rozdiely.

Ale ovšem, že technicky to jde. Jenom to není dostatečně rentabilní. :(

Tomu neverim, za pouziti tepelnych cerpadel je vyuzitelne kazde odpadni teplo se ziskem, nadto kdyz je jde pouzivat i pri 0stC (cerpani tepla ze vzduchu) nejakych 40-50stC co leze z pocitace je primo balada.

Jdi to navrhnout do Norska, tam by se mozna dalo. V cechach IMHO vetsinu roku musis chladit chladnejsim vzduchem nez je venku, aby se pocitace nezavarili ... a pak se to implementuje blbe.

Mikulas Patocka treba ma doma porad Pentium 200MHz a zadne problemy s energii tak nezapricinuje. A to to pouziva na vyvoj a kompiluje na tom!

V dnesni dobe frci Java, .NET, C#, Perl, Python a jine neefektivni programovaci jazyky, ktere jsou zde proto, ze programatori jsou prilis lini nebo blbi na to, aby se naucili davat si pozor, jestli na kazdy malloc pripada prave jeden free.

Software se taky navrhuje s ohledem na to, aby se to programatorovi snadno navrhovalo, a ne aby to rychle bezelo. Misto aby 1 programator vykonal dusevni praci, ktera zivotni prostredi nezatezuje, vykonaji pocitace vsech uzivatelu praci elektrickou, ktera zivotni prostredi zatezuje.

Kdyz poustim takove hruzky jako OpenOffice nebo Firefox, trva to neskutecne dlouho nez to nabehne, a pritom to pri tom startu nic nedela, jen zbytecnou byrokracii (resi vykonstruovane problemy ktere vznikly jako vedlejsi efekt navrhu). Neni divu ze to pak uzivatele motivuje k tomu, aby si koupil rychlejsi pocitac.

Proc se navrhuje s ohledem na snadnost programovani a ne s ohledem na rychlost exekuce? Protoze cas programatora je drahy (rozumej: obe ruce ma leve a jdou mu dozadu). Cas programatora ale z hlediska Zeme nic nestoji - trochu jidla pro 1 cloveka. Horsi je to uz s tou exekuci - tam se to nasobi poctem pocitacu a skody na zivotnim prostredi to dela.

Jenze penize nereflektuji skutecne naklady co to stoji pro zivotni prostredi, ale jakousi umele vykonstruovanou metriku lidi, kteri ziji v iluzi hodnotoveho zebricku falesnych hodnot.

Kdyz se lidi budou ridit iluzorni motivaci penez namisto realnou motivaci skutecnych problemu, splacou nad vydelkem - znici si zivotni prostredi a prijdou na to az pozde, nez aby se neco dalo zachranit.

Sam jsem programator a souhlasim jen castecne. Jde o to, ze prave za pomoci modernich a jednoduchych nastroju uz dela programatora kdekdo a pak to tak i vypada.
Znam prase, co jsou naprogramovalo v jave ulohu porovnani dvou tabulek v databazi tak, aby se daly proste zaznamy sesynchronizovat (nebudu zde psat detaily o co slo). Kazda ta tabulka ma zhruba 10000 zaznamu priblizne po 100B. To porovnani trva na 2GHz Pentiu asi 10 minut a sezere pres 1GB pameti.

porovnanie obsahu dvoch array (nie table) bola svojho casu bezna otazka na vysokej skole, a toto bol najjednoduchsi sposob ako to vyriesit.

nezavidim firmam ktore si nemozu dovolit kvalifikovane pracovne sily ale musia zamestnat takychto cerstvych studentov. robil som v spracovani velkych objemov a viem o com hovorim.

Bingo, programatori maji na svedomi vyhynuti blbouna nejapneho, ozonovou diru a slunecni erupce :) Asi pujdu programovat na ekologicke kulickove pocitadlo.
BTW v cem programovat rozsahle distribuovane systemy? Treba pro Javu existuje velky pocet frameworku, ve kterych je vyvoj daleko rychlejsi a kod se dobre udrzuje a rozviji. Cena prace programatora je pak daleko nizsi to si myslim, ze i s tou "ekologickou zatezi".

Ta Java vubec nemusi byt pomala, kdyz pobezi na HW ktery zvladne nativne jeji bytecode. Jiste, je tam neco navic, co sezere garbage collector, na coz zrejme narazite s tim malloc and free (a v jadru mate pravdu), ale to nemusi byt az takovy problem. Samozrejme, pouzivat ji na tu ulohu s databazi, co je popsana o prispevek vedle, je mirne receno masochismus ;-))

Co se tyce vykonu jako takoveho, osobne delam mimo jine i vizualizace a mit 10x vykonejsi stroj, tak stale jeste budu rvat, ze je to moc pomale. A s vyssim dostupnym vykonem budu spis zvedat kvalitu vystupu, kde stale jeste jsou rezervy. Takovych aplikaci je jiste mnohem vice.

Co se tyce (Open|M$|...)Office, souhlasim, poustet takovou obludu jenom proto, aby clovek napsal dopis nebo technickou zpravu je divokost, v LaTeXu se takova vec s vyssi kvalitou vystupu da zvladnout i na 386tce (jasne, clovek se s tim musi trochu naucit zachazet, ale to ostatne s tim office taky, jinak je to obluda navic vzpurna a neposlusna).

Jo, a zapomnel jsem na hlavniho tahouna rustu vykonu: hry a zase hry. Na ty je take jakekoliv dostupny vykon malo a kdyz se objevi vic, tak se objevi tez lepsi a dokolalejsi hry, ktere narust spolehlive vyuziji.

Samozrejmne ale nijak nezpochybnuji potrebu se venovat i otazce prikonu procesoru apod, kdyz uz nic jineho, tak je take znacny rozdil mit na tole rvouci obludu s deseti vetraky nebo tichy strojecek s pasivnim chlazenim, i kdyz clanek byl myslen asi spis z globalnejsiho hlediska ... je to mimochodem hezky priklad, jak vznika tlak ne setreni zdroju a prostredi na ciste ekonomice bazi, bez jakychkoliv umelych zasahu, proste se ty kWh musi nekde vyrobit, odberatel je musi zaplatit, tak se logicky snazi, aby jich spotreboval co nejmene ;-).

Mylite se. Dnes to funguje tak, ze hra se objevi na trhu jeste pred HW doporucenym pro jeji beh.

mno existuje, ale jen zakladni komponenty staly pred 2 tydny 45k s DPH :-) a prikon pri hrani je 500-550W bez displaye

A v čem bys tu úlohu databází chtěl psát?
Vynechme teď možnost nějakého skriptu na straně databáze, protože předpokládám, že to jsou dvě fyzicky oddělené DB.

No asi v C, ale jak o tom premyslim, tak by mi to dalo o dost vic prace a ten vysledek by mozna az tak o moc rychlejsi nebyl .. a navic, jestli to porovnani zere tolik pameti, co pise, tak tam mozna byla jina chyba, nez ze to bylo v Jave ...

Asi nerozumiem. Poznas nieco co dokaze bezat java bytecode nativne? Od java procesorov sa uz davno upustilo. Preto existuju JIT kompilatory ktore kompiluju bytecode na nativny kod. A prosim uz si to vsetci prepiste v hlavickach: "Java vdaka runtime optimalizacii bezi rychlejsie ako C/C++ (pretoze optimalizator pre C obsahuje iba staticku optimalizaciu)". Nove VM obsahuju paralel garbage collector a mnohe ine vychytavky. Kto bastli nieco v C/C++ okrem kernelu je podla mna mierne povedane, mimo. Naco mam zabijat svoj cas nahananim pamate ked mame prostriedky ktore to zvladnu za mna a bez problemov. Nie jazyk je zodpovedny za za zly program ale programator.

Doufám, že se už přestane lhát a přestanou se tvrdit nesmysly stylu, že Java běží rychleji, než C/C++. Vážený Paľo, buď to prakticky dokažte nejlépe nějakým testem, nebo raději mlčte a neplácejte. Já sám jsem prošel řadu testů Java versus C/C++, kde občas vycházela úžasná rychlost Javy a po nahlédnutí do zdrojáků C/C++ části jsem pochopil, že jediné co test dokázal, že autor testu v C/C++ psát neumí a měli mu urazit ruce za tu prasečinu, kterou prezentoval pod C/C++. On si každý javista mylně myslí hned, že umí psát v C++, sebevědomí javistům nikdy nechybělo. Dokonce jsem na tohle téma napsal článek:

http://www.abclinuxu.cz/blog/miloslavponkrac/2005/12/6/112210

Takže skutečná pravda je, že dobře napsaný program v C/C++ musí být už z principu rychlejší (max. stejně rychlý), než Java. Navíc si přiznejme, že nejenom že bude program v C/C++ rychlejší, ale on bude i rychleji startovat, a sežere tak třetinu paměti a mnohem méně zdrojů počítače, než ekvivalentní program v Javě.

Jinak programoval jsem v C++ přes deset let a o uvolňování paměti jsem se téměř nikdy nestaral. Od té doby co má C++ automatické pointery, různé chytré ukazatele, probíhá automatická destrukce objektů atd.. si už ani nepamatuji, kdy jsem se posledních několik let musel starat o uvolňování paměti. Já vlastně žasnu, když javisti tvrdí, že v C++ se musím starat ručně o uvolňování paměti, když nemusím. Přiznám se, že teď jsem skoro musel kouknout do manuálu jak se vlastně uvolňuje paměť v C++, protože jsem to už několik let nepoužil a to jsem v C++ psal velmi mnoho. Prostě stav prakticky ekvivalentní garbage collectoru. Nehledě na to, že když budu chtít, i pro C/C++ existuje garbage collector, ale on vlastně není potřeba.

Osobne si myslim, ze nie je podstatne porovnavat vykon Java vs C++, ako skor spravne odhadnut potrebu pouzitia daneho jazyka na ulohu, ktoru riesim. Pride mi to rovnake ako porovnavat Aviu a Octaviu - na Avii sa zle chodi do roboty,no na druhu stranu pri stahovani bytu je Octavia castokrat uplne nepouzitelna.
Mne osobne sa na Java vzdy pacilo, ze sa zbavila mnohych vlastnosti, ktore umoznuju 'skraslit' a 'skomplikovat' kod v zlych rukach natolko, ze jeho spatne citanie cudzou osobou je takmer nemozne. Ako priklad by som uviedol preprocesor. Raz som riesil otazku, ktora cast kodu v hlbokom strome ifdefov sa vlastne kompiluje a najjednoduchsim riesenim sa nakoniec ukazalo pridavanie #error direktivy priamo do codu :-D Musim, ale uznat, ze vysledny kod na rozdiel od java, bol urcite mensi!
Som zastancom optimalizacie algoritmov a nie kodu. Posledne som po znacnych upravach dosiahol, ze spracovanie na mesacnej baze trvalo len 1 minutu, no pre celkovy cas to nebolo az tak podstatne, nakolko zvysne 2 hodiny sa vysledky 'tlacili' do databazy. A tu sa urcite zhodneme, ze v takomto pripade by mi C++ neprinieslo ziadne vyhody.
Este malu poznamku na temu garbage collection. Ja by som tu chcel skor zdoraznit, ze podstatna je filozofia jazyka. Javista je nauceny vytvarat objekty a potom sa o ne nestarat, co urcite vedie k vacsim narokom na spotrebu pamate, no na hruhu stranu prave v daka tomu je javovy kod menej nachylny na jej fragmentaciu. Mozno aj preto zvycajne nie prave idealne napisany server v java, je schopny mat dlhsi uptime ako podobny eqvivalent v C++.
A este jednu poznamku k povodnej teme. Urcite je pozitivne, ze vyrobcovia HW si uvedomili vyznam setrenia el. energie. Ono aj ten koder znacnu cast prace so silnym CPU len pise par uderov za minutu a vtedy je nahanat 3GHz CPU bohapustym plytvanim. Na druhu stranu existuju pripady, ked je cena za sluzby programatora podstatne vyssia ako celozivotna spotreba 1ho az 2och serverov, kde bude aplikacia pracovat. Potom je jasne, ze Google, ktory si moze platit programatorsku elitu, ktora je schopna 'vyrazit' aj z lacneho HW vysoky vykon bude hladat odpoved na otazku:"Preco 1/2 miliona serverov zere 2M $/mesiac?" Kolko je ale vo svete projektov, kde pracuje 50 ludi na aplikacii, ktora nakoniec naozaj bude realne pracovat v jednom, mozno dvoch nasadeniach?
Osobne by som rad podobnu statistiku videl...

Já s Vámi souhlasím, akorát mi přijde dost ubohé, když javista napíše něco o rychlejší javě, než C++ a ještě to ztuční.

Nemám nic proti Javě, ale když už se bavíme, mě se naopak filozofie jazyků, které škrtnou vše co by snad někdo mohl špatně použít naprosto nelíbí. Protože pak takový jazyk stejně dojde k tomu, že se algoritmy ohýbají pro něho, a že se všechno nějak emuluje aby se to v tom jazyce dalo napsat a v Javě to je až moc vidět.

Ono srovnání Javy a C++ se dělá jen proto, že Sun má komplexy z C++. Přitom C++ se s Javou srovnávat nedá. C++ je kompilátor do strojáku, Java je původně interpret (nechytejte mě za slovo JITem, to je jen jiný způsob interpretace). C++ je rychlý, efektivní, nenáročný, Java dává několik abstrakcí typu gc a spol.. Atd..

Problém javy při použití na běžné servery oproti C++ je ten, že C++ má počítač víc v rukou. Třeba ošetřit některé věci, jako je možnost zotavení se a běhu při nedostatku paměti, nebo vyčerpání místa na zásobníku lze v C++ provést, v javě to prostě padne bez možnosti programátorem to ovlivnit.

Takze mna napadate ze neviem nic o C++ ale z toho co ste tu napisali je jasne ze VY neviete nic o Jave.

algoritmy ohýbají pro něho

Co take pre implementaciu ktore algoritmu Vam v Jave chyba?

C++ je kompilátor do strojáku, Java je původně interpret

Tymto co chcete povedat? Povodne bol interpreter. Dnes kazda normalna JVM obsahuje JIT alebo sa kod nativne kompiluje (GCJ).

že C++ má počítač víc v rukou

Asi tak isto ako v Jave. Mimochodom nakukli ste napriklad do balika java.util.concurrent.atomic. V C++ dokazete aby pocitac urobil salto alebo prepisat kernel memory. Lebo nic ine co by Java nevedela ma nenapada.

třeba ošetřit některé věci, jako je možnost zotavení se a běhu při nedostatku paměti, nebo vyčerpání místa na zásobníku lze v C++ provést

Tak a toto je vrchol. Dostudujte si podtriedy triedy RuntimeException. Este Vam davam do pozornosti setUncaughtExceptionHandler v triede Thread (ale to je iba pre advanced programatorov ;-) ). Tiez nemam rad ked niekto kto robil v C++ si mysli ze Java je len take orezane C++. Nie vsetko v Jave je take jednoduche ako to vyzera. Ten stroj ma svoje systemove vychytavky. Co napr. sandboxing, security (vo vyzname permissions nad vasim kodom napr. RuntimePermission). Ako si ste pozabudli na to najdolezitejsie a to ze Java dotiahla to co C/C++ slubovalo od zaciatku - prenositelnost. Iste sa da urobit prenositelny kod aj v C++ ale musite sa o to postarat. V Jave sa velmi tazko pise neprenositelny kod.

A to ze Sun ma komplexy s C++? Velmiiiiii zabavne. Asi si odlozim aj linku aby som to mohol ukaz niekomu zo Sun-u. Asi pukne smiechom. Este aj teraz sa mi trasie notebook na kolenach.

Co take pre implementaciu ktore algoritmu Vam v Jave chyba? V Javě nechybí na implmentaci algoritmu nic, neboť jak je z teorie známo, na implementaci všeho stačí podmíněný skok. Ale je to pak poněkud nudné psaní. Aby bylo jasno, já jsem nepsal, že v Javě nejde něco napsat, takže nic mi nechybí, jen jsem psal, že se to musí ohýbat. Tymto co chcete povedat? Povodne bol interpreter. Dnes kazda normalna JVM obsahuje JIT alebo sa kod nativne kompiluje (GCJ). Tím chci říct, že Java a C++ jsou nesrovnatelné. C++ přeci jen kompiluje do strojáku přímo. JIT není kompilace, JIT je normální způsob, jak interpretovat jazyky. Nebo snad chcete říct, že zkompilovaný java soubor je nativní stroják? GCJ je sice kompilátor, ale není to původní záměr jazyka a sám GCJ se musí uchylovat k interpretaci, neboť se musí počítat s dynamic load class. Asi tak isto ako v Jave. Mimochodom nakukli ste napriklad do balika java.util.concurrent.atomic. V C++ dokazete aby pocitac urobil salto alebo prepisat kernel memory. Lebo nic ine co by Java nevedela ma nenapada. Tak napište v Javě ovladač pro linux kernel :-) Opravdu si myslíte, že dokážete naprogramovat, aby java program ošetřil nedostatek paměti v JVM a přežil to? To jste první na světě. Tak a toto je vrchol. Dostudujte si podtriedy triedy RuntimeException. Este Vam davam do pozornosti setUncaughtExceptionHandler v triede Thread (ale to je iba pre advanced programatorov ;-) ). Hm, ok, znovu říkám, jestli si fakt myslíte, že ošetříte v Javě všechno, zkuste si to. Tiez nemam rad ked niekto kto robil v C++ si mysli ze Java je len take orezane C++. Kde to tvrdím? Nie vsetko v Jave je take jednoduche ako to vyzera. Ten stroj ma svoje systemove vychytavky. Co napr. sandboxing, security (vo vyzname permissions nad vasim kodom napr. RuntimePermission). Já to Javě neupírám. Všimněte si, že celá tato debata vznikla na základě Vaší lži o tom, že Java je rychlejší, než C/C++. Ako si ste pozabudli na to najdolezitejsie a to ze Java dotiahla to co C/C++ slubovalo od zaciatku - prenositelnost. Iste sa da urobit prenositelny kod aj v C++ ale musite sa o to postarat. V Jave sa velmi tazko pise neprenositelny kod. Programoval jsem dost pro mobily a o přenositelnosti Javy mohu říct jediné - neexistuje. Co jiný typ mobilu, to se musel Java program přepsat, nebo upravit. Zatímco třeba v Symbianu, což je C++ byla přenositelnost na mobilech 100%. Ale to jen tak na okraj. Přenositelnost je něco co není až taková specifika Javy. Třeba u Pythonu se mi přenositelnost zdála vyšší. A to ze Sun ma komplexy s C++? Velmiiiiii zabavne. Asi si odlozim aj linku aby som to mohol ukaz niekomu zo Sun-u. Asi pukne smiechom. Este aj teraz sa mi trasie notebook na kolenach. Smích prodlužuje život :-)

jen jsem psal, že se to musí ohýbat

Dobre detailista: "Co musite v Jave ohybat oproti inym jazykom?".

snad chcete říct, že zkompilovaný java soubor je nativní stroják

Ano niektore kompilatori generuju nativny kod do suboru. Ine (JIT) az neskor v pamati ale je to nativny preklad do strojoveho kodu.

GCJ je sice kompilátor, ale není to původní záměr jazyka

Jazyk Java nema ziadny zamer v tejto oblasti. Je mu to uplne jedno ci sa kompiluje do pamate alebo do suboru.

Opravdu si myslíte, že dokážete naprogramovat, aby java program ošetřil nedostatek paměti v JVM a přežil to?

Samozrejme, presne tak isto ako v C++. Musim nieco uvolnit (ustrelit napr. nejaku sesssion). Nas Java server to vedel. Pripadne treba pouzivat soft pointre. Mimochodom J2EE servre pouzivaju aj vacsie triky (napr. kaskadne ClassLoadre aby vedeli nahrat rozne verzie tej istej triedy pripadne reloadnut novu verziu bez restartu JVM)

jestli si fakt myslíte, že ošetříte v Javě všechno, zkuste si to.

Velmi jednoducho. Okolo volania ineho kodu urobim catch(Throwable th). Skuste si to.

Java je len take orezane C++. Kde to tvrdím?

Priamo nie len ste na nas zacali hovorit akosi "s patra". Java zo svojimi kniznicami predbehne cokolvek co ste kde videli. Idealne prostredie pre programatora ktoremu ide o vysledok.

Všimněte si, že celá tato debata vznikla na základě Vaší lži o tom, že Java je rychlejší, než C/C++

Iste len medzitym ste ju VY zaviedli niekam inam.

Už je noc, takže odpovím na vše třeba zítra, ale v rychlosti.

Ano niektore kompilatori generuju nativny kod do suboru. Ine (JIT) az neskor v pamati ale je to nativny preklad do strojoveho kodu.

Řekněme, že Java na ten nativní překlad není tak úplně připravená.

Jazyk Java nema ziadny zamer v tejto oblasti. Je mu to uplne jedno ci sa kompiluje do pamate alebo do suboru.

řekněme, že Java byla vyvíjena jako interpretovaná. Dovolte mi to tedy nazvat záměrem.

Velmi jednoducho. Okolo volania ineho kodu urobim catch(Throwable th). Skuste si to.

To prostě nefunguje, není schopno se to zotavit ze všeho co dokáže C/C++/Asm, vyberte si co libo.

Priamo nie len ste na nas zacali hovorit akosi "s patra". Java zo svojimi kniznicami predbehne cokolvek co ste kde videli. Idealne prostredie pre programatora ktoremu ide o vysledok.

Víte z patra mluvím kvůli Vašim reklamám. "Java se svojmi kniznicami predbehne atd." je jen abstraktní nekonkrétní blábol. Stejně tak věta "Idealne prostredie pre programatora ktoremu ide o vysledok." je druhá reklamní věta, tedy druhý abstraktní nekonrétní blábol. Když třeba mým výsledkem má být rychlý nenáročný program, určitě Java nebude ideální prostředí. Prostě mě štvou lidi, kteří nenápadně manipulativně vkládají věty a nenápadně programují podvědomí pomocí oslavných hesel, která se prostě při bližším zkoumání ukáží ne zcela pravdivá, či v pořádku. A Vy to děláte na můj vkus až příliš často do textu, který má jasně a konkrétně argumentovat. Nezlobte se.

Řekněme, že Java na ten nativní překlad není tak úplně připravená.

Akoze nie je pripravena ked ju ma?

Java byla vyvíjena jako interpretovaná

A C ako jazyk pre salove pocitace. Nebavime sa o historii ale o stave Java vs C/C++ 2.11.2006.

není schopno se to zotavit ze všeho co dokáže C/C++/Asm

Uvedte priklad. O dva prispevky nizsie som dal OutOfMemory handling. Inac je vas postreh tiez iba nepodlozeny blabol.

Když třeba mým výsledkem má být rychlý nenáročný program

Ziadne take zadanie nikdy neexistuje (taketo zadania si vymyslaju programatori). To nema pridanu hodnotu. Mna zaujima co program robi nie ako to robi. Aj ked samozrejme mal by to robit najefektivnejsie ako sa da.

Akoze nie je pripravena ked ju ma?

Nalepit a dobastlit můžete věci i na něco co na to není připraveno.

A C ako jazyk pre salove pocitace. Nebavime sa o historii ale o stave Java vs C/C++ 2.11.2006.

C nebyl vyvíjen jako jazyk pro sálové počítače, ale jako jazyk pro přenesení operačního systému. A jak C, tak Java dostali do vínku určité vlastnosti, kterých se prostě nezbaví ani v roce 3000. Přiznejte si, že C je na překlad do strojáku vybaveno poněkud více.

Uvedte priklad. O dva prispevky nizsie som dal OutOfMemory handling. Inac je vas postreh tiez iba nepodlozeny blabol.

Který ovšem závisí na tom, zda se podaří uvolnit nějakou další paměť pro obsluhu výjimky. Jak má tenhle stav, zda bude k dispozici další paměť v libovolném místě možnost ovlivnit programátor Javy?

Ziadne take zadanie nikdy neexistuje (taketo zadania si vymyslaju programatori). To nema pridanu hodnotu. Mna zaujima co program robi nie ako to robi. Aj ked samozrejme mal by to robit najefektivnejsie ako sa da.

Tak tohle komentovat nebudu. Pokud popíráte, že existují úlohy kde přímo v zadání je nutnost rychlosti, tak jste demagog. Chcete snad říci, že třeba databázové systémy ala Oracle nejsou programované s ohledem na maximální rychlost práce s daty? Že zákazníkovi je jedno, jestli ta datová operace skončí za sekundu, nebo za 10 let? Že 3D grafika nemá přímo v zadání maximální rychlost operací? Že kódování videa dlabe na rychlost? Ano, máte pravdu, nikoho rychlost nezajímá, to si vymýšlejí jen paranoidní programátoři, kteří nesnášejí Javu. Fajn, a tu o Červené Karkulce znáte? A dotaz? Věříte ještě na Ježíška a na Bílou paní?

Nalepit a dobastlit

Ak myslite to iste dobastlenie ako ja tak je zaujimave za na tom dobastlenom kode behaju velke produkcne systemy.

zda bude k dispozici další paměť v libovolném místě možnost ovlivnit programátor Javy?

O to sa stara JVM a dokonca na vsetkych platformach transparentne.

Chcete snad říci, že třeba databázové systémy ala Oracle nejsou programované s ohledem na maximální rychlost práce s daty?

Ale vsak pisem ze to treba urobit najoptimalnejsie ako sa da. Napr. oracle sa presadil hlavne funkcionalitou nie rychlostou, tam by ich vzdy predbehla DB2. Aj 3D profi grafika sa robi v Jave. Co sa tyka rychlosti pozrite si napriklad Jake. Veci nemusia byt najrychlejsie. Musia byt iba znesitelne rychle a to sa da dnes v Jave dosiahnut. Ak je rozdiel do 30 percent nikoho to zaujimat nebude. Radsej peniaze investuje do lepsieho HW.

Vy mě chytáte za slovíčka. Já bych jen zareagoval, že JVM se stará o paměť transaprentně, tedy programátor nemá jistotu, že může odchytnout výjimku při nedostatku paměti, a že gc bude mít dost paměti na obsloužení této situce. zaručit se to nedá a klidně to v Javě může spadnout, aniž by programátor to mohl nějak ovlivnit. na rozdíl od C/C++ kde lze napsat obsluhu této situace, která funguje na 100%.

Jinak co se týká rychlosti, napsal jste, že rychlost nikoho nezajímá, a že je to jenom výmysl programátorů. 3D grafika se dělá v Javě, ale Java volá vnitřně stejně C/C++ kód, jinak by to nezvládala rychlostně. Já netvrdím, že se všude musí honit rychlost, ale na rozdíl od Vás bych si nikdy neodvážil tvrdit nic o tom, že rychlost není důležitá. A pomocí hw všechno nenaženete.

klidně to v Javě může spadnout, aniž by programátor to mohl nějak ovlivnit

Ale to snad nie. Vsak to je sucast VM. Typujem ze ten kod ktory hovorite v C++ funguje na 100% v tej virtualnej masine je. V jave sa nestaram o mechanizmus akym sa posielaju vynimky (moze byt na kazdej platforme iny). 3D sa robi v kartach nie v C++.

Tipujete nesprávně. Právě to, že se nestaráte o mechanismus znamená, že nemůžete všechno ošetřit a při určitých situacích prostě můžete v Javě jen bezmocně koukat.

Zrovna 3D grafika rychlost casto nepotrebuje. Rozumej, je jedno z jakeho jazyka se vola hardwarove akcelerovana OpenGL funkce ... protoze softwarove by dnesni 3D grafiku neutahnul ani assembler.

Jo lepsi HW ... no to uz jsme zase u tematu clanku a otazce, proc se tepelny vykon kancelarskych pocitacu priblizuje primotopum. No proc, protoze kancelarske programy programuji lidi jako vy (resp. s vasimi nazory) v jazycich jako Java. I kdyz priznejme si, ty lidi za to muzou vic nez ten jazyk.

Chcete rict, ze v dostatecne slozitych scenach muze procesor skutecne byt VYTIZEN (tj. ne jen ze neco dela, ale ze je pozadavek aby to delal rychle) vypocty souvisejicimi se zobrazovanim ? To jsem asi zaspal to nasazeni pixel shaderu, protoze jsem mel pocit ze uz tomu tak neni ...

V takovem pripade samozrejme neni moudre to delat v Jave, ale mam skoro pocit ze by to nikoho z lidi co pisou v Jave ani nenapadlo (viz vase zbuchane engines, nebo mozna doufaji v ten driver karty, ktery je samozrejme psany v nizsim jazyce nez Java).

Mimochodem, predpokladam ze temi OpenGL open source hrami nemyslite ani tu hromadu opensource her, ktere pouzivaji OpenGL na grafiku kterou by komercni hra zvladla na procesoru, ani tu hromadu, ktera je zalozena na uvolnenych enginech komercnich her (jako Quake a podobne), ale neco z toho maleho zbytku ...

... hlavnim problemem OpenGL open source her je kdyz je hrajete bez akcelerace, protoze softwarove OpenGL je na linuxu zoufale pomale. Sekat se i s akceleraci jsem jeste nic nevidel - samozrejme nemluvim o komercnich hrach, o tech nemam prehled.

Ukazte mi open source hru, ktora zobrazuje real time sceny so zlozitostou Half Life 2, Far Cry, Oblivion... :)

Ukazte mi nejakou co je zobrazuje nerealtime. Ja netvrdim, ze open source hry bezi realtime se stejnou slozitosti sceny jako Oblivion. Ja tvrdim, ze vetsina open source her bezi realtime. Muzu explicitne dodat, ze je to proto ze maji mene slozitou scenu nez Oblivion, pokud na tom trvate.

Tak me napada ... co znamena "krepe" ? Prelozil jsem si to jako pomale, ale mozna to je spatne ...

No, na zaciatku bolo tvrdenie, ze CPU dnes prakticky nema s renderovanim ziadnu reziu. Pravda je vsak taka, ze pokial chcete vytazit z hardware maximum (o co sa snazia niektore komercne hry), tak ten procesor do istej miery treba. Podla mojho skromneho game developerskeho nazoru, vam 3D API nikdy nezarucia to najlepsie vyuzitie. Budu poskytovat sadu "nastrojov", ale vzdy budete mat moznost tieto vyuzit lepsie a horsie :)

Pardom, "Krepý" je tazky slang z jednej slovenskej humoristickej TV relacie. V podtate je to univerzalne slovicko pouzitelne na vyjadrenie lubovolneho negativa :)

No uplne na zacatku to nebylo, nicmene explicitne potvrzuji ze tomu verim. Jako vedlejsi poznamku nicmene dodavam, ze to neni hlavni problem pri vyvoji opensource her.

Ano presne tak. Pokial neboli PS, tak nemalo az tak zmysel sortovat objekty v scene (s vynimkou objektov s priesvitnostou), pretoze sa vam to vdaka Zbufferu spravne vyrenderovalo. Brzdila vas len pamatova priepustnost (viacnasobne prekreslenie jedneho pixelu). Dnes ked k tomu pribalite zlozite shadery pocitane per pixel (radovo desiatky instrukcii, vid napr. novy far cry), tak vas pri overdraw brzdi navyse uzke hrdlo v podobe PS jednotiek.

Takze ked mate v leveli tak 300-tisic objektov, tak si naozaj myslite, ze profi hry to rvu vsetko do karty spoliehajuc sa na to, ze sa to "nejako" pretlaci? Tiez treba spravit preprocess v podobe vyhodenia objektov ktore nevidite, treba zosortovat do spravneho poradia objekty s priesvitnostou (napr. particles, ktorych mozu byt na scene naraz tisice) a pod.

Este dodam k predch. reakcii, ze su uz experimentalne implementacie, ktore scenu vyrenderuju "na necisto", bez textur a shaderov, pripadne len bounding boxy objektov, aby sa len zistilo, ktore objekty prejdu Z-testom a ktore nie (karty vedia spocitat, kolko pixelov sa vyrenderovalo per objekt). Ale ziadne sucasne API (DX,OGL) na to nie je dostatocne pripravene, aby vedelo automaticky, bez cakania na vysledok, nerenderovat objekty, ktore nepresli prvym prechodom.

Ziadne take zadanie nikdy neexistuje (taketo zadania si vymyslaju programatori). To nema pridanu hodnotu. Mna zaujima co program robi nie ako to robi. Aj ked samozrejme mal by to robit najefektivnejsie ako sa da. zpracovani dat v realnem case ... napriklad telefonni hovory ... delal jsem okolo toho nejake veci v Jave, tak jsem to prepsal do C++ prave kvuli rychlosti a pak jsem to jeste dal optimalizoval ... pokud si myslite, ze zrychleni o 10% nestoji za praci navic, tak tady byste silne pohorel ... management i zakaznici byli z vyssi rychlosti vskutku nadseni a par mesicu prace za to byla nizka cena ...

Tohle by me zajimalo. Jak presne se v okamziku, kdy dojde pamet, vyrobi objekt ExceptionDoslaPamet nebo jak se jmenuje ?

A umi Java alokaci/swap-in pameti na vypadek stranky ? (C ano, v linuxu i v aplikaci pres SIGSEGV). Myslim naprogramovat, ne jestli to umi JVM.

import java.util.*;

public class A {
private static long j;
public static void main(String arg[]) {
for (int i=0; i < 5; i++) {
System.out.println("Cycle "+i);
j=0;
try {
doAllocation();
} catch (Throwable th) {
th.printStackTrace();
System.out.println("j="+j);
}
}
}

private static void doAllocation() {
ArrayList a=new ArrayList();
while (true) {
j++;
a.add(new byte[1024]);
}
}
}

Cycle 0
java.lang.OutOfMemoryError: Java heap space
j=63645
Cycle 1
java.lang.OutOfMemoryError: Java heap space
j=63648
Cycle 2
java.lang.OutOfMemoryError: Java heap space
j=63648
Cycle 3
java.lang.OutOfMemoryError: Java heap space
j=63648
Cycle 4
java.lang.OutOfMemoryError: Java heap space
j=63609

Ziadna zahada to nie je pretoze pri vystreleni vynimky sa vela objektov oznaci za garbage nakolko su nedosiahnutelne pripadne zariadite aby sa stali nedosiahnutelny v catch tym ze im priradite null hodnotu.
A este naco by som mal ten swap-in programovat?

Takze, kdyz cirou nahodou nic co by se dalo oznacit za garbage neni, tak Java nahodne vybere ten nejdulezitejsi objekt ktery akutne potrebuju pro dalsi beh programu a uvolni ho ? To snad ne.

Kde je napisane ze Java vyberie. Vy ako programator musite vybrat co odpalit.

Prostě to dře a není to moc neprůstřelné. Java nedává prostě možnost programátorovi mít úplnou kontrolu nad touto situací. Tím tohle přestávám dále komentovat.

I prekladace C++ kompiluji nejprve do mezijazyka. Napsat primy kompilator by byl cisty masochismus.

Jenže ten mezijazyk je šit na míru cílovému prostředí a je dělán tak, aby přenášel maximum informací. Ono čistě vzato už parsing zdrojáku je přepis do mezijazyka. :-)

Neni sity na miru cilovemu prostredi. Obvykle je "mezijazyk" (tusim se rika mezikod) crossplatformni. Jenze, nikoho ani nenapadne distribuovat mezikod. Konecne, i vzhledem k jeho velikosti by to byl spatny napad.

No vzhledem k tomu, že už samotné C/C++ má přímo v jazyce (především v extenzích toho kterého konkrétního kompilátoru) platform dependend věci, lze říci, že tyto věci jsou zaneseny také ve formátu mezijazyka. Ale ono je otázka co nazývat mezijazykem.

Samozrejme nezavislosti na platforme myslim to, ze neni zavislejsi nez puvodni C/C++ kod. A samozrejme pro konkretni kompilator to nemusi byt pravda. Podstatne ale je, ze NENI napsan primo na cilovou architekturu, neni "šit na míru cílovému prostředí".

Jak, otazka ? U vetsiny kompilatoru je to jasne specifikovane. Napriklad v pripade gcc se jedna o RTL.

Co take pre implementaciu ktore algoritmu Vam v Jave chyba?

V Javě nechybí na implmentaci algoritmu nic, neboť jak je z teorie známo, na implementaci všeho stačí podmíněný skok. Ale je to pak poněkud nudné psaní. Aby bylo jasno, já jsem nepsal, že v Javě nejde něco napsat, takže nic mi nechybí, jen jsem psal, že se to musí ohýbat.

Tymto co chcete povedat? Povodne bol interpreter. Dnes kazda normalna JVM obsahuje JIT alebo sa kod nativne kompiluje (GCJ).

Tím chci říct, že Java a C++ jsou nesrovnatelné. C++ přeci jen kompiluje do strojáku přímo. JIT není kompilace, JIT je normální způsob, jak interpretovat jazyky. Nebo snad chcete říct, že zkompilovaný java soubor je nativní stroják? GCJ je sice kompilátor, ale není to původní záměr jazyka a sám GCJ se musí uchylovat k interpretaci, neboť se musí počítat s dynamic load class.

Asi tak isto ako v Jave. Mimochodom nakukli ste napriklad do balika java.util.concurrent.atomic. V C++ dokazete aby pocitac urobil salto alebo prepisat kernel memory. Lebo nic ine co by Java nevedela ma nenapada.

Tak napište v Javě ovladač pro linux kernel :-) Opravdu si myslíte, že dokážete naprogramovat, aby java program ošetřil nedostatek paměti v JVM a přežil to? To jste první na světě.

Tak a toto je vrchol. Dostudujte si podtriedy triedy RuntimeException. Este Vam davam do pozornosti setUncaughtExceptionHandler v triede Thread (ale to je iba pre advanced programatorov ;-) ).

Hm, ok, znovu říkám, jestli si fakt myslíte, že ošetříte v Javě všechno, zkuste si to.

Tiez nemam rad ked niekto kto robil v C++ si mysli ze Java je len take orezane C++.

Kde to tvrdím?

Nie vsetko v Jave je take jednoduche ako to vyzera. Ten stroj ma svoje systemove vychytavky. Co napr. sandboxing, security (vo vyzname permissions nad vasim kodom napr. RuntimePermission).

Já to Javě neupírám. Všimněte si, že celá tato debata vznikla na základě Vaší lži o tom, že Java je rychlejší, než C/C++.

Ako si ste pozabudli na to najdolezitejsie a to ze Java dotiahla to co C/C++ slubovalo od zaciatku - prenositelnost. Iste sa da urobit prenositelny kod aj v C++ ale musite sa o to postarat. V Jave sa velmi tazko pise neprenositelny kod.

Programoval jsem dost pro mobily a o přenositelnosti Javy mohu říct jediné - neexistuje. Co jiný typ mobilu, to se musel Java program přepsat, nebo upravit. Zatímco třeba v Symbianu, což je C++ byla přenositelnost na mobilech 100%. Ale to jen tak na okraj.

Přenositelnost je něco co není až taková specifika Javy. Třeba u Pythonu se mi přenositelnost zdála vyšší.

A to ze Sun ma komplexy s C++? Velmiiiiii zabavne. Asi si odlozim aj linku aby som to mohol ukaz niekomu zo Sun-u. Asi pukne smiechom. Este aj teraz sa mi trasie notebook na kolenach.

Smích prodlužuje život :-)

Musim Vam dat za pravdu, ze porovnanie Java a C++ je presne to iste ako porovnavat Linux a Windows... V kazdom tabore su ti, co uznavaju vyhody toho druheho, ale aj ti,co sa budu do 'krvi' snazit presvedcit supera, ze su 'lepsi'.

Osobne nemam pocit, ze Sun ma principialne problem s porovnanim danych jazykov. Dnes je mozne povedat, ze az na par vynimiek je v jave implementovane alebo sa implementuje skoro vsetko,co bezne pri navrhu IS stretavame - LDAP, DNS, databaza, ci webserver alebo mailserver. Povedal by som, ze castokrat je to prave vyhoda, nakolko je rozdiel tlacit data do LDAP z aplikacie, ako pouzit kniznicu LDAPu vnutorne v nej a len mapovat existujuce data. Tu vsak musim uznat, ze nie vsetko sa podarilo, ako napriklad Swing, ktory je pomaly a este aj matie uzivatela svojim specifickym look&feel.

Ja osobne som C++ tak trochu preskocil v profesnom zivote, takze moje znalosti su naozaj len zbytky poznania z minulej dekady. Java mi ucarovala prave svojim zjednodusenim beznych veci. Ci uz je to kontrola buffer overflow, alebo reference counting na objektoch, co dodnes povazujem za jedno z najlepsich krokov vpred (aj ked uznam, ze Java tuto vec pre nas neobjavila). Dodnes si pamatam, ked som sa trapil s tym, ze do black-box modulu(funkcie) pricestoval objekt, ktory som potreboval odlozit a nebolo vzdy jasne, ci musim robit kopiu alebo nie :-)

Smart pointers (ak ich narychlo podla Googla spravne chapem) nie su sucastou jazyka samotneho, ale len urcitou implementaciou kniznice, ktoru clovek pouziva. Z toho vyplyva, ze menej skuseny programator (a budme objektivni, ze kazdy z nas raz zacinal), velmi lahko aj neumyselne bude produkovat zbytocne nebezpecny kod, pretoze to za neho jazyk implicitne neriesi. Koniec koncov, aj implementacia smart pointeru znamena CPU time navyse, takze ostava len otazka o kolko je to v sumare vyhodnejsie.

Myslim si, ze JIT VM ponuka aj ine vyhody (aj ked je mozne, ze v C++ je to tiez implementovatelne alebo sa to aj bezne pouziva) a to je hlavne schopnost zajazdy pridavat kod - hot deploy, alebo schopnost pisat kod 'prezerajuci si' dosle instancie cez Reflection. Skor by som chcel podoknut, ze prave niektore vyrazne nevyhody - ako cas traveny garbage collectingom sa prave dnes s prichadzajucim masivnym paralelizmom aj na zakladnom HW zacinaju stierat (aj ked uznam, ze to stoji prave tu spominanu elektriku navyse)

Este si dovolim jednu poznamku, aj ked link som nevedel narychlo vygooglit. Zachytil som informaciu, ze Intel aj AMD uvazuju o pridani dalsich instrukcii do CPU pre podporu VM ako takych, co by sme samozjreme povazovali este pred par rokmi za scifi rovnako ako dnesnu virtualizaciu CPU. Da sa to povazovat za potvrdenie trendu v programovani?

Java i C++ jsou každý něco jiného.

Smart pointers (ak ich narychlo podla Googla spravne chapem) nie su sucastou jazyka samotneho, ale len urcitou implementaciou kniznice

Smart pointers mají podporu v jazyce C++. Vznikají prostě z toho, že C++ jazyk automaticky uklízí lokální objekty (volá jejich destruktory) a smart pointers toho jenom využívá.

menej skuseny programator (a budme objektivni, ze kazdy z nas raz zacinal), velmi lahko aj neumyselne bude produkovat zbytocne nebezpecny kod

Vlastností jazyka C++ je dát do ruky větší, a tím pádem nebezpečnější prostředky. To je jeho filozofie.

Koniec koncov, aj implementacia smart pointeru znamena CPU time navyse, takze ostava len otazka o kolko je to v sumare vyhodnejsie.

Pozor! Implementace smart pointeru ve většině případů neznamená CPU time navíc, protože to kompilátor zoptimalizuje. Výhoda je v tom, že se uvolní vše: paměť, i další zdroje systému. Je to víc, než gc.

Myslim si, ze JIT VM ponuka aj ine vyhody (aj ked je mozne, ze v C++ je to tiez implementovatelne alebo sa to aj bezne pouziva) a to je hlavne schopnost zajazdy pridavat kod - hot deploy, alebo schopnost pisat kod 'prezerajuci si' dosle instancie cez Reflection.

Tohle je výhoda každého interpretovaného, nebo dynamického jazyka. Jen poznámku: v Javě na mobilech jsem možnost reflexe neměl.

Ad, Smart pointers
Znamena to, ze reference counting tam realne nefunguje? Ak teda potrebujem urobit lokalnu cache objektov musim ich nevyhnutne clonovat? To moze mat drasticky dopad na spotrebu pamate alebo znacnu komplikaciu algoritmu.

Ad, Zodpovednost
Aky ma zmysel ziskavat na vykone za cenu rizika padu alebo security problemu?
Prave ma napadol Tomcat vs Apache - neviem ci Tomcat 4 a Apache 2.0 boli sucastnici, no Apache ma Secunii 33 advisories, no Tomacat len 3! Pritom pri niektorych testoch co som videl, bol Tomcat na statiku podobne rychly ako Apache 2...

Ad, Vyhoda dynamickeho jazyka
Tu vidim pointu, bezna strata na vykone je vyrazne vyvazena dalsimi moznostami... K tomu je potrebne pripocitat schopnost Java byt na aktualne prevadzkovanej platforme rozumne vykonna out of the box... V linuxe sme sice zvyknuti si aplikacie kompilovat, no ja osobne to nerobim pokial mam k dispozicii binary balik uz len preto, ze je to pracne. Pri beznych krabicovych aplikaciach az na svetle vynimky ako kompresory videa a mozno renderovacie SW aj tak ma clovek k dispozicii len 386 mozno v lepsom pripade 586 kod... Myslim, ze sa zhodneme aj na fakte, ze ak by sme naozaj mali v reale kompilovat pre kazdu kombinaciu CPU krabicovu aplikaciu... asi by sa to zle aj vyrabalo...

Ad, Javovsky C++ kod.
Vo Vasom priklade (uvedena linka) ste uvadzali pouzitie struct miesto objektu. Ok,je to mozne, no zavadzat hodnotove typy namiesto referencnych lahko vedie ku komplikaciam ako ukazal C#... Zakladne typy jednoducho su len hodnoty a ked nahodou je potrebne mat univerzalnejsiu funkciu koder nema moc na vyber... Bud to dynamicky casti cez object, alebo vytvara overloady, alebo si posiela NULL ako 0, -1 alebo nieco podobne vymyslene.... alebo si este moze zapuzdrit 'long' do vlastneho objektu. Myslim si, ze prave MS je krasny priklad toho ako sa to nerobi v duchu vykonu, kedze nullable types zaviedol do C# 2.0! Je fajn, ze na trivialne priklady sa to celkom hodi, no neskor prave takeho predcasne optimalizacne rozhodutia vedu ku tragedii v dalsom kode...

Znamena to, ze reference counting tam realne nefunguje? Ak teda potrebujem urobit lokalnu cache objektov musim ich nevyhnutne clonovat? To moze mat drasticky dopad na spotrebu pamate alebo znacnu komplikaciu algoritmu.

Ne to neznamená.

Vo Vasom priklade (uvedena linka) ste uvadzali pouzitie struct miesto objektu. Ok,je to mozne, no zavadzat hodnotove typy namiesto referencnych lahko vedie ku komplikaciam ako ukazal C#...

Víte možná to patří k folklóru těch co mají rádi Javy, ale javisti všude vidí problémy. Já zase naopak vidím problémy v absenci hodnot v Javě. V Javě jsou jen odkazy a to je problém. Žádný jazyk to nedonesl tak důsledků. Právě proto nepotřebuje třeba C++ gc, protože má hodnoty i reference. Java neumí pracovat s hodnotami vůbec (mluvím o objektech) a proto si javisti nedokáží představit co to vlastně znamená. V C# je to bohužel hybrid, který se trochu nepovedl, neboť v tomto blbě napodobil Javu, i když ne zcela.

Zakladne typy jednoducho su len hodnoty a ked nahodou je potrebne mat univerzalnejsiu funkciu koder nema moc na vyber...

A ve skutečně objektových jazycích nejsou primitivní typy. A s hodnotami tam problémy nemají, protože jak říkám, každý jazyk s výjimkou Javy má hodnoty i reference. Proto v jiných jazycích tyto problémy nejsou.

Bud to dynamicky casti cez object, alebo vytvara overloady, alebo si posiela NULL ako 0, -1 alebo nieco podobne vymyslene.... alebo si este moze zapuzdrit 'long' do vlastneho objektu. Myslim si, ze prave MS je krasny priklad toho ako sa to nerobi v duchu vykonu, kedze nullable types zaviedol do C# 2.0! Je fajn, ze na trivialne priklady sa to celkom hodi, no neskor prave takeho predcasne optimalizacne rozhodutia vedu ku tragedii v dalsom kode...

Je to trochu přeplácané.

Jinak s bodem 2 a 3 jak ho uvádíte souhlasím. Akorát bych uvedl, že je smutné, když se zase na toto místo tlačí Java, neboť existuje mnoho schopnějších dynamických jazyků. Já sám píšu v dynamickém jazyce, ale Java to bývá jen, pokud jí dostanu přikázáno. Java není moc dobře vyřešený dynamický jazyk. V Javě se musím starat až o příliš moc věcí, které dělat v jiných dynamických jazycích nemusím, aniž by mi to něco přineslo.

Ako Javista sa uz davno necitim, kedze zijem skoro 4 roky vyhradne v C#...

Ale ten reference counting som nepochopil - je tam nie je tam? Priznam sa,som lenivy to googlit...

Ano neuvedomil som si, ze v C++ si urobim pointer na struct ked sa mi to hodi... Akurat si kazdy musi davat presne pozor ako to prislo, ze? Ano uz si zacinam vybavovat niektore neprijemne preklepy a nepochopenia, co ma za kratkeho zivota v C++ stretli...

Ono sa to moze zdat preplacane, ale tragedia je,ked univerzalna datova struktura obsahuje nieco ako IsNull(), pretoze null sa univerzalne pouzit neda. A moja realna skusenost hovori,ze raz ked to nie je jasne ako sa to ma urobit, lahko sa s podobnym folklorom stretnete. Kazdy obcas podla svojej chuti! Kiez by MSSQL nemal bigint alebo datetime. Ale toto by som povedal vseobecne. Cim vacsiu moznost koderovi clovek da,tym vacsmi ju aj koder vyuziva. Na skodu veci, castokrat naozaj zle.

Java IMO nebola planovana ako dynamicky jazyk, aj ked niektore vlastnosti vdaka VM ziskala. Kompilator mala od zaciatku a mozno prave preto, ze je niekde na pomedzi ziskala aj istu popularitu. Je to presne pripad Swingu - je mi nanic, ze ma pekny objektovy navrh a v podstate sa s tym celkom dobre robi, ked vysledny efekt je taky ako je...

Ale ten reference counting som nepochopil - je tam nie je tam? Priznam sa,som lenivy to googlit...

Přímo v jazyce není. Reference counting se dá naprogramovat a v základních knihovnách boostu už je. V příštím standardu C++ už bude reference counting rovnou. Jde v zásadě o rozšíření současné třídy auto_ptr, která už v C++ je.

Ale ten reference counting som nepochopil - je tam nie je tam? Priznam sa,som lenivy to googlit...

Přímo v jazyce není. Reference counting se dá naprogramovat a v základních knihovnách boostu už je. V příštím standardu C++ už bude reference counting rovnou. Jde v zásadě o rozšíření současné třídy auto_ptr, která už v C++ je.

Já bych doplnil, nechci tady kritizovat Javu, i když osobně jí považuji za dost nepovedený jazyk. Jazyk, který prostě se ujal, protože do něj cpala peníze velká firma. Ale to mi nebrání abych neviděl také kladné stránky tohoto jazyka. Spíše jsem trochu ve střehu, protože Java se prezentuje dost často příliš nepravdivě.

Debata s Vámi je konstruktivní a je to radost. Pokud máte pocit, že vystupuji trochu ostřeji, nebo nedbale, tak je to jen ospalostí, takže se omlouvám. Nedejte se mnou prosím odradit.

Myslim, ze sa zhodneme aj na fakte, ze ak by sme naozaj mali v reale kompilovat pre kazdu kombinaciu CPU krabicovu aplikaciu... asi by sa to zle aj vyrabalo...

Máte pravdu.

Já s Vámi souhlasím, akorát mi přijde dost ubohé, když javista napíše něco o rychlejší javě, než C++ a ještě to ztuční.

Nemám nic proti Javě, ale když už se bavíme, mě se naopak filozofie jazyků, které škrtnou vše co by snad někdo mohl špatně použít naprosto nelíbí. Protože pak takový jazyk stejně dojde k tomu, že se algoritmy ohýbají pro něho, a že se všechno nějak emuluje aby se to v tom jazyce dalo napsat a v Javě to je až moc vidět.

Ono srovnání Javy a C++ se dělá jen proto, že Sun má komplexy z C++. Přitom C++ se s Javou srovnávat nedá. C++ je kompilátor do strojáku, Java je původně interpret (nechytejte mě za slovo JITem, to je jen jiný způsob interpretace). C++ je rychlý, efektivní, nenáročný, Java dává několik abstrakcí typu gc a spol.. Atd..

Problém javy při použití na běžné servery oproti C++ je ten, že C++ má počítač víc v rukou. Třeba ošetřit některé věci, jako je možnost zotavení se a běhu při nedostatku paměti, nebo vyčerpání místa na zásobníku lze v C++ provést, v javě to prostě padne bez možnosti programátorem to ovlivnit.

Ale ja som robil v C/C++ viac ako 6 rokov. O starte a pamati sme sa nebavili. Bavili sme sa o behu programu. A tak ako som napisal v povodnom prispevku java je rychlejsia pretoze JIT si profiluje beh programu a az potom sa rozhodne ktoru cast a ako prekompiluje a zoptimalizuje. To kod v C/C++ nedokaze pretoze takuto informaciu nema. Staticku optimalizaciu mozu obidva kompilatori urobit rovnako.
Mimochodom z vasho popisu aj tak nerozumiem kto vam tu pamat uvolnuje ked to nerobite vy a ani garbage collector tak je to zazrak ktory bude stat za zverejnenie lebo teoretici z IBM a Sun sa s tym trapia uz niekolko rokov ako to urobit SAMO ale zatial vzdy potrebuju garbage collector.
Vy dokazte opak, preco to mam robit ja?

Zapomínáte na to, že

1) profilace programu za běhu taky stojí nějakou režii a tudíž se může také negativně projevovat na rychlosti

2) c++ to dokáže také, to jest překompilovat program podle profilovacích informací

trochu přeceňujete možnosti optimalizace JITu a děláte tu bublinu

Nevím proč bych dokazovat a vyvracel Vaší evidentní lež, když jsem jasně odkázal na svůj článek, kde to dělám. A dostatečný důkaz je, že NEEXISTUJE žádný SERIÓZNÍ test, který by byl v souladu s Vaším tvrzením. Jinak řečeno, praxe a testy vyvracejí naprosto jednoznačně Vaše tvrzení o tom, že by kdy java mohla být rychlejší, než C++.

Ne paměť v C++ neuvolňuji ani já, ani garbage collector, já jen naznačím kompilátoru C++, kdy to má udělat on sám automaticky. To je celé kouzlo. Na rozdíl od Javy dokonce mám bonus navíc v tom, že toto kouzlo neuvolňuje jenom paměť, ale také ostatní prostředky objektů, jako jsou třeba otevřené handly apod.., což je v Javě někdy docela problém, protože tohle musíte zařídit v Javě pěkně ručně, tady Vám gc nepomůže. Takže v jistém smyslu se v C++ starám o uvolňování prostředků, tedy paměti, handlů, a jiných zdrojů systému méně, než v Javě.

1) Isteze pretoze nema zmysel optimalizovat kratko trvajuce procesy. Ci nieco trva 25 sekund alebo 26 sekund to je jedno.
2) Len poukazujem na to preco je optimalizacia v Jave efektivnejsia.
Viete preco napr. moze byt kod v Jave rychlejsi, pretoze napisat a spravne ohandlovat multi threadovu aplikaciu v Jave je ovela jednoduchsie nez v C++. Tak ako som napisal predtym. Java je silny nastroj ktory dokaze dobry programator vyuzit vo svoj prospech.
V C++ Vam stale zostava C pomocou ktoreho si mozete niekde prepisat pamat. V Jave to nejde. Takze aj pouzitie 3rd party kniznic je napr. bezpecnejsie. A to je aj dovod preco su v Jave rozne frameworky take oblubene (a programatori taky lenivy).

Viete preco napr. moze byt kod v Jave rychlejsi

Vy jste velký teoretik. Pořád může být rychlejší. Problém je, že není a nikomu se to ještě nepovedlo. Praxe říká něco jiného. Fakt se odmítám dále bavit na teoretické bázi, buď dokažte nějakým testem tu Vaší lež, kterou opakujete jako kolovrátek, a nebo se prostě jděte bodnout.

napisat a spravne ohandlovat multi threadovu aplikaciu v Jave je ovela jednoduchsie nez v C++

to je pravda, nicméně tohle není důvod pro rychlost, spíš naopak

Java je silny nastroj ktory dokaze dobry programator vyuzit vo svoj prospech.

C++ je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

Ruby je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

Python je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

C# je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

Smalltalk je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

V C++ Vam stale zostava C pomocou ktoreho si mozete niekde prepisat pamat. V Jave to nejde.

Jasně, možnosti C/C++ jsou prostě větší. A proto se s tím spojují i větší rizika. Mimochodem by bylo docela smutné, kdyby C++ neuměl přepsat paměť.

Takze aj pouzitie 3rd party kniznic je napr. bezpecnejsie. A to je aj dovod preco su v Jave rozne frameworky take oblubene (a programatori taky lenivy).

A to je také důvod, proč je Java taky pomalejší a hlavně žravější. :-)

Obavam sa kompilacia na zaklade profilacie ma istu vaznu slabinu - kazdy vacsi system ma svoj zivotny cyklus... Takze rano importujem data, cez den s nimi pracujem, vecer zase exportujem. Moze to byt dokonca aj horsie. Mzdy sa sa robia den alebo dva, vypis z banky zadava jeden klient raz za mesiac, no druhy to robi kazdy den... V takychto pripadoch staticka kompilacia skoncila.

Este by som rad spomenul napriklad upravu bytecode za behu. Viem,ze je to extrem, ale celkom pouzivany k prospechu celkoveho vykonu... Z uvedeneho by som povedal, ze C++ bude pravdepodobne pri jednoduchych prikladoch asi vzdy rychlejsie, no pri long running systemoch to bude mat dost tazke...

Obavam sa kompilacia na zaklade profilacie ma istu vaznu slabinu - kazdy vacsi system ma svoj zivotny cyklus... Takze rano importujem data, cez den s nimi pracujem, vecer zase exportujem. Moze to byt dokonca aj horsie. Mzdy sa sa robia den alebo dva, vypis z banky zadava jeden klient raz za mesiac, no druhy to robi kazdy den... V takychto pripadoch staticka kompilacia skoncila.

Já bych řekl, že přínos dynamické kompilace bude menší, než se tvrdí. Ono ať chcete, nebo ne, stejně 99% kódu, který Java vykonává je staticky překompilovaný v C/C++.

Este by som rad spomenul napriklad upravu bytecode za behu. Viem,ze je to extrem, ale celkom pouzivany k prospechu celkoveho vykonu... Z uvedeneho by som povedal, ze C++ bude pravdepodobne pri jednoduchych prikladoch asi vzdy rychlejsie, no pri long running systemoch to bude mat dost tazke...

Já bych se odvolal na praxi. Zatím se C/C++ systémy ukázaly vždy rychlejší. Až bude Java rychlejší, věřte mi, že se začnou kritické věci psát v Javě - a to se neděje. Zatím máte kernely operačních systémů psané v C/C++/Asm a rychlostně kritické části si zatím nikdo nedovolil přepsat do Javy, ale píšou se v C/C++/Asm. Řekl bych, že to o něčem svědčí. Stejně tak jako kódování a dekódování videa se v Javě taky nezačalo psát. A 3D grafika, která se používá v Javě stejně volá vnitřně C/C++ rutiny, které provedou ty rychlostně náročné věci. Náročné vědecké výpočty, které simulují matematické modely také nepoužívají Javu. Věřím, že stačí jeden důkaz, že Java je rychlejší, než C/C++ a ti lidi to do Javy začnou přepisovat, neboť každé procento výkonu navíc se v těchto aplikacích hodí. Ale oni to stále nepíší v Javě a asi vědí proč.

Hmm toto je trochu nefer, pretoze ste prave zacali porovnavat neporovnatelne... A z tohto uhla pohladu je jasne, ze mozeme vsetci buchat Asm a usetrene megawaty dame do ziaroviek a dalsieho CPU time, ktory budeme na tento nezmysel potrebovat :-) A CPU budu stale este i8086, i ked na 3Ghz, pretoze to nedokazeme kazde 2 roky cele prepisovat!

Ale mozno je to aj ta spravna odpoved na povodnu otazku... Potrebujete napisat time critical vec,lebo kazdy takt sa pocita? Ano mate tu Asm ked je moc zle, C ked je to celkom v pohode a C++ ked si mozete dovolit mierny luxus. Inak na vsetko ostatne existuju pohodove jazyky, ktore vyrazne predcia spominanu TROJICU, no treba pocitat, ze nejakky ten CPU takt obetujete za goodies, ktore vam neposkytne ani jeden zo spominanych... A ked nahodou ano, tak to len tak, ze sa stanu sucastou VM, ktoru mate k dispozicii k tym ostatnym jazykom.

Uz mi len teraz unika, preto je tolko veci z core Java napisanych v samotnej Java a nie vo svatej Trojici ako ste spominali

PS: Az teraz chapem, preco sa C# cita ako Cis :-D

Jenže tohle je právě sice mainstream názor, ale mylný. Jednak neexistuje jen svatá trojice. Jednak C++ není pomalejší, než C, tudíž C++ je na tom rychlostně stejně jako C. Existuje spousta jiných jazyků, které se používají a jsou třeba velice rychlé. Já to řeknu jinak, zabýval jsem se kdysi realtime jazyky. Jinak třeba NASA všechno píše v Adě - statický kompilovaný jazyk zaměřený na maximální bezpečnost a na to, aby bylo maximálně těžké v tomto jazyce napsat chybu. Přesto je to jazyk docela rychlý. Amiga měla část operačního systému napsánu v jazyce B, předchůdci Céčka. Viděl jsem operační systém napsaný v Module 2 - rychlostně je na tom podobně jako Céčko. Spousta core Java věcí je sice napsáno v Javě, ale pak to dopadá tak, že Microsoft napsal svojí JVM, která regulérně byla velmi výrazně rychlejší, než cokoli od Sunu a neměla tuším ani JIT. Java samotná jen velmi mizerně podporuje rozšířování pomocí C, sice to jde, ale nikde se to nepropaguje a nikdo to moc nedělá. Prostě v Javě nejde o rychlost tak co by se někdo namáhal.

Vykonostny rozdiel pride v pripade pouzitia OOP nie? Ak si dobre pamatam, tak prve verzie C++ boli riesene len cez preprocesor.

Nebol rozdiel vo vykone dany aj tym, ze MS si mohol dovolit natlacit veci do jadra, co hold Sun nemal?

Ono rozsirovanie cez JNI nie je uplne vzacne, ved samotny Eclipse zacal stavat SWT prave ako JNI wrap. Sice zahodil write once run anywhere, ale ziskal native look and feel. No a este k tomu podoknem to podstatne. Kedysi som pouzival NetBeans so Swingom a bol celkom slusne bugovy. Faktom je, ze postracal aj nejaku pamat a bolo ho vhodne restartovat aspon raz za den. No ked nieco padlo, co nebolo zas take zriedkave, nic sa vacsinou nedialo a na opakovanu poziadavku fungoval dalej. Zato Eclipse vo verzii 2 ci kolko mi na linuxe zil len 5 az 10 minut... Potom isiel ako spravny C++ do .core :-)

Vykonostny rozdiel pride v pripade pouzitia OOP nie? Ak si dobre pamatam, tak prve verzie C++ boli riesene len cez preprocesor.

Proč myslíte, že použití OOP by mělo snižovat výkon? Musíte si uvědomit, že z hlediska C++ nejjednodušší třída nemá prakticky naprosto žádnou výkonnostní režii. První verze C++ byla opravdu v preprocesoru, ale taky uměla asi tak 1% toho co dnešní C++.

OOP není o snižování výkonu, OOP je jen metodika programování. To je třeba taky důvod, proč opravdové OOP jazyky nají všechno jako objekty, i celá čísla, a přitom rychlostně je to stejné jako práce s primitivními typy.

Musíte si uvědomit, že kompilátor prostě je od toho, aby optimalizoval a také to, že pro C++ nejsou objekty spojeny s takovou režií jako v Javě, protože prostě jsou to z hlediska strojového kódu vnitřně jenom struktury, metody jsou jen funkce s parametrem navíc. Proto také se nikdo neobává používat OOP v C++ i na rychlostně kritické věci, neboť OOP v C++ nemá výkonnostní režii prakticky žádnou a v případě využívání pokročilých OOP věcí je v C++ výkonnostní režie naprosto mizivá.

Samotne pouziti OOP vykon nesnizuje. Co je naprosty zabijak vykonu je kdyz trvate na tom, aby vas program byl "ciste objektovy" nebo tak neco - napr. zacnete trvat na tom, aby cizi objekt nikdy nemenil promenne a podobne a nedavate pozor, jestli jste to nedostali do stavu kdy to optimalizace uz nezachrani (nepochopi, co mate na mysli).

Osobne myslim, ze v tomto ohledu nejde o to, ze by bylo C++ napsane nejak lepe, ale o to, ze kdyz C++ neco nezvladne optimalizovat, muzete mu pomoct (treba i C prostredky), zatimco v Jave kdyz to nejde, tak to holt nejde.

Jinak, na co bych si rozhodne daval pozor je vicenasobna dedicnost. Pokud C++ prekladac chce dodrzet normu, musi ji prekladat dost priserne. I kdyz mozna to lepe nejde, konecne Java vicenasobnou dedicnost objektu pro jistotu vubec nema (jen interface).

Vykonostny rozdiel pride v pripade pouzitia OOP nie? Ak si dobre pamatam, tak prve verzie C++ boli riesene len cez preprocesor.

Proč myslíte, že použití OOP by mělo snižovat výkon? Musíte si uvědomit, že z hlediska C++ nejjednodušší třída nemá prakticky naprosto žádnou výkonnostní režii. První verze C++ byla opravdu v preprocesoru, ale taky uměla asi tak 1% toho co dnešní C++.

OOP není o snižování výkonu, OOP je jen metodika programování. To je třeba taky důvod, proč opravdové OOP jazyky nají všechno jako objekty, i celá čísla, a přitom rychlostně je to stejné jako práce s primitivními typy.

Musíte si uvědomit, že kompilátor prostě je od toho, aby optimalizoval a také to, že pro C++ nejsou objekty spojeny s takovou režií jako v Javě, protože prostě jsou to z hlediska strojového kódu vnitřně jenom struktury, metody jsou jen funkce s parametrem navíc. Proto také se nikdo neobává používat OOP v C++ i na rychlostně kritické věci, neboť OOP v C++ nemá výkonnostní režii prakticky žádnou a v případě využívání pokročilých OOP věcí je v C++ výkonnostní režie naprosto mizivá.

Nebol rozdiel vo vykone dany aj tym, ze MS si mohol dovolit natlacit veci do jadra, co hold Sun nemal?

Řekl bych, že MS umí na rychlost optimalizovat lépe, než Sun. Především na rozdíl od Sunu oni neměli všechny standardní knihovny Javy v Javě, a pak taky asi napsali lépe optimalizovanou JVM. MS vůbec dokazuje, že nad Sunem rychlostně vede, když si spočítám kolik let trvalo Sunu dostat se rychlostně s JVM na dnešní úroveň, a MS bez problémů udělal z placu naráz rychlejší JVM (kterou mu potom Sun napůl soudně zakázal). A stejně tak dnešní .NET je rychlostně plus mínus srovnatelný s Javou (někde jsem slyšel, že dokonce mírně rychlejší) a to ho MS naprogramoval do dnešního stavu za pár let s porovnání s několikanásobkem času, který potřeboval Sun. Tím neoslavuji MS, jen se snažím dát dohromady fakta.

Priznejme si, ze v M$ na to maji vic programatoru. Ale nativni implementace kritickych knihoven taky musela pomoct ... proc to Sun neudela taky ?

Mno, to bude spíš armáda, ne? NASA píše ve všem možném včetně obskurnosti zvané HAL/S, na které stojí třeba celý raketoplán. ;-)

Díky za opravení.

Ono NASA to ma tezky. Nikde na Zemi nemuze chyba pocitace - at uz HW nebo SW - zpusobit takovy pruser jako ve vesmiru. Proto ma kazdy na stole 1GHz procesor, ale v raketoplanu si ho nemuzou dovolit - HW do raketoplanu musi splnovat vysoke pozadavky na spolehlivost, byt odolne proti radiaci a nekolik let od vyroby se jen ceka jestli se na nem neprojevi nejaky problem.

K tomu pripocteme ze raketoplany jsou pres 30 let stare a behem tech 30 let si netroufli menit nic co fungovalo, protoze testy jestli neco nepokazili by pri potrebne spolehlivosti byly zatracene drahy.

A CPU budu stale este i8086, i ked na 3Ghz, pretoze to nedokazeme kazde 2 roky cele prepisovat! - No vzdyt je. Dnesni 3GHz Pentium IV / Athlon 64 jsou interne sice RISCove, ale pro aplikace stale funguji jako 8086 kompatibilni. A to proto, ze vetsina kodu sice neni napsana v assembleru, ale bud zavisi na necem v assembleru co se nikomu nechce prepisovat, nebo se zdrojaky ztratily (to se stava casto, treba zkrachuje firma a nejak uz neni mozne jeji software portovat na jinou architekturu, zlaty Open Source), nebo je to sice v jinem jazyce, ale v praxi to stejne na jine platforme prelozit nejde ... a nebo by treba i slo, ale vzhledem k objemu toho software se do toho nikomu nechce.

Já bych se odvolal na praxi. Zatím se C/C++ systémy ukázaly vždy rychlejší. Až bude Java rychlejší, věřte mi, že se začnou kritické věci psát v Javě - a to se neděje.

Já bych to viděl takhle: Java je slušně rychlá, ale obávám se, že opravdu velký přínos z dynamické kompilace přinese spíš Strongtalk a jeho odvozeniny, nebo nějaký jiný VM Smalltalku – nevím o tom, že by v současnosti v Javě byly využívány až tak agresivní techniky. Pokud Self mohl před skoro patnácti lety běžet polovinou rychlosti céčka, co teprv o něco méně dynamický kód dneska?

Pravda je, že šablony a intrinzika dělají v C++ svoje – kombinací těchto dvou funkcí se dá například vymáčknout z vektorových jednotek maximum, na což Java potřebuje knihovnu. Pokud vím, Java u generik dělá jen type erasure a interní konverze, docela by mě zajímalo, jestli je to aspoň trošku optimalizované (nebo optimalizovatelné) na úrovni VM, když na úrovni kompilátoru to řešené není. Kvalitní VM by to taky dost možná dokázal dynamicky, ale nějak se mi nechce věřit, že by VM Javy byl kvalitní natolik, aby zrovna tohle uměl. C++ to řešit pochopitelně nemusí.

Já jsem nikde netvrdil, že Java je pomalá, já jen prostě dementoval hloupost, že Java je rychlejší, než C.

Chtěl jsem tím naznačit, že Java (tedy aspoň sunovský HotSpot) podle mě stále ještě není schopna dostát slibu, že dynamická optimalizace za chodu může zkrátit celkový runtime. Na takové vychytávky si asi ještě počkáme. :-) (Ale možná to nebude dlouho trvat…)

A otázkou je, jestli někdy tomuto slibu dostát schopná bude. Podle mě možnosti dynamické optimalizace, pokud jsou tedy reálné a není to jenom více méně teoretická fikce předvede první Microsoft na svém .NETu, Sun s tím možná ani nezačne. Já pořád lavíruji mezi tím, jestli dynamická optimalizace má v reálu možnosti zvětšit zrychlení více, než o pár procent (nepočítám-li některé teoretické v praxi se téměř nevyskytující se případy). Dynamická optimalizace totiž sama o sobě má určitou výkonnostní režii a teď jde o to jak to udělat, aby zisk z ní mínus její režie byla k něčemu.

Tak s tím souhlasím, MS je v lecčem bohužel progresivnější. Ve Smalltalku se ukázalo, že volání metod se sebemodifikujícím kódem a inline cachingem cílové adresy je na dnešních procesorech (branch prediction) rychlejší než přístup s vtable a nepřímými skoky … a hádejte, co z toho používá Java a co .NET? ;-)

Heh, chci videt, jak budes psat v jave trebas game server, dopadnes podobne jako l2j, ani ten nejvykonejsi HW ti neudrzi rozumny mnoztvi (aspon stovky) pripojenych hracu.

Nejsem programator, i tak tusim ze ve vasem prispevku je asi obsazeno dost pravdy. Nicmene s Damn Small Linux mi Firefox startuje temer okamzite na jakekoli sracce. Spis bych rekl, ze chybi osveta, ochota a nabidka na trhu; pro setreni zivotniho prostedi ... Lide by vice meli nakupovat usporne zarovky, me by se libilo na trhu dostupne pocitacove reseni na "beznou praci doma" - priklad pro rodice, kteri potrebuji jen surfovat a obcas si pusti hudbu ci film. Podle me dnes koupi zbytecne nadupany (zravy) PC.

No ty takzvané úsporné žárovky jsou podle mě spíše na prd, než na svícení - jsou drahé, málo svítí a když si srovnám náročnost výroby s klasickou žárovkou, tak si spíš myslím, že nám nakonec ta "úsporná" sežere energie ještě více, než klasická.

To že se zvyšuje spotřeba energií je fakt a zvyšovat se bude, s tím se nedá nic dělat, spíš by se měl hledat způsob, jak ji co nejefektivněji vyrábět, s co nejmenší ekologickou zátěží.

Osobně jsem zastáncem jaderných elektráren, je to nejefektivnější a nejčistší výroba el. energie jakou zatím známe a vyhořelé palivo nakonec půjde použít, až vědci trošku pohnou z fůzními reaktory, pak nás myslím nějaký problém se spotřebou elektriky přestane zajímat.

"...pak nás myslím nějaký problém se spotřebou elektriky přestane zajímat."

Neprestane, jen bude vypadat jinak. Co kapacita siti pro distribuci elektriky? Co zdravotni nasledky techto siti? Znate takovy ten prijemny pocit, kdyz vam nad hlavou bzuci VVN?

Spravne je "pak nas nejaky problem s vyrobou elektriny prestane zajimat". Jakmile se technologie fuzniho reaktoru dostane z experimentalni faze, nebudeme se muset trapit nedostatkem elektriny a fyzickym odpadem a budeme se moci zamerit na problem prepravy elektriny a problem odpadniho tepla ...

Osobne myslim, ze je dulezite uvazovat nad setrenim, ale nesmi se to prehanet. Idea, ze zacneme setrit tolik ze by poklesla spotreba, je naprosto mimo. Maximalne muze poklesnout rychlost rustu spotreby. Konkretne u te usporne zarovky si myslim, ze to je resitelne - nevim, jak jsou na tom dnesni usporne zarovky pri zapocitani obtiznejsi vyroby, ale klasicka zarovka je proste tak neefektivni (prinejmensim v lete, v zime muzes rict ze topis) ze neverim ze by se to nedalo zlepsit.

Vyhořelé palivo a fúzní reaktory spolu nesouvisejí. Vyhořelé palivo se dá přepracovat nebo použít v rychlých reaktorech (tzv. breederech). Tato technologie je celkem zvládnutá, nicméně z ekonomických důvodů od ní některé země (jako třeba Francie - projekt Superfénix) ustupují. Není to technologický problém, zkrátka elektřina není ještě tak drahá, aby se to vyplatilo. Zatím se víc vyplatí použité palivo skladovat na horší časy.
Fúzní reaktory jsou mnohem větší problém, než si spousta lidí dovede představit. Je to řádově někde úplně jinde oproti klasickým jaderným reaktorům co se týče nároků na technologie. Materiálové nároky na klasický reaktor se výrazně neliší od nároků na parní kotel, místo uhlí je zde uran, toť prakticky vše, zatímco ve fúzních reaktorech panují kosmické podmínky, silná magnetická pole, milionové teploty.

No, myslim ze s tim parnim kotlem jsi to prehnal (nebo ty materialove naroky myslis hodne doslova), u parniho kotle nehrozi ze kdyz nejaka soucastka bude o milimetr sirsi, tak nezasunes regulacni tyce a reaktor se ti roztavi. Ale je pravda, ze fuzni reaktor nemuzes dat do nadoby z jakehokoliv materialu - kvuli teplote musis pouzit magneticka pole. A ve vesmiru je vetsinou zima, tech nekolik malo mist (relativne) s vysokou teplotou nestoji za rec.

Nejefektivnejsi asi ne, vyuziti energie z uranu funguje asi jen z 2%

A znas efektivnejsi?

Respektive pokud budes porovnavat s nejakou jinou hodnotu v procentech, je treba si dat pozor, abys porovnaval vuci stejnemu zakladu.

No, efektivnejsi (IMHO nejefektivnejsi=100%) je napriklad anihilace - spojeni castice s jeji anticastici. Ale myslim si, ze se nejedna zrovna o vyuzitelny zdroj energie :-)

Anihilace je sice efektivní, ale zase to není obnovitelný zdroj energie! :))

To je pravda, nakonec skoncime tak, ze vsechny prvky s vyssim protonovym cislem nechame v reaktorech rozpadnout na zelezo a vsechny prvky s nizsim protonovym cislem zfuzujeme na ... kupodivu take zelezo :-) Potom uz nic jineho nez vyuziti anihilace nezbyva, ale je pravda, nekolik miliard let to jeste potrva...

Zadny zdroj energie neni skutecne obnovitelny. Dnes se za obnovitelne zdroje prohlasuji ty, ktere se "dobijeji" sluncem, ale slunce samo se vycerpa ...

Jo jo ... je to smutne, ze elektrinu vyrabime stejne jako pres 150 roky - zahrejeme vodu a parou roztocime turbinu. Jen tu vodu ohrivame necim jinym, jinak porad to same :-(

S tim vyuzivanim ztratove energie telehousu by to byl asi technicky orisek, je fakt, ze tepla je tam hodne. Treba velke vysilace jsou vytapeny ztratovym teplem vysilace ( napr. Klet ). V dobe stavby geniani napad. A ted tam museji udelat nove topeni, protoze po prechodu na digitalni vysilani se vysilaci vykon natolik snizi, ze by tam zmrzli ;-)

Jeste bych rad videl nejaky vypocet ohledne tech uspornych zarovek, do ktereho by byla zahrnuta i energie na jejich vyrobu a srovnani se zarovkami klasickymi. Usporna zarovka sice zere mene, ale kolik energie se spotrebuje na jejich vyrobu? Aby to, v souctu nebylo nakonec vice. Krome toho tyhle zarovky by mely byt recyklovane, protoze obsahuji patrne toxicke materialy (luminofor) a recyklace take neco stoji. Navic vetsina lidi je jednoduse vyhodi do kose a s recyklaci si vrasky nedelaji a v nekterych zemich na to ani nejsou sberny, protoze stat na to.... V CR snad jeste ani nesbiraji vybite baterky, natoz pak zarovky. A pokud sbiraji, typnul bych si na marketingovou opicarnu, aby zakaznici nakupovali tam, kde je soucasne i sber. Baterky pak skonci stejne v popelnici. Takze i kdybychom na zarovkach nakrasne usetrili elektrinu, dopad na zivotni prostredi se objevi jinde.

Použité baterie se sbiraji, v kazdem supermarketu je takova krabice. Az pujdu zitra do Billy, tak se mrknu jakou to ma webovou adresu.

> Mikulas Patocka treba ma doma porad Pentium 200MHz a zadne problemy s energii tak nezapricinuje.

Meril jsem spotrebu nekolika starsich PC (pentia 100-200 MHz) a mela spotrebu tak okolo 40-60 W bez monitoru.

Dale jsem meril nejaka soucasna bezna PC, tam se spotreba pohybovala okolo 60-120W.
(udaje uvedene v clanku me prijdou nadsazene a odpovidaji spise nejakemu hracskemu nadupanemu stroji nez bezne kancelarske masine)

Sam mam nove PC se spotrebou 30W (ale ne bezne, jedna se o VIA EPIA s procesorem VIA C3).

Takze nelze pouzivani starych PC neni zas takova uspora, nove PC maji pomer vykon/W vyssi. Lepsi je nove PC a to drsne podtaktovat, nebo usporne PC typu VIA EPIA.

To sice jo ale Mikulas si muze kdykoliv koupit nove PC a podtaktovat si ho na 200MHz a tam pak bude mit ten samy vypocetni vykon za mnohem nizsi prikon.

> To sice jo ale Mikulas si muze kdykoliv koupit nove PC a
> podtaktovat si ho na 200MHz

A která základní deska ti to umožní? Já co jsem videl, všechny měli minimum na 400 nebo dokonce 800 (ale souhlasím, podtaktování na 200 by byla hodně veliká úspora).

Vy mate opravdovy watmetr?

Ano, da se bezne koupit.

Jo, to potvrzuju. Epia 600 MHz s CF kartou misto HDD ma 27W.

Muj domaci pocitac (Sempron 2100+, 2x HDD, nVidia 5200, 2x sitovka, 1x zvukovka, 1x FireWire karta) ma v klidu 85 W, pri zatizeni asi 125 W.

ast

JAVA:

- velke distr. sys. postavene na jave cekaji vetsinu casu na vysledek
z databaze ktera je napsana treba v cistem C.

- java "umi" optimalizovat i za behu

ps: jj, uznavam ze na nektere ulohy se hodi vic jine jazyky a ze pro vyvoj a spousteni java aplikaci je potreba mit silnejsi stroj (i kdyz v dnesni dobe je dulezita hlavne pamet;)

a jak by si ta aplikace teprve pockala, kdyby ta databaze byla taky v jave :-)

Jojo. Veta "velke distr. sys. postavene na jave cekaji vetsinu casu na vysledek
z databaze ktera je napsana treba v cistem C." je agumentem pro "cim dulezitejsi cast kodu, tim nizsi jazyk se musi pouzit na jeji implementaci".

Lenost programatoru? Chtel bych te videt, jak v C delas rozsahlou webovou aplikaci, jak sefovi vysvetlujes, ze uz to bude, jenom jeste tento segfault a je to :-D

Nejvetsi problem soucasne doby se jmenuje x86 a binarni kompatibilita. Verim, ze pokud by se dalo zahodit tohle, nebyl by takovy problem bezne pouzivat uspornejsi procesory, nez mame dnes.

no neviem ci by mal OpenSource OS problem s binarnou kompatibilitou... ale skor myslis nejaky procesor pre bytecode, ze? ale kto by vsetok software (vratane operacneho systemu) pre to pisal?

Jenže Opensource v praxi představuje max. desítky procent používaného software. Tu máš DOSové účetnictví, tu aplikace ve FoxPro, tu něco jiného. Náklady na portaci/přepsání (dle kvality kódu) takové hromady fungujícího software jsou bohužel natolik velké, že se nějakého přechodu z x86 asi nedočkáme, protože by se potenciální přínos asi nezaplatil. Holt špatné návyky z DOSu, na unixech (zvlášť OSS) to je daleko menší problém, s tím souhlasím.

IMO to nie je o aplikaciach a windose. x86 je vela muziky za malo penazi... (nehovorim o kancelarskych PC)

V případě poměru schopností HW a počtu tranzistorů/složitosti designu je to přesně naopak. Jen se podívejte na MIPS: 2 GHz dualcore a 15-20 W spotřeby.

Hlavni vyhodou x86 je, ze se vyrabi v tak velkych poctech, ze je to levne. To je duvod, proc se dnes x86 pouziva casto i na mistech, kde by kompatibilita aplikaci nebyla problem ...

pristup "aplikace musi byt efektivni" zkouseli ve (velke a bohate) firme jmenem WordPerfect a seredne na to doplatili

Můžu se zeptat jakou největší reálnou aplikaci jste naprogramoval? Už vidím, jak budete vyvíjet v jazyce C nebo C++ obrosvký intranetový systém s tisíci moduly, podporou JMS (či srovnatelnou technologií), napojením na databázi (Oracle, Sybase, Adabas nebo PostgreSQL) a neskončíte v psychiatrické léčebně bohnice a navíc to uděláte v reálný čas (což neznamená za 20 let).A vlastně proč v C nebo C++? To jsou taky žrouti procesorového času -- proč ne rovnou v assembleru?


Btw: Problém není že lidstvo potřebuje stále více energie. Problém je jak se ta energie vyrábí -- existuje spousta technologií, které negenerují odpad nebo jejich odpad neznečišťuje životní prostrědí - např. Větrné elektrárny, Vodní elektrárny, Jaderné elektrárny (odpad se dá skladovat a za 50 let ho budeme moci klidně střílet do slunce nebo někam jinam), čekají nás pravděpodobně elektrárny na bázi jaderné fůze...

"Muzu se zeptat jakou nejvetsi realnou aplikaci jste naprogramoval?"
Links. Nenaprogramoval jsem ho sam.

To je ta hruza, co neumi poradne js a css, ze? Zvlaste css setri webovemu vyvojari spoustu prace a je tedy ekologictejsi. Se taky nediv, ze lidi maji radsi uzivatelsky privetivy ff, prace s nim je pohodlnejsi a efektivnejsi. Mozna ze kdybys pouzil nejaky vyssi jazyk s bohatym prostredim, mohl bys vyvijet efektivneji a links by mohl byt i pouzitelny.

Kdyby Links uměl pořádně CSS, tak by pomalostí a žravostí byl na stejné úrovni, jako Firefox --- představ si, že ke každý kousíček textu na WWW stránce je objekt, na jehož atributy se tě někdo může zeptat nebo je změnit. Pak ten document object model žere víc než samotný textový obsah.

Links stránku během parsování rovnou sází, v CSS prohlížeči to nejde, musí se udržovat celá stránka rozparsovaná pro případ, že ti někdo skriptem změní velikost nějakého kusu textu a musí to samo přerovnat tabulky.

"Zvlaste css setri webovemu vyvojari spoustu prace a je tedy ekologictejsi." --- to je přesně to, o čem clock mluvil, že ti uživatelé, kteří musí mít 1-3G stroje a firefox na prohlížející si třeba roota protopí mnohem víc energie než kolik se ušetřilo při jeho psaní v CSS. Ale ekonomický dopad pro manažery určující strategii vývoje WWW stránek to nemá, oni chtějí maximalizovat svůj zisk.

> Links stránku během parsování rovnou sází, v CSS prohlížeči to nejde, musí se udržovat celá stránka rozparsovaná pro případ, že ti někdo skriptem změní velikost nějakého kusu textu a musí to samo přerovnat tabulky.

A co CSS bez podpory javascriptu, to by snad slo, ne?

Neúplné CSS (třeba nastavovat pomocí CSS pouze atributy, co už Links umí, jako barva textu, pozadí, velikost odsazení apod.) by šlo, možná by se to mohlo v rámci příštího Google summer of code navrhnout.

Sám na to nemám čas, ale kdyby ten parser CSS někdo napsal, tak bych to mohl do linkse dolepit.

BTW. jak se dělají a jak fungují ty CSS tabulky pomocí tagu DIV? Je na to někde nějaký tutoriál?

Tabulky se v (X)HTML porad pouzivaji, nicmene pouze na veci, jejichz semantika odpovida koncepci tabulky - napriklad cenik (1 radek = jedna cena), skolni rozvrh (1 radek = jeden den) a podobne. Naopak layout stranky se uz tabulkama nedela (stranka neni tabulka, ostatne takovehle tabulky maji na kazdem radku typicky uplne neco jineho). Vyhody jsou hlavne ty, ze stranka pak jde snadno udelat tak, aby davala smysl linearizovana (coz je vyhoda pro vyhledavace, hlasovou ctecku a textove prohlizece, no a nakonec jeden z pozadavku pristupnosti http://www.w3.org/TR/WCAG10-TECHS/#tech-avoid-table-for-layout ), zaroven prilozenim alternativniho CSSka pro tisk jde jednoduse vytvorit uplne jiny design pro tiskovou verzi (clovek obvykle vyzaduje, aby vystup na papir vypadal uplne jinak nez verze pro obrazovku s vysokym rozlisenim).

Taky to setri bandwidth, protoze jeden externi (nejlepe cachovany) CSS soubor usetri hodne HTML tagu, ktere by bylo nutne posilat znovu s kazdym pozadavkem o dalsi stranku.

Jak vytvorit 2 sloupcovy layout popisuje Pixy, tady je jeho priklad:

http://www.wellstyled.com/files/css-2col-fluid-layout/example3.html

Obvykle se pri delani layoutu pomoci CSS pouziva hodne relativni a absolutni pozicovani, coz bude naprosto odporovat pozadavku na to, aby ten prohlizec stranku vykresloval prubezne (ostatne treba MSIE se snazi nekdy vykreslit urcite casti stranky az prilis rychle a tak vznikaji chyby jako peek-a-boo nebo guillotine). V samotne norme CSS pak jsou i pravidla, kterymi je mozne oznacit elementy na zaklade toho, jake elementy jim nasleduji.

CSS ma jednu zasadni vadu: nikde neni implementovano stejne, ff na widlich a unixu ukazuje fonty jinak velke (a hlavne siroke) a podobne. NElze tedy za ziveho boha docilit stejneho vzhledu na dvou rucnych systemech v ramci jednoho prohlizece.
NEsplnuje tedy ani roky po svem vynalezeni ani tu zakladni pozitivni vlastnost co melo mit. Je krasne usetrit na strane providera pak kb na transferu, trochu casu vyvojare a sezere mraky megabajtu pameti a spoustu hrubeho vykonu navic u klienta - to nas preci nezajima.
V tabulce se da stranka navrhnout krasne, fakticky nespatruju (krom ruznych animovanych mezivariaci pri renderovani) zadny posun ve vzhledu stranek od dob, kdy se tabulky masove pouzivaly.
CSS je tedy realne k nicemu a zustane tomu tak, protoze nez se zvladne implementace CSS 1.0, bude tu verze 3...
Takze prohlizec, ktery neumi CSS je bezny, jen mnohe se tvari ze umi a stejne neumi. Projhlizec, ktery CSS neumi a hrde se k tomu hlasi je z principu veci lepsi, mam proti clockovu linksu nemalo drobnych vyhrad, ale CSS k nim rozhodne nepatri.

Rozdilna velikost fontu neni vubec otazkou CSS. I pokud si velikost fontu nadefinujete v HTML tagem font, tak v pripade, ze si treba v OS nastavite jine DPI monitoru (na hotebooku s LCD s rozlisenim 1900x1200 nutnost!), budete mit fonty jinak velke (v pixelech). A ono je to tak spravne! Web nema za vsech okolnosti vypadat na pixel stejne, uzivatel musi mit moznost si okynko roztahovat, zvetsovat pismo, predefinovavat si CSS pravidla, nastavovat minimalni velikost fontu.

Je velmi dobre a diky CSS je tahle variabilita umoznena ve vetsi mire. Web se ma prizpusobovat - ma vypadat na kazdem pocitaci optimalne podle jeho konkretnich moznosti (jinak na PDA, jinak na projektoru). Ostatne ve vetsine modernich OS CMS systemu si s nicim jinym nez s

Samozrejme neni CSS implementovano vsude stejne a hned podle nejnovejsi normy. No a ma byt? C/C++ taky neni implementovano ve vsech kompilerech stejne a podle nejnovejsi normy. Pritom se asi vicemene shodneme, ze C/C++ je dost pouzitelne.

Nedokoncil sem jendu vetu: Ostatne ve vetsine modernich OS CMS systemu si s nicim jinym nez s CSS ani neskrtnete.

treba tady,
TABLE { display: table }
TR { display: table-row }
THEAD { display: table-header-group }
TBODY { display: table-row-group }
TFOOT { display: table-footer-group }
COL { display: table-column }
COLGROUP { display: table-column-group }
TD, TH { display: table-cell }
CAPTION { display: table-caption }

Samozrejme, hlavni myslenka CSS je pouzivat tabulky jen na skutecne tabulky, ale spousta veci se pak udelat proste neda (hlavne kdyz nechcete davat pevne velikosti). Proto to vzdali a vymysleli tohle: polozku display, ktera zpusobi ze se ten objekt bude chovat trochu jako prislusny tag HTML tabulky. Ma to jeste nejake sideefekty zpusobene tim, ze muzete neco vynechat, ale nejsem si jisty jestli jsou standardni ...

Tohle je sice mozne (dat treba obycejnemu divu treba "display: table-cell"), ale v praxi se to vubec nepouziva, protoze to nefunguje v MSIE. Display se samozrejme (k jinym vecem dokonce i casto) pouziva, je to zakladni vlastnost CSS, ale spis jde o hodnoty block a inline.

Jojo... to je ta hruza, ktera alespon podle toho co jsem si zkusil zobrazi citelne a v pohode vetsinu stranek, kde autorum slo o obsah a ne o grafickou fasadu... nekdo kdysi prohlasil, ze web prestal byt "pouzitelny" (resp. ze predavani informaci na webu skoncilo) ve chvili, kdy se ho chopili sileni grafici. Clock mimo jine psal prave o tom, ze z hlediska ochrany zivnotniho prostredi nemusi zalezet na tom, ze se usetri vyvojaruv cas a tys to pochopil uplne naopak...

Links... hmmm, to je to presne ta hruza (program na takove urovni), na kterou ty a tobe podobni hlupacci nikdy nebudou mit programovaci schopnosti, ale pod rouskou anonymity na netu si budou otevirat hubu... ;)

Nevím, nevím, ale kdybys třeba jen zkusil google(links), tak bys zjistil, že links (alespon 2) opravdu mají na svědomí nějací Mikuláš Patočka, Karel Kulhavý (Clock), Petr Kulhavý (Brain) a Martin Pergel (PerM).

Hm, vidim... a prinejmensim o Clockovi a Mikulasi Patockovi jsem vedel uz predtim, ale nejak nechapu kam tim miris... (reagoval jsem na "ee", ne na Clocka) :P

Nojo, vetrne elektrarny. Akorat je blbe, kdyz pak treba Google je tri dny nedostupny, protoze nefoukal vitr nebo jen tak malo, ze to akorat tocilo ventilatorem v reditelove kancelari. BTW, by me zajimalo, jak si predstavujete strileni odpadu na Slunce. Uvazte, ze dnes se spotrebuji tuny paliva a jinych materialu treba jen na to, aby se vystrelil takovy vetsi Sputnik pouze na obeznou stacionarni drahu okolo Zeme. Navic tak jednou nebudeme mit ani ocel na hrebiky, protoze ji vsechnu nastrilime do Slunce s kontejnery vyhoreleho uranu. Pokud tedy neplanujete otevreni dolu na Venusi nebo nekde v okoli Proximy Centauri. A na jadernou fuzi moc nespolehejte. Neni vylouceno, ze se to povede, zaruky jsou ale jeste horsi, nez u prvni ceny v loterii. Vsimnete si, ze k pokroku ve vyzkumu moc nedochazi. Bodejt by take ano. Porovnejte si vojenske rozpocty s rozpocty na vedu. Lidstvo ma vzdy dulezitejsi problemy na reseni, nez ty dulezite. Korporace chteji vydelat a to ihned a tomu se podrizuje vsechno. Pokud tedy neco zachrani lidstvo pred energetickou krizi, bude to cite nahodou, navzdory lidske blbosti.

Jaderna fuze nevypada moc realne. Ani hromadne vyuziti vodiku ve spalovacich motorech.

strilet ho nebude treba....pojede orbitalnim vytahem (http://www.ian.cz/detart_fr.php?id=1741)
myslim, ze termojaderna fuze budoucnost ma, i kdyz to neni jedina alternativa. ale az ONI budou chtit :-)

Kazda vetrna elektrarna potrebuje vodni precerpavaci ktera vyrovna "kratkodobe" poklesy vykonu.

Ja bych ten odpad nikam nestrilel. Ono by se z nej jeste dostalo spoustu energie, kdyby prislusna technologie nebyla hlidana armadou protoze se s ni daji vyrabet atomovky ...

Venuse je dost neprijemna. Pro zacatek Mesic, pak Mars, potom mesice Jupitera.

Kdyz se ve dne podivate na oblohu (a neni zrovna zatazeno), zjistite ze jaderna fuze je mozna.

Jojo ... taky se obavam, ze dokud bude ropa levna, tak se nicim jinym nenahradi, a vetsinu teto cenne vyrobni suroviny spalime ... ale zda se ze posledni zvysovani ceny uz slusne podporilo vyvoj hybridu.

> proč ne rovnou v assembleru?

LOL. tak to ti nevyslo...

Presne.
Bohuzel se to za poslednich cca 15 let vse posunulo nekam k obludnemu systemu, ktery spotrebovava spoustu energie, jen aby udrzel pri chodu sam sebe a vytvari zbytecne problemy, ktere je treba zbytecne resit. Nekdy si rikam, ze za par let se clovek bude snad i stydet za to, ze je z IT. Za vsim je jedna trivialni vec, ktera je lidem vlastni: kseft. Programovani pomoci lepeni kodu a nikoliv znalosti, jak maji programy pracovat efektivne je pouze jednou casti toho vseho.
Mozna je tato civilizace odsouzena k zaniku. Mozna zanik civilizace nastava vzdy, kdyz je prekrocena kriticka hranice koncentrace blbosti. A koncentrace blbosti na km2 stoupa a stoupa....

A koncentrace blbosti na km2 stoupa a stoupa....

Odstehuj se na nejaky ostrov v Pacifiku. Tam je to zatim v poho ;-)

Nedelejte si iluze. Globalizovana blbost prosakuje zajiste i na tyto ostrovy :)

Tady nam efektivnejsi kod asi nepomuze, nebot jen efektivneji vytizi CPU, ktere se tak vic zahriva a tedy bere vice energie. Rozdil mezi spotrebou energie napr. programu prime95 a spatne napsaneho programu v Jave asi bude znacny.

"Cas programatora ale z hlediska Zeme nic nestoji - trochu jidla pro 1 cloveka." LOL tak si sežeň programátory, kteří za tebe budou pracovat za trochu jídla a nech nám naprogramovat nové OpenOffice. Děkuju :-)

1) Ceny práce programátorů a energií jsou více méně tržní, takže nemá cenu nad tím moc dumat, líp to nepůjde. Časem se to třeba změní, až bude víc programátorů a začnou docházet zdroje energie.

2) Nejde jen o výdaje na práci programátora. Firmám jde taky o čas, je rozdíl, jestli uvedou SW na trh teď nebo za půl roku, někdy i měsíční zpoždění může být problém. Proto je potřeba RAD a všechny moderní jazyky.

3) To že něco napíšeš v assembleru, ještě neznamená, že to bude rychlé. Je jen málo programátorů, kteří dokáží napsat v assembleru efektivnější kód, než který vyleze z kompilátoru nějakého vyššího jazyka. Navíc někdy není v lidských silách mít v hlavě celý program a napsat to v nějakém nízkoúrovňovém jazyce, takže je to spíš horší, pomalejší a méně efektivní.

4) Nadávání na Javu mě moc nebaví. Pro spoustu lidí je to "pomalé" jenže to je jen tím, že na začátku musí nastartovat JVM, pak už program běží úplně normálně, můžeš mít v javě třeba 3D hru.

5) Pro firmy je taky důležité, aby šlo jejich programy aktualizovat, třeba přidat nějakou funkci na přání zákazníka. Jestli program namastíš v bůhvíjak (běhově) efektivním jazyce, tak se ti ale může stát, že kvůli přidání jedné funkce to budeš celé přepisovat...


Taky souhlasím s tím, aby se snižovala spotřeba energií, ale to se udělá samo. Začnou se vyrábět úspornější součástky a lidi je budou kupovat, aby ušetřili na účtech. Výrobci HW na tom taky vydělají, protože budou prodávat nové věci. Takže v tom problém nevidím. Je to jen otázka technologického pokroku.

> 3) To že něco napíšeš v assembleru, ještě neznamená, že to bude rychlé. Je jen
> málo programátorů, kteří dokáží napsat v assembleru efektivnější kód, než který
> vyleze z kompilátoru nějakého vyššího jazyka. Navíc někdy není v lidských silách
> mít v hlavě celý program a napsat to v nějakém nízkoúrovňovém jazyce, takže je to
> spíš horší, pomalejší a méně efektivní.

LOL. to je akoby som napisal "Slnko svieti". alebo niekto naznacoval, ze assembler je ta spravna cesta? :)

Clock si tady ztěžuje na vyšší programovací jazyky Java,.NET, C#... Tak jsem vzal assembler jako opačný extrém, ale docela to platí i pro jazyky někde na úrovni mezi asm a javou.

to nie je opacny extrem, ale blbost. co tak brat za opacny extrem nejaky jazyk, ktory je portabilny? take, hmm, co by to, aha - C?

a proc by musel byt "portabilny"? kopilatory C asi clovek vetsinou netrumfne, ale nekdo treba jo a potom je ten assembler z toho "ekologickeho hlediska" lepsi volba.

nie je.

1) verzia by sla len na 1 type procesoru, rucne optimalizacie by boli vhodne len pre tu jednu generaciu

2) rozdiely by boli male (a okrem toho je mozne jednoducho spojit C a assembler, ak by to bolo vhodne), takze v spojeni s bodom 1 nam vyplyva bod c.3

3) je to taka blbost (ak nie este vacsia) ako povedat, ze pisanie v strojovom kode je este lepsie. tiez to nema ziadne vyhody, ale preco to tak nerobit?

Třeba quake je prý dvakrát rychlejší s použitím ručně optimalizovaného assembleru než s C funkcemi.

Ale vyvíjet se to v tom assembleru pochopitelně nedalo, dělali to tak, že to prvně napsali v C, pak odladili, a pak
nejvytíženějí funkce přepsali do assembleru.

Navzdory všem trikům gcc generuje dost hnusný kód (třeba u konstrukce if (x < 0) printf("chyba") sice správně pochopí, že tato větev moc často nenastává a posune ji nakonec funkce, ale stejně kvůli tomu printf nedovolí používat EAX,ECX,EDX i v té rychlé větvi --- člověk by samozřejmě kolem toho printf dal PUSH a POP na EAX,ECX,EDX, a ve funkci by pak mohl používat všechny registry).
Ve výstupu M$VC jsem zase jednou viděl perlu PUSH ECX;MOV [ESP],ECX (že by obsesivně kompulzivní porucha kompilátoru? :-)

quake nie ze pry, ale JE 2x rychlejsi pri asm optimalizaciach... vlastna skusenost :) takze nieco na tom bude.

Ja bych opet zduraznil, ze je lehke spojit C a assembler. Spravne reseni totiz neni psat celou mamuti aplikaci v assembleru, ale prave ta metoda pouzita u Quake - 90% kodu je v C, ale tech 10% ktere spotrebuji 90% vykonu je v assembleru komentovanem ekvivalentnimi C funkcemi.

Neverim, ze neschopnost gcc zoptimalizovat vyse zminene bude trvat vecne. Ale je pravda, ze vzdycky budou veci co clovek napise lepe.

OS/2 Warp 4 - system, ktery je z velke casti napsan v ciste JAve a bezi velmi pricetne na 386/8mb ram. Bezi tam mnohem rychleji nez ve vmwaru, cert vi proc.
Obektove programovani obecne moc rad nemam, javu uz vubec ne, ale ten system je dukazem toho, ze nejlepsi (z hlediska dovednosti a reakcnich casu) system v pomeru dovednosti/(spotrebovany hruby vykon) byl napsan v jave. Pokud nekdo vite o vychytlejsim prostredi pro 386/8ram dejte vedet at se poucim, ja hledam uz deset let...

20 megawattu mesicne nedava smysl - otazka je, co tim ted chtel autor rici. Jestli 20MWh mesicne, a nebo 20MW, coz odpovida 14400MWh mesicne.

Jde o hantýrku. Často se výkon (příkon) u velkých odběratelů enegie vyhodnocuje jako spotřeba za nějakou časovou jednotku (typicky 1 hodina). Proto se občas používá (nepřesně) výraz spotřeba i tam, kde se tím rozumí výkon (příkon).

Pro ilustraci - hodinové maximum spotřeby ČR je cca 11 GW.

Příkony cca 10 - 20 MW jsou pro velké serverhousy běžné.

no nerad kazim iluziu ale 20MW je uplne realnych...
spravujem jednu z takych vacsich serverovni a dnes uz by sme potrebovali vlastnu elekraren :)

zrovna ted jsem kupoval nova streva pro pocitac rodicum. via epia + notebookovy hdd je myslim ta spravna volba ;)

Moje řeč. Až se mi podaří naškudlit cca 10 litrů z rodiného rozpočtu, tak mám v úmyslu narvat stávající stroj do koupelny coby server, a zhotovit klientský stroj na bázi via epia. Důvody? Maximálně tichý (pasivní chlazení), nízká spotřeba, malé rozměry.

Taky mi přijde, že vlhkost vzduchu mu bude škodit ...

I když, praví geekové se nekoupou, těm stačí příkaz grep -Ri "spina" *

No, nevím jestli koupelna je to správné místo pro server.

Takže stávající stroj s vysokou spotřebou poběží 24h denně a nový úsporný stroj poběží jen pár hodin denně. Nebylo by to lepší naopak ? :)

Nebylo, protože vysoká spotřeba je dána větším počtem disků a prioritou pro mne není spotřeba, ale nehlučnost - proto taky ta koupelna (pro představu, není to takový ten panelákový kamrlíček, ale wc + koupelna v poctivé cihle). Dokud jsem bydlel v devátém patře paneláku, tak si ten stroj spokojeně hučel v boudě na balkoně a dovnitř jsem měl protáhnuté jen kabely: k monitoru, bezdrátovému HID zařízení, USB prodlužky a kabel k reprákům. Bohužel nazývat balkonem tu rozšířenou římsu co máme ted snad ani nemá smysl, navíc bydlíme v přízemí. Koupelna je jediná místnost, kde hluk nevadí, protože tam netrávíme tolik času. Ev. by šel použít sklep, jenže.. Postavit kompa do bývalého sklepa na uhlí by mohl asi jen magor, protože uhelný prach je mnohem větší zabiják než vzdušná vlhkost (mám ověřeno v praxi, že si ten stroj udrží v boudě své klima, v podstatě funguje jako sušička - pernamentně cirkulující horký vzduch se o veškerou vlhkost spolehlivě postará).

Ano, arabske "بطرس" odpovida ceskemu "Petr" ;-))

počítač, u kterého sedím má 700wattový zdroj a jede 24 hodin denně, přičemž je 100% vytížený tak z 95% času - jedná se o výpočetní stanici s 2 LCD monitory. V naší firmě je takových počítačů spousta, to musí být účty za energie. V noci sice monitory neběží, ale i tak to bude docela nářez.

Výkon zroje!=příkon PC

?? oba dva jste jahody..teda linuxaci to vas omlouva

A proč já?

to je snad dnes uz kazdemu jasne, ale [radim] nerekl nic ani o prikonu ani o spotrebe, rekl pouze "počítač má 700wattový zdroj" :)

Když někdo řekne, že má jeho počítač 700W zdroj a jede tolik a tak, tak mi nedá než usuzovat, že autor mj z pojmu "700W zdroj" usuzuje na jaké budou účty. To jsem jen to uved na pravou míru.

Ten úvodní odhad spotřeby běžného PC(?) je nepřesný a příliš pesimistický (nebo příliš Wintelovský ;-). Já jsem si koupil wattmetr a tak vidím, že mi stroj s Athlon XP 2500+ bere kolem 70W a 17" monitor dalších 35W. Čili polovinu v článku uváděné spotřeby.

A to se ještě moc těším, až si změřím můj nový strojek s Athlonem EE (=Energy Efficient), který má teplotu minimálně o stupeň nižší než v místnosti, a to s obyč. chladičem (z čehož odvozuji, že ten procesor se prakticky vůbec nezahřívá, takže asi nežere elektriku), a grafiku má integrovanou na boardu - tam počítám, že budu s celým strojem snad na pouhých 60W, možná ještě míň.

Zásadní vliv na spotřebu procesoru má samozřejmě využití jeho úsporných vlastností, tj. u AMD Cool&Quiet - frekvence i napětí procesoru můžou v době čekání na uživatele jít hodně dolů, a samozřejmě náš oblíbený linux sám je šetřivý (v oknech má procesor 29 stupňů místo 19 v linuxu, takže asi jejich idle loop nebude tak úplně idle, jako je v linuxu). Podobně se dají uspat disky, když dlouho nic nedělají a vůbec - ACPI povypíná postupně od periférií třeba celý stroj, když lelkuje.

Zkrátka u desktopů, které 40% času čekají na stisk klávesy a 50% času, až se uživatel doma vyspí a znovu přijde do kanceláře, to není tak zlé, když je to dobře nastaveno.

má teplotu minimálně o stupeň nižší než v místnosti, a to s obyč. chladičem

Jak to ten chladič dělá? Pokud nemáte v počítači ledničku, tak mi to přijde ve sporu s termodynamikou, která se učí ve škole. Možná jenom nemáte kalibrované teploměry.

To je jednoduché, v procesoru je namontován rušič 2. termodynamického zákona, pracující na principu volné energie :))). Ostatně proč se tu hádat o nějaké watty, když podle výše zmíněného příspěvku má spotřebu 3MW pár lidí se "skříňkama" (teleporty??), takže serverovna Googlu asi spotřebuje několik atomových elektráren. Tahle diskuze je lepší než komix :))

Optimalizovanie spotreby PC nie je to, o co sa vyrobcovia komponentov snazia, kazdy tranzistor na cipe je dobry na zvysenia vykonu a zlepsenie pozicie v nahanacke pred/za konkurenciou. Bezne PC, pokial nie je pouzivane ako hracia konzola (to je forma ista luxusu, podobne ako sportove auto, kde sa na spotrebu nepozera), 99.9% casu stravi cakanim, kym ta masa vody, trochy vapnika a ineho maglajzu, co sa vyvaluje na stolicke pred monitorom, laskavo natiahne paprcu a stlaci klavesu aklebo pohne mysou. Uz v pradavnych dobach, ked este existovali 16kB dynamicke pamete DRAM (celkom zravy zrut energie) sa dal taktovanim refresovacich signalov dosiahnut stav, kedy si pamete este po 20sec (!!!) pametali ulozene informacie. Nie je teoreticky ziaden problem , dobe ked sa nic nedeje, zredukovat spotrebu zeleza na absolutne minimum - na taktovani komponentov - zbernice, procesora, grafiky zliezt na zopar MHz, LCD spotrebu zredokovat na spotereby vybojky, mechanicke casti (obsah CD/DVD, HDD v maximalnej miere ulozit do cache) vypnut atd. - a to vsetko dynamicky, pocas prace, samozrejme problemom su dynamicke javy, ktore sprevadzaju zmeny taktovacej frekvencie a to je prave ten problem, do ktoreho sa nikomu nechce. Zoberte si stare PC s nejakym AMD 800MHz a podtaktujte ho na minimum - cca 150 MHz - nepotrebujete nijaky ozrutny chladic, staci maly pasivny a CPU bude len mierne vlazne.

"Uz v pradavnych dobach, ked este existovali 16kB dynamicke pamete DRAM (celkom zravy zrut energie) sa dal taktovanim refresovacich signalov dosiahnut stav, kedy si pamete este po 20sec (!!!) pametali ulozene informacie."

No já pamatuju doby, kdy se ještě používaly 16 kib paměti se třemi napájeními : * +5 na IO obvody (kvůli "kompatibilitě" s TTL * +12 na jádro a R/W obvody * -5 na odsávání minoritních nosičů ze substrátu (aby to neshořelo hned, ale až za chvíli)

Např. v legendárním PMD85 jich bylo celkem 24 (32 kiB "běžné" RAM + 16 kiB VideoRAM). Obnovování se dělalo tak, že se musely v taktu řádově stovek us postupně přečíst/zapsat buňky ze všech řádků. Technicky to v PMD nebyl problém - pravidelné čtení způsobovalo generování videosignálu. Dokonce pro jednoduchost bylo horizontální rozlišení 288 bodů (48 x 6 bodů v 1 byte), protože časovače běžely pořád stejně a během "zobrazování" videoinformací za zbývajících 16 B se generoval zatemňovací impulz a zpětný běh.

Pamatování informace na dobu řádově desítky s je spojená spíš s novou generací pamětí, které se už spokojily s jediným napájenám +5. Tyto pak měly celkem 3 režimy přístupu :
a) "klasické" čtení/zápis
Při něm se se na adresové vodiče zadala adresa řádku -> aktivoval se signál /RAS -> zadala se adresa sloupce -> aktivoval se signál /CAS. Tímto byla adresována jediná buňka a současně se občerstvil řádek naadresovaný na začátku operace

b) "obyčejný" refresh
Na adresové vodiče se zadala adresa řádkum která se má občerstvit a na chvíli se aktivoval /RAS (bez /CAS).

c) speciální refresh
Při něm se aktivovaly signály /CAS a /RAS v opačném pořadí. Na obsahu adresových vodičů nezáleží, dochází k občerstvení řádku, jehož adresa se bere z interného registru, který se autoinkrementuje.
Tímto způsobem jsem viděl u jednoho člověka vyřešen externí RAMdisk k počítači Sord M5. Napájení obstarávaly 2 tužkové baterie (skutečně na udržení informace stačily 3V !), občerstvování zajišťoval jednoduuchý generátor velmi úzkých impulzů postavený na časovači 555 (generovány řádově v intervalu stovek ms).

Jste si jist, ze Vam pocitac s Athlonem zere jen 70W? Zkousel jste do toho wattmetru, pro hrube porovnani, zapojit neco se znamou spotrebou, prinejhorsim 60W zarovku?

Protoze muj Athlon se dvema disky se bezne pohyboval okolo 170W, nyni co jsem byl nucen prejit na P4 3.0GHz mam ve wattmetru radeji strceny router.

Tak jsem doma a měřím si ho - vypnutý počítač konzumuje 5 W. Zapnutý pak 45 W. Takže většina motherboardu včetně integrovaného zvuku a obrazu, 1 GB RAM, 250 GB Seagate a dvoujádrový procesor si vezmou za provozu dohromady jen 40 W. Kolik z toho zbývá na Athlon X2 3600+ EE? 10 W? Nebo jen 5? Neuvěřitelné. Proto nehřeje, když nic nežere... Jo, a 17" LCD (Sony) si vezme za provozu pouhých 17 W.

BTW, ten wattmetr samozřejmě funguje správně - žárovka označená jako 60W bere ve skutečnosti 56 W.

WATTMETER - kde se to dá koupit? Prý se to dá i půjčit od energetiky, ale to není ono. Docela bych si s tím proměřil domácnost, ono je dost možné, že některé spotřebiče ve standby si berou i několik desítek wattů.

Wattmetr je drahý, lepší je koupit nějaký obyč AVmetr za pár šupů.
Z do euro prodlužováku vrazit čokoládu s klemou a v serii měřit I(A), v zásuvce teoreticky je od 210-240V AC, to stačí změřit jednou, napětí se tak rychle němění jako proud. No a jistě si pamatujete z fyziky že P(W)= U(V)×I(A) (jalovou složku necháme stranou, ta tu nehraje roli).
Pak stačí sledovat sleep, online, game mody PC a máte jasno, kolik ta kysna žere

1) Wattmetr jsem nedavno kupoval za cca 300 Kc, nebude asi extremne presny, ale to ten AV metr za par supu taky ne. Navic AV metr za par supu malokdy meri stridavy proud do 1A.

2) Pri tomto zpusobu mereni spocitas zdanlivy vykon. Jalova slozka hraje roli dost podstatnou, nebot u spinanych zdroju PC je ucinnik casto okolo 60% a tedy zdanlivy vykon a jako bezny spotrebitel platis za cinny vykon. Takze timto zpusobem tedy zmeris hodnotu, ktera muze byt az dvojnasobna oproti spotrebe, kterou ti nauctuje dodavatel elektricke energie.

Super, až tak laciné jsem to nečekal, můžete prosím uvést značku/modelovou řadu/typ ať mám při hledání vhodného zařízení z čeho vycházet? Díky.