Názory k článku
Scheme: kostlivec ve skřini nebo nehasnoucí hvězda?

Vždycky jsem měl za to, že Prolog je logický, ne funkcionální jazyk.
Třeba jsem se mýlil?

dhetto ako predosli prispevok, prolog patri medzi logicke jazyky

anho, bhane
http://en.wikipedia.org/wiki/Prolog

Scheme ma sice nektere rysy funkcionalnich programovacich jazyku, ale zdaleka nejde o typicky funkcionalni programovaci jazyk. Viz treba uvod k R5RS: "A wide variety of programming paradigms, including imperative, functional, and message passing styles, find convenient expression in Scheme."

Tak tak...já bych to nazval spíš "aplikativní funcionální assembler"... :-D

Predem, rict, ze funkcionalni jazyky jsou ,,deklarativni'' je absolutni nesmysl. Mozna u nekterych z nich (trochu) ano, ale vetsina z nich, a predevsim dialekty LISPu, zasadne nikoliv. Maji jasne dany algoritmus vyhodnocovani a aplikace a vubec nic deklarativniho na nich neni.
Mam pocit, ze autor chtel udelat funkcionalnim jazykum sluzbu, ale misto toho jim udelal svym sarlatanstvim spis ,,medvedi sluzbu''. Dalsi blabol, ze LISP byl vyvinut pro ucely programovani AI, totalni hovadina. A na zaver to nejhorsi: demonstrovat ,,silu'' dialektu LISPi na takove debilite jako je faktorial, ktera lze mnohem efektivne vyresit prostou iteraci s jednou stavovou promennou a jednim kolektorem je proste ukazka cire neschopnosti. Do prdele, autore, to se tam nemohl placnout nejake pekne makro s aktualnim prohracovanim? Kdyz dela nekdo recenzi nejnovejsiho vozu Bentley, tak taky zakaznikum nevysvetluje, ze to ma kola, ale spis chce ukazat neco, co jiny auta nemaji, ... ach jo.

A na zaver to nejhorsi: demonstrovat ,,silu'' dialektu LISPi na takove debilite jako je faktorial, ktera lze mnohem efektivne vyresit prostou iteraci s jednou stavovou promennou...

Něco jako (fold * 1 (iota n 1))? :-D

Tohle by prisne vzato asi vedlo na rekurzivni proces, ale pointa ja myslim jaska n! jde vypocitat vsude s pouzitim jednoho cyklu. To je houby rekurze. :)

Ale cyklus je speciálním případem rekurze. :-) Rekurzivní zápis je koncept (stejně jako třeba dynamické programování), nikoli implementace nějakým zásobníkem. :-) Fold je v SRFI-1 zcela určitě tail-rekurzivní, přinejmenším jeho referenční implementace poskytovaná se specifikací. Iota sice consuje, ale pak taky můžu použít SRFI-42 (early comprehensions) a zasat to jako (product-ec (:range i 1 (+ n 1)) i). ;-)

(Ale já jako starý commonlispový prase bych to napsal jako (iter (for i from 1 to 10) (accumulate i by #'* initial-value 1)). :-DDD)

No to jo, ale vetsina programatoru lamu maji vuci rekurzi nejaky blok; takze kdyz uvidi neco, co muzou nabouchat v jinym jazyce cyklem, tak si reknout: proc proboha pouzivat jazyk, ve kterem to musim (i kdyz nutne nemusi) napsat takhle i kdyz to nakonec dopadne jako cyklus (i kdyz tohle se z clanku taky nedozvi). Melo se to zkratka ukazat na necem netrivialnim, co si clovek cyklem (a pripadnym pouzitim zasobniku) nelajzne udelat, pac je to prasarna. Ale, skoda lamentovat. Jinak Common LISPu zdar! To je jazyk pro skutecne muze. Zrovna vcera jsem se kochal kusem cerstve napsaneho zdrojaku a rikal si: tak Javisti, chtel bych vas ted videt. :):):)

Jestli se na něco rekurze absolutně nehodí, pak je to právě výpočet faktoriálu. Nechápu, proč je rekurze vždy prezentována na tomto případě a to i ve školách. Daleko vhodnější příklad by byl třeba průchod stromem - kde má rekurze opravdu smysl. (Do šířky roste rychleji, než do hloubky). I když já i ten dělám zásadně bez rekurze - s využitím zásobníku. Možná mám blok - nebo taky poruchu osobnosti - ale aspoň poznám i po letech, co ten program opravdu dělá. Je totiž daleko čitelnější - i když, pravda, delší. Ve skutečnosti lze každou rekurzi nahradit zásobníkem ( a v podstatě ani o nic jiného nejde).Tvrdit, že jde o prasečinu, je poněkud odvážné. Nicméně pokud někdo nalézá v rekurzích zálibu (a programy mu chodí), nikdy bych si nedovolil ho zesměšňovat. Takový nadutec nejsem.

Na 95% suhlasim. Ja nemam az taky problem s rekurziou, mozno preto ze som kedysi pouzival aj LISP a prechod stromu by som iste radsej riesil rekurziou. V kazdom pripade by som ale chcel povedat ze rekurzia sa da urobit aj v Jave. Tam mate na vyber.

No ja nevim, ale mam pocit, ze jste krapet nechytili pointu. Ve scheme ma slovek samozrejme taky na vyber, existuje neco jako DO. Ale to je jedno. Pruchod stromem, pripadne grafem pomoci zasobniku je OK, to neni nejaky ukrutny problem, i kdyz citelnost programu vyrazne klesa. Na druhou stranu, kdo programuje cokoliv, kde treba upravuje symbolicke vyrazy, a dela to iterativne a se zasobnikem, je sam proti sobe, protoze je to prasarna jak hrom a neni to ani trochu odvazne tvrzeni. Jinak doby, kdy se lidi bali rekurze jsou snad ty tam, vic jak 64 kB RAMky uz mame snad vsichni, ne?

Fígl je v tom, že explicitní zásobník řeší jen jednu věc, a sice ten zásobník pushdown automatu. Má-li člověk třeba několik různých funkcí (třeba strom má několik typů uzlů), kterým navíc předává různé parametry, začne se to dost prasit - nebo aspoň mi cokoli jiného přijde hodně nepřirozené. Jak praví pánové Sussman a Steele, lambda (resp. volání funkce) je jen "goto s předáváním parametrů". Těmi funkcemi také hravě nahradím stavový automat, který bych v C asi musel psát smyčkou, protože pokud nemám zásobník, zařídí tail rekurze nulovou spotřebu zásobníku.

Když jsem onehdá zjistil, jak krásně lze klasický céčkoidní stavový automat typu "while smyčka se switchem na aktuální stav a přiřazením pro jeho změnu" nahradit tím, že mám pojmenované funkce, jejich názvy označují příslušné stavy a prostým zavoláním dotyčné funkce přejdu do příslušného stavu a ještě "syntakticky zadarmo" předám parametry, které daný stav může požadovat k rozhodování, docela jsem zajásal - nevím, ale skutečně mi přijde, že jsou případy, kdy je rekurzivní zápis o tolik průhlednější, že mě Cčko bolí (a kvůli "drobným problémům" s tail rekurzí v C to nelze tak snadno řešit). Dokážu to psát, to ano, ale dnes už jen z donucení. ;-) (Což neznamená, že bych byl rekurzivní bigot, leckdy taky rád smyčkuju, oni i Schemeři si píší loop makra, páč to _je_ často naopak zase čitelnější přes smyčku, a nebránil bych se ani TAGBODY/GO (ekvivalent GOTO, byť "poněkud" inteligentnější ;-)), kdybych třeba přepisoval něco z Knutha, který tak algoritmy zapisuje, a přepsat je mechanicky je největší záruka toho, že se přepis povede.)

S tím souhlasím. Nejsem proti rekurzím tam, kde jsou vhodné a používám je také. Ale přímá rekurze (A volá A) vhodným příkladem není. To je přirozeně iterační algoritmus. Já jen, že bychom neměli zacházet do extrémů.

Pokud se to napíše jako koncová rekurze, stejně to lze převést automaticky na iteraci. Na druhou stranu ovšem, pokud ten rekurzivní algoritmus provádí nedestruktivní operace, může systém ten algoritmus automaticky paralelizovat. Ano, čistě funkcionální přístup je extrémní, protože se nestará o konkrétní průběh výpočtu na daném stroji. To ale nemusí být nutně špatné.

Melo tam byt spise receno, ze u Scheme se primo v definici jazyka jasne rika, kdy se provede rekurze (skutecne volani funkce) a kdy se volani "rozbali" - tail recursion. Strasne moc zalezi na zapisu toho rekurzivniho volani a prave v tomto je Scheme docela dobre pro vyuku. Osobne jsem taky nikdy moc nechapal, proc nam rekurzi vysvetlovali prave na faktorialu, ktery se mnohem snaz zapisuje smyckou.

Tak tak, mnohem hezčí je tree fold, nebo na tail rekurzi nějaký ten pěkný stavový automat. :-)

Ach jo - já nevím, ale stále vidím, že při propagaci jiných jazyků se projevuje komplex méněcennosti zvaný musíme dokázat, že jazyk je rychlejší, než C/C++. A jako vždy i v případě Scheme jde o naprostý blábol - vyzývám autora, aby dokázal svoji tezi, že něco co vyleze kompilací Lispu je rychlejší, než ten samý problém efektivně zapsaný v jazyce C. Ale autor to prohraje "bez nadsázky" na plné čáře a odejde jako zmoklá slepice.

Jazyky C/C++ jsou už od základů zkonstruované pro max. rychlost a leccos v nich bylo ohnuto títmo směrem. To je jejich určení. Proti tomu LISP/Scheme/Java a další jazyky nebyly stvořeny z hlediska rychlosti a při pokusu srovnávat jejich rychlost v reálné aplikaci s C/C++ začínají se značným rychlostním handikepem.

Ach jo - já nevím, ale stále vidím, že při propagaci jiných jazyků se projevuje komplex méněcennosti zvaný musíme dokázat, že jazyk je rychlejší, než C/C++. A jako vždy i v případě Scheme jde o naprostý blábol - vyzývám autora, aby dokázal svoji tezi, že něco co vyleze kompilací Lispu je rychlejší, než ten samý problém efektivně zapsaný v jazyce C.

Jen abyste se nedivil. Dokonce i Jon Harrop, slavný to flamer, co na comp.lang.lisp a comp.lang.scheme leze jen proto, aby tam pořád protlačoval Ocaml a všechny jen soustavně nasírá, byl nucen přiznat, že raytracer napsaný autorem Stalina je rychlejší, než tentýř program zapsaný v C/C++, Ocamlu a MLtonu. Thread máte tady, můžete zkusit napsat lepší kód v C a Siskindovu verzi přebít. Tedy máte-li na to koule. ;-)

Bohužel neuznávám. Kdysi jsem prošel asi dvacet testů "dokazujících", že Java je rychlejší, než C++. Asi jsem byl jediný poctivý, který prolezl vždy celý test včetně zdrojových kódů a došel jsem k jedinému závěru - jediné co ty testy dokazovaly je pomalost neefektivně napsaných program v C++. Vždy se program v C++ dal většinou velmi jednoduše upravit na rapidně vyšší rychlost a pak test dával zcela jiné výsledky, které si ale žádný javista nepřál vidět.

Tehdy jsem se rozhodl, že nebudu ztrácet zkoumáním dalších testů čas a to zvláště, pokud test není proveden se snahou o serióznost - tj, nejsou přiloženy zdrojové kódy a autor testu se nesnaží o maximální využití prostředků daných jazyků k max. rychlosti. V tom odkazu, co jste napsal tyto podmínky splněny nejsou - jsou tam pouze výsledky bez ničeho - na to se hodí napsat jenom Churchillovo "Věřím jen statistice, kterou si sám zfalšuji".

Je prostě absolutní nesmysl, aby high level jazyk s dynamickými konstrukcemi přebil dobře napsaný C/C++ program v rychlosti. Je to nesmysl už z podstaty a žádným SERIÓZNÍM, zdůrazňuji SERIÓZNÍM a KOREKTNĚ PROVEDENÝM testem vám nikdy tento výsledek nevyjde.

Kde jsou "výsledky bez ničeho"? Zdrojové kódy (čtyř variant raytraceru v pěti jazycích) samozřejmě přiloženy jsou. Jinými slovy, tu statistiku si můžete "zfalšovat" klidně sám. Tomu "autor testu se nesnaží o maximální využití prostředků daných jazyků k max. rychlosti" moc nerozumím, Harrop je ocamlista až za hrob a Siskind zase autor nejlepšího kompilátoru Scheme na světě (a to "Scheme" by z toho možná i šlo vynechat), takže pokud jde minimálně o ML a Scheme, tak lepší implementátory aby člověk pohledal - jaképak "nesnaží se"? Dali si na tom sakra záležet. C++ hodnotit nemohu, při pohledu na C++ je mi blivno, takže zbýváte Vy. Vám důvěřuji, že na review C++ kódu určitě máte lepší kvalifikaci než většina z nás. ;-)

Ano, a takhle přesně vznikají bláboly a fámy o jazycích "rychlejších, než C/C++". Nikdo z autorů testu pořádně C/C++ neumí (a zejména dobré a efektivní programování v C++ chce podle mě roky praxe - je to složitý a náročný jazyk, ale s neuvěřitelnými možnostmi). Ani Vy, ani další zastánci toho jazyka "rychlejšího, než C/C++" nenapíšou nic jiného, že jim je z C/C++ blivno.

Proboha, co čekáte za jiný výsledek, než že C/C++ bude "pomalejší"? Když někdo programuje v něčem, co pořádně neumí, pak je výsledek předvídatelný - nenapíše v tom dobrý program. Jestliže píšu program v jazyce, na který jsem levý jako šavle - a žádný z autorů se nepochlubil mnohaletou praxí v C/C++ (opravte mě, pokud se mýlím), pak taky výsledek bude stát za velké kulové. Což je celkem normální, ale tragédie je, když takové lidé to vydávají za "seriózní" test a dokonce z toho zcela nesebekriticky vyvozují nějaké rádobyplatné závěry.

Uhýbáte od tématu. ;-) Jsou jen dvě možnosti - buď je Stalin skutečně schopnější než lidský programátor v C (protože dokáže provádět celoprogramové analýzy životnosti objektů, inferenci datových typů a podobně), nebo je prezentovaný kód v C++ špatný/subtoptimální/whatever. V tom druhém případě je řešení jednoduché, stačí to napravit a upozornit autora, že se mýlil. :-) Ať už to uděláte Vy, nebo kdokol jiný, komu na C++ záleží. Přijde mi ale divné, že by Siskind neuměl dobře přinejmenším C - ostatně musí umět C co nejlépe, aby ho mohl ve Stalinovi používat jako "přenositelný assembler". (Ten generovaný kód je sice hnusný, ale stačí, aby byl prokazatelně správný, což je. :-)) U Harropa bych se tomu nedivil, kdyby v tomhle trošku kulhal.

Neuhýbám od tématu - jen mě už nebaví participovat na dalších experimentech dokazujících, že "foukáním tabákového dýmu do vody zlato nevzniká". Už jsem se podílel na zneplatňování mnoha testů dokazujících, že nějaký jazyk je rychlejší, než C/C++ a to co píšu jsou jen poznatky z těchto testů.

Mě je úplně jedno a moje štěstí nijak nezávisí na tom, jaké bláboly a nesmysly si tam píší v nějaké diskusi. Na světě běhá tolik lží a blábolů, že kdybych měl ambice bojovat za napravování všech omylů, o kterých vím, asi bych nedělal nic jiného. A čas je docela vzácná komodita.

Jenom píšu, že v článku je blábol o tom, že je něco ve stylu LISP/Scheme rychlejší, než C/C++. Zajímavé je, že pokud bych někde viděl psáno, že třeba (například) Fortran je rychlejší, než C/C++, nedovolil bych si to jen tak zpochybnit a považoval to za možné. Ale u LISPu, Scheme a dalších je to naprostá blbost - tyto jazyky se pouze limitně mohou rychlsotně blížit k rychlosti dobře napsaného programu v C/C++.

A víte, že na Crayích v osmdesátých letech spousta lidí radši používala Lisp než Fortran? Protože Lisp tam byl rychlejší... :-D

Faktem je, že principielně máte pravdu: V C máte k dispozici inline assembler a v podstatě Stalin není schopen napsat nic, co byste nedokázal napsat Vy. Jenže Stalin zase umí jiné věci: Například umí globálně v celém programu v čase kompilace (!) provést analýzu toho, kde začíná být která proměnná zapotřebí, a kdy zase je již prokazatelně nepřístupná. Většinu zdánlivých "lispovských malloců" pak převede na rezervaci místa na zásobníku, nebo sdružuje data do větších struktur, které alokuje a ruší najednou. Takhle se dokáže zbavit obrovského množství alokací a dealokací, takže i když má garbage collector (Boehmův GC), většinu času ho běžící program ani neprocvičuje. Člověku by to v Cčku zabralo hodně času promyslet, a taky je otázka, jestli by to dokázal napsat bez chyby - k leakům dochází, i pokud člověk zapomene na free() i tehdy, pokud s jejich umístěním moc nešaškuje.

Podobným způsobem vytváří také částečně aplikované nebo jinak specializované monomorfní funkce, takže tam, kde by interpret Scheme musel řešit typy za chodu, tam spustí Stalin třeba nad vektorem čísel funkci bez jakýchkoli kontrol typů - provedl je v čase kompilace. Podobně pracují i jiné jazyky, třeba právě ML, ale Stalin provádí věci, které žádný jiný kompilátor nedělá, třeba tu nesmírně precizní analýzu práce s proměnnými.

Za to, čeho se tím dosáhne, se ale přeci jen platí jistá daň: Stalin neumí ani celé R4RS Scheme, ale jen tu část jazyka, která se takovýmto analýzám podvoluje, a čas kompilace je astronomický. Ale může to být zajímavý cíl pro generátory kódu, protože člověk zadarmo získá všelijaké zajímavé optimalizace a závorky není tak těžké generovat. ;-)

Ad 1) Ohledně Craye jde o kvalitu jední instance kompilace/interpretru, nikoli o možnostech jazyka jako takového.

Ad 2) Já netvrdím, že Stalin neumí třeba mistrovsky optimalizovat, ale když přijde na věc a rozdá si to s člověkem kovaným v C/C++ tak to rychlostně na 100% prohraje. Navíc jak říkám, rozumný člověk dnes píše v C jen ze dvou důvodů: a) neexistuje pro danou platformu dobrý C++ kompilátor, nebo b) neumí C++ a tak je nucen přijmout mnohem horší C. Efektivita a rychlost toho co napíšete v C++ je ve výsledku stejně rychlá jako v C, ale brutálně se liší komfortem programátora v obrovský neprospěch C. Jen pro Vaší informaci - píšu v C++ mnoho let a nutnost garbage collectoru jsem nepocítil - ani si moc nevzpomínám, kdy jsem naposled v C++ musel starat o uvolňování dynamické paměti (no dobře čas od času ano, velmi zřídka). Jazyk C++ nemá garbage collector, ale má jiné, velmi efektivní prostředky pro práci s pamětí. To je právě ten problém, který si uvědomí až člověk s dlouholetou praxí v C++ - ty vyšší jazyky nemají až takový náskok vůči C++ jak se zdá a C++ za člověka udělá automaticky velmi mnoho věcí. A to je proto, proč ty testy začínám ignorovat - člověk bez praxe v C++ na to nepřijde a nedocvakne mu to, že 90% věcí z high levelů jazyků má k dispozici též. To je možná důvod, proč se Stalin raději komfortem programování a efektivitou srovnává raději s C, protože hlavně v tom okmfortu by měl daleko těžší pozici vůči C++.

Ad 3) Naprosto souhlasím.

No, jestli někdy někde nadhodíte nějaký kód v C++, který berete za příklad efektivity C++, a dotyčný kód nebude proprietární, jistě se někdo rád pokusí přepsat ho do Stalina. :-) Které efektivní prostředky pro práci s pamětí máte na mysli? Snad ne reference-counting smart pointers, to je přesně to, co Stalin dělá "v čase kompilace", aby si nemusel dělat přehled za chodu. :-) Ale přiznávám, že se v C++ možná mimo věcí v STL a spol. objevilo i něco lepšího, nejsem na tohle expert a ani nechci. :-) (BTW, v tom testu se Stalin srovnával zrovna s C++, ale toho jste si určitě všiml. :-))

Osobně ale myslím, že dobrý C++kař schopný abstrahovat a využívat prostředky jazyka by byl i dobrý lisper, takže to nakonec asi zase bude o lidech. Přesto se nemohu ubránit pocitu, že C++ má oproti Lispu "určité nedostatky" (na které jsem prostě možná citlivější než někdo jiný, třeba Vy ;-))... Už jen ty návrhy alternativní syntaxe, na kterou by se i dal napsat normální parser, o něčem vypovídají (já si třeba rád píšu vlastní tooly pro práci se zdrojovým kodem, ale zkuste to v C++ konzistentně - v Lispu je to hračka, navíc parser je exponovaný jako API).

Ad 1) První větu jsem nepochopil, ale budiž. Jinak je na Vás vidět, že se moc soustředíte na STL, a přitom C++ má spoustu možností přímo v jazyce samém, včetně i další automatické práce s pamětí. Ale nic, to dělá každý začátečník bez praxe v C++ :-) (take it easy).

Ad 2) Jsem si jistý, že dobrý programátor může být dobrý v jakémkoli jazyce.

Jinak ten dokument s "určitými nedostatky C++" jsem měl tu čest kdysi vidět - rád bych Vás upozornil, že v tom dokumentu jsou značné chyby a dost často bohužel i lži, kdy tvrdí že C++ se chová tak a tak, ale ono to dělá úplně jinak. Takže ten dokument s "určitými nedostatky" je velmi velmi známý mezi C++ jako dobrý vtip - protože evidentně ten autor C++ neovládá ani v základním levelu a tvrdí tam takové ptákoviny, že se třískáme hlavou o stůl. Zejména do očí bijící je autorova naprostá neznalost chování C++ při výjimkách. A to vůbec nemluvím o tom, že hovoří o g++ a nazývá to C++. Jo jo, tenhle dokument hodně rozšířujte, hlavně mezi znalci C++, uříznete si pořádnou ostudu. Příště prosím argumenty od člověka, který alespoň nedává tak okatě najevo, že nezvládl ani první lekci C++.

Stejně tak návrhy alternativní syntaxe nic nevypovídají o C++, stejně tak já bych Vám navrhnul alternativní syntaxi pro LISP, se kterou bych byl více spokojen, ale jak jistě uznáte o LISPu to nic neříká.

Jinak rád bych to uzavřel smírem - nikomu neberu jeho oblíbený jazyk a ani já nejsem zastánce C/C++ všude. Ale pokud jde o rychlost, C/C++ je prostě formule 1 a to mu nikdo neodpáře. Nechápu proč LISPaři a Schemaři mají kompexy z toho, že nejsou nejrychlejší, když byly dělány s ohledem na jiné priority.

pane Ponkrac,

prijde mi ze jdete sam proti sobe.cetl jsem vassi debatu s rejpalem a zpocatku jsem plne souhasil s vami,pak uz me to prislo jako remiza,ale ZASADNE nemuzu souhlasit s vami v "c++ je optimalnejsi nez c" a to presne s tou samou retorikou jako vy pouzivate proc scheme nemuze byt jako c++.obecne,libovolny vyssi jazyk nemuze byt optimalni jako jazyk tridy nizsi,trajektorie c++ -> c -> assembler je jasna.nema cenu resit konkretnosti,pracuji s c/c++ relativne dlouho a zrovna v oblasti jako je 3d grafika a simulace,ono staci sledovat kolik je odporu proti budouci verzi OpenGL v C++,protoze tam na vykonu OPRAVDU zalezi.
v podstate,spickovy programator v C/C++ jiste zustane neprekonan cimkoli z vyssich jazyku,ale verim ze 75%tni programator uz porazen byt muze,jestli zrovna Stalinem nebo Breznevem to si netroufam soudit protoze Scheme znam jen ze skoly

Problem je vsak v tom, ze Stalin nepodporuje nektere
veci, co jsou v poslednich standardech jazyka Scheme,
takze je pro nektere programy nepouzitelny.

Měkteří lidé si myslí, že R6RS Scheme je nepoužitelné, resp. že to už není Scheme. :-) Takže to je možná skoro až přednost. :-D Ne, vážně, Stalin je hodne specializovaná záležitost, a i pro schemery je o něm spíš dobré vědět, pro případ, že by to člověk potřeboval, ale na každodenní používání to asi není. Já si například ukrajuji chleba k snídani poměrně běžně, takže se bez něčeho, co umí krájet, neobejdu, ale jen zřídkakdy si na chleba beru motorovou pilu. ;-)

Já osobně věřím tomu, že optimalizace, co dělá Stalin, jsou pro lidského programátora nehratelné.

Ono je totiž rozdíl udělat "rozumný" program (tj optimalizovaný, ale pořád ještě čitelný) a optimální program z hlediska rychlosti (tedy takový, že už žádný lepší neexistuje). Člověk by asi nakonec toho Stalina porazil, ale za jakou cenu: naprosto nečitelný program - organizovaný chaos. V kategorii "rozumných" programů člověk IMO prohraje.

BTW: Miroslav Ponkrác je asi nejdrsnější diskutující, co znám. Ten ze svého přesvědčení neuhne ani o píď.

Problém je, že něčemu věříte, ale nevíte to. Já si zase nemyslím, že by to tak v praxi bylo.

Já bez problémů přeberu názor druhého, ale musí být podložený. A po důkladném prostudování asi dvaceti testů, že Java/Lisp/cokoli je rychlejší, než C++ jsem velmi přesvědčen, že není a ani nikdy být nemůže.

Jinak bych chtěl ještě dodat, že C/C++ byly už navrhnuty s ohledem na max. rychlost. Mají to dané do vínku a bylo v zájmu autora zejména C++ aby rychlé programy byly taky zároveň čitelné. Asi cítíte, že je blbost navrhovat záměrně nečitelný jazyk.

Prosím vás, o tom netřeba diskutovat. Kdokoliv kdo tvrdí, že obecně lze říct, že program napsaný v Javě je rychlejší než to samé naspané v C++ se okamžitě odhaluje jako totální lama a další diskuse postrádá smysl.

Tu by som si dovolil nesuhlasit. Vysledny strojovy kod z C/C++ je produkovany raz a zalezi na kvalite kompilatora. Pri jazykoch, ktore su kompilovane v runtime ma virtualny stroj moznost dodatocne strojovy kod optimalizovat podla potreby. Samozrejme, ze tu existuje moznost profilovania kodu a potom pouzitie dat pri kompilacii, ale vysledne ide opat o jednorazove prekompilovanie a so strojovym kodom sa nepohne (neberme do uvahy nejake polymorfne kody).
Takze vysledne je tu sanca ze v pripade kvalitneho runtime kompilatora bude urcity kod naozaj rychlejsi, pretoze ma k dispozicii nieco naviac a je preto schopny prislusne optimalizovat dany kod za behu. Je vsak uplne samozrejme, ze to nie je obecne platne tvrdenie a zalezi na prislusnej aplikacii. Tymto som len chcel vyjadrit skutocnost, ze v pripade rozhodovania o pouziti jazyka o tom diskutovat treba a nejedna sa o prosty fakt.

Problém je, že tu šance, ale v praxi jsou prostě virtuální stroje pomalejší. A to z důvodů:

1) To co virtuální stroj teoreticky může získat runtime optimalizací více, než bohatě a daleko víc ztratí tím, že jazyk toho virtuálního stroje provádí není tak bohatý na možné low level optimalizace jako je C/C++.

2) Optimalizovat strojový kód za něhu podle potřeby je drahé - stojí to čas a tak je virtuální stroj postavne před volbu buď a) optimalizaci odfláknout, ale bude to rychle hotové, a nebo b) optimalizaci udělat pořádně, ale to strašně dlouho trvá a přičítá se to k výslednému běhu aplikace. Takže výsledkem v praxi je zase kompromis plus dlouhý start aplikace.

3) A nejdůležitější je, že ono zase tak není moc co na virtuálním stroji optimalizovat oproti optimálnímu výstupu z C/C++. Možnosti runtime optimalizace na virtuálních strojích a jejich možnosti se v diskusích značně, ale příšerně zveličují, ale ve skutečnosti tak moc toho zase není. Zde virtuální stroj nemá takové možnosti jak se zdá - kromě nějakých globálních drobností a kromě přizpůsobení se reálnému procesoru nula nula nic. A nějaká dobrá profilace kódu za běhu zase zpomaluje běžící kód, takže je otázka.

Ano, čistě teoreticky virtuální stroj může optimalizovat. Čistě prakticky i tato optimalizace má režii - tedy zpomaluje a jste tam kde jste nechtěl být. Takže v praxi se virtuální stroj moc rozšoupnout nemůže a C/C++ bude rychlejší. Znovu říkám, dokažte na praktickém seriózním testu (= max. optimalizované programy, použití kvalitní kompilátoru, tedy rozhodně ne gcc/g++ a další), že virtuální stroj je rychlejší. Nedokážete.

Samozrejme s 95% co ste napisal suhlasim a snazil som sa aj moj predchadzajuci prispevok tak koncipovat aby to z toho bolo jasne (mozno nebolo). Nemyslim vsak ze mozete s kludnym svedomim napisat "virtuální stroj moc rozšoupnout nemůže a C/C++ bude rychlejší", pretoze uz z logiky veci je jasne, ze v pripade, ze virtualny stroj v runtime skompiluje program do podoby aku ma vystupny kod z Vami uvadzaneho (akehokolvek) C/C++ (a aj ineho) kompilatoru tak samotny beh tohoto kodu bude rychlostne ekvivalentny. Samozrejme s reziou na kompilaciu a pamatove naroky pri startupe ale to je jednorazova aktivita a moze sa v tomto pripade zanedbat.

Dalej samozrejme mozeme rozoberat a teoretizovat, co este bude mozne vdaka runtime kompilacii v (blizkej) buducnosti dosiahnut - dokazete si napriklad predstavit ze virtualny stroj skompiluje a spusti cast Vasho programu v grafickom koprocesore? Ja ano a som si isty, ze je ovela viac menej obskurdnych technik, ktore dokazu kod uchychlit oproti statickej kompilacii.

Dneska uz se pise na prehlednost, architekturu a upravitelnost. Uz se tolik nemusi hlidat proceosr, pamet atd. Pozn.: jsem ze stare skoly, takze jsem tak byl zvykly premyslet - optimalizovat uz pri navrhu.

Byl pouzit kompilator g++ coz je velmi mizerny prekladac pro goniometricke vypocty a pro vypocty s plovouci desetinnou carkou je taktez podprumerny.

Možná jsi to nepostřehl, ale Stalin použil v tomto případě jako svůj backend taktéž gcc. (Totéž dělají i Ocaml a GHC.)

GCC/G++ jsou velmi mizerně optimalizující kompilátory. Pokud nepočítám kompilátory firmy Borland (které jsou naprosto tragické), pak už horší kompilátor z hlediska optimalizace, než je GCC/G++ nenajdete.

Je jedno, co používá Stalin pro svůj backend, ale tady je právě rozdíl mezi dobře optimalizujícím kompilátorem a GCC/G++. V dobře optimalizujícím kompilátoru prostě píšete lidsky, čitelně v C/C++ a nemusíte se soustředit na optimalizace a kompilátor to zoptimalizuje. V takovém dobře optimalizujícím kompilátoru by Stalin ztratil své výhody značným tempem. Ve špatně optimalizujícím kompilátoru jako je GCC je nutné při psaní maximálně efektivního kódu mu ručně pomáhat, tedy zbytečně přizpůsobovat styl psaní v C kompilátoru a Stalin je tam pak na koni.

Hmm, to by mohlo dávat určitý smysl. Ovšem, možná bych se měl zeptat Siskinda, jestli v tomhle směru podnikal nějaký výzkum. :-) Pokud by ale třeba intelí kompilátor C++ nebyl v průměru o 35-40% rychlejší, což už by byl velmi postřehnutelný rozdíl, nad kterým by asi spousta lidí řvala, protože uživatelů obojího je hodně, tak to stejně nedorovná. :-) A zas takové řvaní jsem nezaznamenal, stejně jako lepší výsledky jiných kompilátorů (25 % výkonu v Blenderu z ICC byl pro mě velký svátek, a to ještě nefungovalo nad všemi daty, s jinými scénami to bylo třeba jen 10 % nebo taky nic.)

Zeptejte se člověka, který v tom podnikal výzkum :-) Já jen, že v tom řadu let mnoho hodin dělám, a nejenom občas pořádám občasné výzkumy :-)

Intel kompilátor je hlavně velmi citlivý na optimalizační parametry, které mu zadáte v příkazové řádce. Pokud si pohrajete, jde hodně.

Řvaní nezaznamenáte, protože dnes mají počítače pro běžné věci výkonu nadbytek a lidi ani zvednutí rychlsoti programu o 100% ve většině případů nezaznamenají, pokud se nejedná o kritické části.

Ale hlavní přínos dobře optimalizujícího kompilátoru je v tom, že můžete psát lidsky v jazyce a on to vychytá. Kompilátor pak napadne, že váš cyklus se dá efektivněji provést trochu jinak, než jste ho napsal, a že jednou použitá funkce se dá inlinovat i když to nepředepíšete a tisíce dalších věcí. Dobrý kompilátor udělá i celkovou globální optimalizaci proměnných a všech objektů v programu.

Takže pak špatně a neoptimalizovaně napsaný program v C začátečníkem (ale s dobrými algoritmy) v dobrém kompilátoru se výslednou rychlostí vyrovná programu napsaném optimalizovaně a s péči (se stejným algoritmem). U špatného kompilátoru jako je gcc jsou ty rozdíly ve výsledné rychlosti obou verzí značné. Proto taky všelijací zastánci jazyků "rychlejších, než C/++" milují gcc/g++, protože ten houby s octem zoptimalizuje a velmi graduje rozdíl v každé napsané čárce ve zdrojovém kódu C/C++ a pak excelují automatické generátory typu Stalin apod.. Všimněte si, že 100% všech testů, které ukazují jazyk "rychlejší, než C/C++" je provedena na gcc/g++. GCC/C++ jsou opravdu hodně špatné kompilátory. Na jiných kompilátorech by všech těmto testerům rychle spadl hřebínek.

Mozem sa spytat, ktore su tie dobre optimalizujuce kompilatory ?

Tohle myslím vychází z nějakých studií, že programy v Lispu jsou obecně rychlejší než C/C++. Je to ale čistě jen o metodice.

Nechá se x lidí napsat program, a x/2 to píše v Lispu a x/2 v C. Potom se udělá průměr rychlostí všech Lisp a všech C aplikací a ... Lisp vyhraje. To ovšem neznamená, že by nejrychlejší aplikace byla v Lispu. Nejrychlejší je v C, ale ten průměr s tím udělá svoje.

Je to stejný flame jako Asm x C. Nikdo nepochybuje, že Asm by v takovém testu měl nejrychlejší program, ale v průměru by bylo rychlejší C. Proto se dneska v Asm píší jen části programu.

A v tom je síla Lispu/Pythonu/... Celkem rychle napíšu prototyp aplikace s výhodami těchto jazyků, pustím profiler a pomalou část přepíšu jako C knihovnu (popřípadě C + ASM). Ve výsledku bude aplikace stejně rychlá jako optimalizované C, ale bude napsaná mnohem rychleji.

Ano, s tímto bych naprosto souhlasil (až na nepodstatné detaily).

Ono C je v podstatě jen "prekabátěný asm", takže o nic nejde. Proto se také větší a rozsáhlejší projekty, kde záleží na efektivitě běhu programu už dávno píší v C++ a nikoli v C.

A pokud na efektivitě programu nezáleží, a nebo jsou jiné priority, pak tu máme Python, Javu, C#, Ruby, Lisp, Scheme, Smalltalk, ...

Hmm, to mi zase tak věrohodně nezní. Pravda je, že klasické lispovské kompilátory (třeba Allegro, LispWorks nebo Scieneer) odvádějí velice dobrou práci, hodně blízkou C/C++, ale většinou pomalejší co do generovaného kódu. To ani lispeři nepopírají, i když práce, kterou dokážou odvést na vnitřních smyčkách, je leckdy pozoruhodná.

Fígl je ovšem v tom, že má-li člověk takovýhle kód k dispozici po čtvrtině času, co v C/C++, může si začít vyskakovat. A to třeba s profilováním, přepisem části kódu do C/assembleru, vylepšováním algoritmu, v případech takových věci, jako jsou genetické algoritmy, může zapojit kompilátor (!) do práce za chodu aplikace, generované algoritmy rovnou kompilovat s minimální prodlevou přívo uvnitř a ladit, ladit, ladit... Výkon aplikace je většinou o lidech :-), ale Lisp dává lidem co do nástrojů maximum, a do interaktivního vývoje dává doslova celé srdce - turnaround je v řádu sekund, ne minut, opravy bugů můžu klidně provést v půlce běhu programu a pokračovat od bodu přerušení, nemusím neustále načítat zkušební datasety a podobně (to první a poslední nabízí třeba i Python, to druhé znám jen z Lispu a Smalltalku...). Pak je člověku hned víc hej, ne? ;-) Interprety C a C++ sice znám, ale moc bych v nich dělat nechtěl. ;-)

Fígl je v tom, že mluvíme-li tedy o rychlosti, je jasné, že LISP/Scheme nemůže z principu být rychlejší, než v C/C++, budeme-li soutěžit v rychlosti. Jsem moc rád, že jsme se konečně shodli. A to bylo to co jsem obhajoval.

Problém je jeden, C++ nemá prakticky konkurenci, pokud chcete udělat maximálně efektivní a rychlý program - s výjimkou asm. C++ je pro tyhle věci nenahraditelné a stejně C/C++ tepou v srdci všech těchto kompilátorů/interpretrů LISPu/Scheme/Javy a dalších.

Jakmile jdu výš a chci různé vychytávky pak už mám na výběr obrovské množství plus mínus rovnocenných jazyků podle toho co přesně za vychytávky požaduji. Máte LISP, Scheme, Smalltalk, Javu, Python, Ruby, ... - kde zvládne nějaký vývoj i nezkušený programátor a kde výsledke máte rychleji, než v C/C++.

Třeba právě tak jako Vy nemůžete přijít na chuť C/C++ (aniž bych tím říkal, že jsem fanatický fanda těchto jazyků), já nemůžu přijít na chuť LISPu. Ovládám ho, ale počet primitiv toho jazyka mi přijde už příliš malý na to, aby byl přehledný a udržovatelný rozsáhlejší kód. Možná právě proto ho v praxi není vidět tak často jako jiné mainstreamové jazyky. I když uznávám, LISP je nádherně čistý jazyk a obdivuji ho pro jeho geniální koncepci - bez nadsázky ten člověk co ho vymyslel musel být génius. Ale nechtěl bych LISP používat v praxi.

Hmm, většina lispů, co běhala na holém železe, mela i integrovaný assembler, a mnohé ho mají i dnes na PCčkách. :-) Takže by ty dva vztahy (Lisp ≤ C/C++) a (Lisp ≥ C/C++) šly zredukovat na pouhé (Lisp ≡ C/C++) :-) A to ne co do výpočetní úplnosti, ale spíš v tom smyslu, že se dá obojí dokopat přesně k témuž, s větší či menší námahou. :-D

A mimochodem, já mám céčko velice rád, ostatně jsem se s ním potkal v devíti letech a asi to ve mně nějak zůstalo... Nicméně v otázce "co nad ním?" jsem se asi trošku odklonil. :-) A pokud v Lispu něco chybí, no, to je jeho největší síla - úplná makra, jejichž slabý odvar sice v C++ je taky, ale už jen tím, že jsou v C++ psána v jiném (byť turingovsky úplném) jazyku omezuje jejich použitelnost jen na první řád transformace. To by mi asi trošku chybělo, protože transformace druhého řádu mají leckdy opodstatnění (už jen obyčejné with-gensyms je skoro nutnost pro kohokoli s mozkem na správném místě).

Myslím, že diskuse už se odklonila od odstaty problémy - a to, že jsem chtěl vyvrátit nesmysl o překonané rychlosti C/C++ Stalinem.

Jinak psát v integrovaném asm a psát v C je dost kvalitativní rozdíl, takže se obávám, že při psaní max. rychlého programu tady bude s dobou vývoje C naprosto excelovat.

Já C nemám moc rád. Přiznávám se bez mučení, přestože mě programování v C živilo hezkou řádku let, a tehdy jsem ho rád měl. Pak jsem poznal C++ a Adu a nějak jsem přišel na to, že v C budu psát jen v případě nutnosti. Možná se mi C++ líbilo i proto, že jsem zažil jeho předchůdce Simulu - velmi dobrý jazyk. Byl jsem nějaký čas okouzlem Smalltalkem, až mě znechutila ta vázanost na jeho prostředí a nezapadnutí do běžného systému. Pak jsem zkusil Ruby, ale to se mi oproti Smalltalku zdálo značně zmatené a nedomyšlené, ačkoli to měl být jeho zastánce. Python mě nezklamal, líbí se mi. LISP mě samozřejmě neminul, v minulosti to byl daleko rozšířenější jazyk, než dnes a víc se o něm mluvilo a víc se v něm dělalo, ale nezaujal mě - mám pocit, že příliš minimalistický jazyk je sice mocný, ale ztrácí přehlednost a praktickou užitečnost. LISP mě víc nadchnul koncepcí, než užitečností. Pak jsem se také setkal s jazyky, které se mi pranic nelíbily - Perl, Java. A pracovně jsem samozřejmě dělal i s dalšími jazyky, ale to nemá smysl uvádět. Prostě každý má jiné preference a jde jinou cestou a tak je to naprosto správné, neexistuje žádný nejlepší a nejhorší jazyk - každý má jinde své slabé a silné stránky a každý sedne jinému člověku jinak. Tak ať se nám všem dobře programuje, ať už používáme cokoli.

> je jasné, že LISP/Scheme nemůže z principu být rychlejší, než v C/C++

A dokázat* to chcete zhruba jak?

*Ne, důkaz _není_, že budete do zblbnutí opakovat, že ty jazyky jsou navržené pro maximální rychlost a že to prostě víte a že to tak je a nikdo to nemá zpochybňovat.

mne se nechce rypat... ale ja jsem myslel, ze pokud mame algoritmus implementovany v c++ a ten samy algoritmus implementovany v lispu, tak oba dva programy lze prevest na ten samy turinguv stroj... a ten na ten samy kod jazyka realneho stroje...

Tak to je sice pravda, ale to bychom museli navíc předpokládat, že z C++ leze ten kód nejrychlejší možný (a pokud bychom si tu nerovnost vyložili jako ostrou, tak ještě, že pro jiné jazyky to není možné) aby tamto byla pravda, což se mi jen tak sám o sobě nechce.

v _idealnim_ pripade ta nerovnost tam logicky musi byt neostra a dva ruzne prekladace generuji pro stejny algoritmus stejny (nejrychlejsi) kod... takze tvrzeni pana ponkrace o tom, ze C++ musi byt "z principu" rychlejsi nez Scheme/Lisp jsou postavana na vode...

Ad 1) Proč chodit kolem horké kaše - napište to rovnou: Mizerný rychlokvašný programátor určitě dosáhne spíš výsledky v LISPu, než v C.

Ad 2) Děláte z C záležitost obtížnější, než stavba atomové elektrárny. Tak to není - C je velmi jednoduchoučký jazyk. Profíků, kteří ho velmi znají je obrovské množství po celém světě. S optimalizacemi také nesouhlasím - stejně tak i v LISPu se dá psát kód méně a více optimálně a samotný LISP to optimalizacemi na 100% nevykryje. S tím soustředěním se na optimalizační věci nemáte v C pravdu - nemusíte se soutředit na nic, když ho znáte a máte ho v krvi. Pro informaci, programoval jsem už v řadě jazyků a ať to byl jakýkoliv, pokud ten jazyk dal k dispozici dostatek prostředků - vždy se dalo soustředit přímo na algoritmy, nikoli na optimalizaci. Je úplně jedno, jestli mluvíme o C, C++, Adě, Smalltalku, PHP, LISPu, atd.. - pokud se soustřeďujete na optimalizaci, pak to znamená, že ho neumíte. Je to asi stejné, jako koktavý člověk se musí soustředit na správnou výslovnost, zatímco běžní lidé prostě na výslovnost už nemyslí. A se závěrem - nebuďte křen a napište pravdu: Ve výsledky vždy půjde napsat program v C rychleji a efektivněji, než v LISPu. A o soustředění na optimalizační věci jsem už napsal své, soustředit se musíte jen na to co neovládáte.

Jinak znovu píšu, není důvod psát v C, od té doby co existuje C++, ve kterém vznikají naprosto stejně efektivní programy jako v C, ale C++ má nesrovnatelně vyšší komfort a možnosti pro programátora.

Dovolim si vas opravit ohledne koktavosti. Tam je to presne opacne, clovek zacne koktat prave v okamziku, kdy se zacne soustredit na vyslovnost...

takze pan P.:
1.) aky este iny jazyk poznate okrem C/C++ ?
2.) hovoria vam nieco veci ako kontinuacia, zipper, fold, lazy evaluation, referential transparency, lisp makra, erlangovske procesy, korutiny, generatory...?

pisal som v asm/c/c++ vela rokov, okrem ineho som v nom napisal aj mikrokernel OS, embedded veci a server soft napchany pthreadmi.

prestal som v nom pisat, lebo zlozite veci v tychto jazykoch ide pisat len velmi tazko (za hranicami 99.9% programatorov). Medzi zlozite veci radim napriklad pisanie kompilatorov grafovych patternov a podobne.

pripadate mi ako zakomplexovany trtko, ktory sa tu hada v 2 instrukcie, a nevie vobec nic o stavbe kompilatora, o SSA, CPS, ANF transformaciach, nic o lambda calculus a podobne.

je mi jasne ze nic neviete o tom co som tu pisal, ale ked vyrastiete zo svojej programatorskej puberty, a konecne budete robit tak komplexny projekt kde vam zufalo slabe "abstrakcie" c++ nepostacia (a poznam a pouzival som kniznicu boost, takze klud), mozno vam trkne v gebuli.

Děkuji, poskytl jste mi dostatek informací abych pochopil, že jakákoli odpověď a polemika s Vámi je zbytečnou ztrátou času. Myslete si o mě co chcete, je to Vaše svaté právo a přeji Vám hezký den.

Prilis mnoho neznamych pojmu, ze jo ;) Ale nesouhlasim se stylem jakym to ten clovek napsal.

Žádný neznámý pojem. Jen pro Vaší informaci, LISPem jsem se před nějakým časem dosti úspěšně živil, stejně tak jako jinými věcmi. Ale pokud je proti Vám někdo nabroušený, je lépe ho nechat, ať se jde zchladit a jde si třeba někam zahulákat, nebo zahulit a nechat ho žít v jeho agresívním prohnilém světě samotného. Je to jeho problém, že mu vadím, ne můj. Proč bych měl na sebe přejímat jeho problémy?

Pan Ponkrac, neda mi to a musim reagovat... podobna reakcia (ako ta o kusov vyssie) na Vase prispevky musela skor ci neskor prijst... lebo ked pisete veci ako (teraz len tak namatkou vyberam, bolo toho viac):

"je jasné, že LISP/Scheme nemůže z principu být rychlejší, než v C/C++"

"LISP mě samozřejmě neminul, v minulosti to byl daleko rozšířenější jazyk, než dnes a víc se o něm mluvilo a víc se v něm dělalo, ale nezaujal mě - mám pocit, že příliš minimalistický jazyk je sice mocný, ale ztrácí přehlednost a praktickou užitečnost."

"Ovládám ho, ale počet primitiv toho jazyka mi přijde už příliš malý na to, aby byl přehledný a udržovatelný rozsáhlejší kód."

Nechcem teraz nijako urazat a podobne, ale Vy podla toho co pisete naozaj lisp (common lisp trebars) nepoznate... a je dost zarazajuce s akou "drzostou" tu hovorite ze hej...

Ale nechte toho, nevím, tady na rootu se nějak spousta lidí řídí pravidlem, že co znám, musím bezmezně a fanaticky milovat a chválit do nebe. Že tím, že dokonale poznám LISP/Javu/cokoli jiného, tak to musím začít bezmezně milovat. Jistě uznáte, že tato úvaha je totální pitomost jak vrata.

Trosku prekrucate... vobec nehovorim ze to musite "bezmezně a fanaticky milovat a chválit do nebe". Ale povedal ste niekolko veci, ktore by clovek znaly lispu (aspon intermediate) nepovedal.

Ale celkom pekne na to idete, podsuniete nieco co tu nikto nehovori (aspon v tomto sub-vlakne), a potom to oznacite za "totální pitomost jak vrata". Vy by ste sa hodil do nasej Slovensej politiky ;)...

Ale inak vsetko v dobrom, nechcem Vas tu teraz napadat ani sa s Vami hadat... a o tych benchmarkoch ohladom C++ a Javy s Vami celkom suhlasim (ohladom c++ vobec nie, ale tak to chodi... :)

Existuju 3 stupne klamstva:
1. male
2. velke
3. benchmark

;)

Ad 1) Opravím Vás: Řekl jsem několik věcí, které by člověk milující LISP neřekl. Aby bylo jasno, já jsem nikde nenapsal, že LISP není mocný jazyk - je. Ale je vystavěn na celkem málo primitivech. Přestaňte mě obviňovat bez konkrétností - a mohlo by z Vás už nějak vyjít ven, kde jsem napsal chybu o LISPu. Tady bylo napsáno tolika pitomostí a lží třeba o C++, že jsem to ani nekomentoval. A to někteří třeba i vrdili, že v tom několik let programují.

Ad 2) Já odrážím konkrétní argumenty konkrétními argumenty a osobní nekonkrétní výhrady shrnutím toho, že jsou to pouze osobní záležitosti.

Ad 3) Já se taky nechci hádat, koneckonců to C/C++ je v této debatě silně off topic, a celé to vzniklo z toho, že autor článku lživě píše o větší rychlosti, než C/C++. Kdyby se autor držel tématu a nepsal takové lži o ostatních jazycích, žádné téma o C/C++ by se tu neojevilo. Jinak beru to, že LISP/Scheme je dobrý jazyk - už jsme tu napsal, že ho obdivuji a považuji za geniální svojí koncepcí. Ať už o LISPu/Scheme tvrdím cokoli, celkově na mě tato dvojice působí velmi kladně svými možnostmi a dalšími. Nicméně prakticky v něm psát už nechci - to je ale jen subjektivní moje volba, která nijak nesnižuje LISP/Scheme.

Každý benchmark je do jisté míry lež :-) S tím zase souhlasím já :-)

A preco je problem, v com je problem, ze je vystavany na malo primitivach, ked existuju lisp makra (tomuto zasa j avobec nerozumiem)? Preco sa v nom nedaju pisat velke projekty?

A on je to problém? A kde jsem tvrdil, že se v něm nedají napsat velké projekty? Samozřejmě, že dají. Jediné jsme co jsem kdy napsal je, že LISP/Scheme mají už příliš málo primitiv podle _mého subjektivního soudu_ (tedy nepíšu objektivní závěr, jen svůj pocit - a jasně tím dávám najevo, že to nepovažuji za nic jiného, než svou osobní preferenci, nikoli za pravdu) na to, aby v tom vznikaly tak dobře přehledné a udržovatelné programy, jak by bylo možné, kdyby měl jazyk primitiv více.

Co presne Vam chyba (chybalo), ked ste programovali v Lispe? Ake jazykove konstrukcie, aka paradigma? V com Vas obmedzoval pocet primitiv tohto jazyka? Co ste nevedeli prehladne a jednoducho napisat?

Je to opravdu problém Lispu, nebo problém lidí? Kdyby to byl (technický) problém Lispu, asi těžko by v něm vznikl celý fungující operační systém...

Obdivujem Vasu trpezlivost (sledujem uz dlhsie;)... ak by ste niekedy mali chut sa zapojit do CL projektu, dajte vediet... ;)

Což o to, chuť mám, teď jen najít čas. :-) A taky čas na studium, protože ten jazyk přeci jen svá zákoutí má. :-)

Takze ak by bol zaujem viete kde ma naist... (staci 3x vyslovit moje meno a "zajvym sa niekde na roote", ak cas dovoli;)

Na com momentalne pracujeme tu rozoberat nebudem... ale pre zaujimavost z nasej tvorby (toto konkretne iba jednoho z nas...)

http://common-lisp.net/project/patg/

Kazdy jazyk ma milion "zakouti", ale len v CL ich odhalovanie prinasa novu slobodu (vacsinou;) a nie nove obmedzenia - "glass barriers", ako vo vacsine inych jazykoch...

Ked nic ine tak pokracujte v osvete dalej, ma to zmysel, aj ked Vas zvacsa nechapu, ako som si vsimol... mozno sa najde v nejakej diskusii aspon jeden clovek, co pochopi a pozrie sa ze "o co to teda ide"... a aj keby pri CL neostal (co je dost pravdepodobne, nie kazdy ma na to hlavu:), mozno iny ostane...:)

Viditelne ztracite cas.
Hosi si mysli, ze jsou mistri sveta, ale v hlave to budou mit srovnane az po deseti letech, nekteri nikdy.
Ja to vidim na mladych - napr. webove prezentace. Nektere znam nebo jejich praci. Nauci se (tedy opisou a upravi cizi fragmenty) napr. delat v PHP a MySQL a uz se citi jako programatori. Me programovani bavi, ale mrzi me, ze jsem pet let pozadu.

Praveze problem Cecka je ten, ze assembler dost dobre nenahrazuje, zejmena na architekture CISC. Pokud se pise assembler napriklad pro MIPS (nebo drive na M68k), je to parada, v podstate je to takove jednodussi cecko - dokonce i se skoky, makry atd. Ale CISC architektury, zejmena ty s flagy (Carry, Zero, Overflow...) uz maji assembler od dost slozitejsi nez to, co by slo napsat v cecku, takze ve vysledku je nekdy nutne cecko s assemblerem kombinovat (prace na urovni jednotlivych bitu napr. cecko vlastne vubec neresi, pokud nepocitam problematicky implementovana bitova pole).

Jinak co se rychlosti tyka, v podstate s tim lze souhlasit. V nekterych ulohach sice C/C++ pokulhava za Fortranem, vetsinou je rychlejsi implementace v C++, ale ty rozdily se postupne zmensuji - treba i diky tomu, ze backendy prekladacu tech jazyku jsou dost podobne.

Jen poznamka k rychlosti jazyku:
1) hodne zalezi na konkretni uloze
2) hodne zalezi na na efektivite napsaneho programu
3) hodne zalezi na pouzitych knihovnach

---

Obecne se daji jazyky rozdelit do 3 skupin a uvadim jen vyhody nevyhody tykajici se performance:

kompilovane na stroji vyvojare:
+ rychly start u uzivatele
- nutne mit stejny kod s podporou MMX/SSE/AV i bez ni (pokud compiler vubec doda jejich podporu)
- velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss

bezici ve VM - JIT (mluvim o Jave, o ktere toho vim nejvic, ale bude platit i +/- pro ostatni):
+ optimalizace na velikost cache
+ vyuziti vsech instrukci procesoru dostupnych v dobe tvorby VM
+ alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss
- nutnost nacteni VM pred programem => pomaly start
- garbage collection

interpretovane:
- nemaji zadnou performance vyhodu (aspon si nemuzu zadnou uvedomit)

---

zpet k performance prvnich 2 reseni:
1) aritmeticke operace jsou prakticky stejne rychle (logicky, protoze vysledny kod JIT i bezneho compileru je prakticky stejny)
2) cena cache miss je obrovska (2-4 cykly pri pristupu do cache vs. stovky-tisice cyklu pri pristupu do RAM)
3) velke mnozstvi vytvarenych objektu (treba v iteraci) neprospiva Java a spol. kvuli GC
4) systemy s GC maji obecne vetsi spotrebu pameti
5) JVM je prozatim dost neoptimalni, jen JDK 6 prinesla zrychleni cca. 20% a chybi podpora alokace objektu na stacku (ktera by mela pomoct s bodem 3)
6) casto se pri testech srovnavaji nesrovnatelne veci: srovnavani 8-bit stringu v C versus. srovnavani 16-bit Unicode retezcu s ohledem na lokalizaci v Jave (jan aby byl clovek obezretny)
7) dnesni JIT pouzivaji hodne agresivni strategie na optimalizaci - dynamicky inlining/deinlining apod.
8) pokud udelate test v jehoz prubehu se bude nacitat nova trida (napriklad poprve pouzijete tridu MyVector az uvnitr mereneho useku), tak v JIT do testu zapocitate i nacitani teto tridy, ktera se ale realne nacita jen 1x za cely zivot programu a tutiz neni pro vykon smerodatna

Snazil jsem se udelat fakt jenom hodne rychly prulet vecma k zamysleni a rozhodne se nejedna o nic uplneho, tak prosim nekamenovat. Nemam rad kecy typu X je rychlejsi nez Y, protoze to nic nerika o podminkach a konkretnim ukolu. Navic +- 10% vykonu je dnes absolutne irelevantni zalezitost. Daleko markantnejsi dopady maji pouzite algoritmy nez to jestli se jedna o C-family/Java/Python.

Zbyva dodat, ze JIT zatim ceka jeste dlouha evoluce (v podstate je jeste na zacatku), zatimco klasicke compilery uz jsou dlouhodobe doladovane k maximalnimu vykonu a uz narazi na hranici svych moznosti.

Dobre je si o tom neco precist (doporucuju Google), rychle jsem nasel jen tohle: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Z tohoto komentáře mám pocit, že jeho autor má o běhu programu na nižší úrovni jen velmi mlhavé a nedostatečné vědomosti. Některé poznámky mi připadají naprosto "mimo":

"nutne mit stejny kod s podporou MMX/SSE/AV i bez ni (pokud compiler vubec doda jejich podporu)" - co je tím přesně myšleno? Jaký stejný kód, stejný kde?
"velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss" - prosím??? Co tím myslíte přesně?
"alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss" - cože???
"optimalizace na velikost cache" - jaké cache?

V podstatě vůbec nevím, co chcete říct a o čem to vlastně mluvíte a to se programováním - jak v Assembleru, tak v C - zabývám skoro 20 let. A mám takový pocit, že to není mou neznalostí, ale tím, že to co tvrdíte nemá ani hlavu, ani patu - asi jako když v béčkovém sci-fi se snaží někdo působit rádoby odborně.

"vyuziti vsech instrukci procesoru dostupnych v dobe tvorby VM" - to samo o sobě naprosto o ničem nevypovídá. Výkon programu v daném případě stojí a padá s bytekódem a je celkem lhostejné, jak je tento kód interpretován VM. Speciální instrukce už nemohou vůbec nic zachránit.

"cena cache miss je obrovska (2-4 cykly pri pristupu do cache vs. stovky-tisice cyklu pri pristupu do RAM)" - to obecně vůbec neplatí - omezujete se na jednu architekturu a ani na té to obecně není pravda.

"nesni JIT pouzivaji hodne agresivni strategie na optimalizaci - dynamicky inlining/deinlining apod." - co je na tom jako agresívního? To je ta nejprimitivnější optimalizace a často je sporné, jde-li vůbec o optimalizaci nebo naopak.

"Navic +- 10% vykonu je dnes absolutne irelevantni zalezitost" - pokud je myšlen celý program, tak budiž. Pokud by se to týkalo nějakého vnitřního podprogramu, tak i těch 10% je moc.

prectete si prispevek, na ktery jsem dal na konci link a odkazy, na ktere se odkazuje ... je tam pomerne dobre popsany rozdil mezi JIT a zkompilovanym kodem a nema cenu, abych to prerikaval ... nemam silu odpovidat na otazky, ktere vysvetluji co je to cache procesoru, co je cache miss apod.

jeden citat za vsechny: "Výkon programu v daném případě stojí a padá s bytekódem a je celkem lhostejné, jak je tento kód interpretován VM" ... v JIT neni nic interpretovano, vse je kompilovano Just-In-Time do strojovych instrukci pri class loadingu => zde se byte-code nahrazuje nativnimi instrukcemi procesoru (vcetne SSE/AV) a zalezi ja implementaci JIT jak moc jich vyuzije

Přihřeju polívčičku panu Ponkrácovi a zarejpu si: "1) Pointers make optimization hard" je pitomost, protože to je již osm let vyřešený problém. Aliasing nikdo neignoroval, při psaní pořádného kódu se s ním musí počítat (resp. musí se počítat s tím, že se mu musí zabránit), a není to až takový problém. :-) GC lze používat i v C a C++, pravda, s jistými omezeními (precizní GC e-e), ale libGC tu je celé věky. Program, který tráví 25-30 % v malloc() a free() by spíš zasloužil popravu autora, na jemně granulární práci s paměti tyhle funkce fakt nebudou (zvášť v příchutích glibc a msvcrt) a obecně se to ví. A pokud JITované programy jsou rychlejší než předkompilované, tak kompilátor odvedl špatnou práci. ;-) Z principu totiž není omezeno, co může před dodáním programu uživateli provést. Čehož využívá třeba právě Stalin ;-), ale i MLton a další.

Chtel bych videt, jak se teda v C poprali s pointerem, ktery se muze toulat, kde se mu zlibi.

"A pokud JITované programy jsou rychlejší než předkompilované, tak kompilátor odvedl špatnou práci." ... neni pravda, JIT ma navic informaci, ktere kompilator na pocitaci u vyvojare mit nemuze - kompletni popis hw, na kterem bezi

vidite to treba uz na tom, ze program v bytecode nemusite kompilovat pro kazdu platformu zvlast - az JIT vi, na jake instrukce ma byte-code prevest
napriklad: program v C pro Intel spusteny na PowerPC - cas dokonceni: nikdy, kdezto program pro JIT pobezi v pohode (pokud pro PowerPC je dana VM)

rekl bych ze podobne (samozrejme s mene drastickymi nasledky) je to v ramci jedne architektury ... napriklad program v C byste musel kompilovat do nekolika variant s/bez podbory pro SSE1-4/MMX/x64/AltiVec, nebo tam udelat rozhodovaci logiku, ktera si vybere vetev s instrukcemi podporovanymi procesorem ... nemyslim, ze je to idelani pristup (i kdyz to udela kompilator automaticky) ... navic prichod novych instrukci znamena rekompilaci toho programu v C jeho vyrobcem (pokud nemate tu moznost sam), kdezto u JIT staci nova VM a vsechny programy hned hezky bezi s podporou vseho noveho

nerikam, ze soucasne VM vyuzivaji vsech moznosti jak optimalizovat kod ... ocividne jsou teprve na zacatku a podle me je v nich jeste hodne potencialu ... vzdy tam bude rezie pri spusteni programu, ale jaky je cas spousteni a nasledneho pouzivani programu?

Chtel bych videt, jak se teda v C poprali s pointerem, ktery se muze toulat, kde se mu zlibi.

Zavedli pointery, které se nemohou toulat, kde se jim zlíbí. :-)

hezka odpoved :) ... dekuju

jde videt, ze si autori restrict byli narozdil od nekterych zdejsich diskutujicich vedomi tohoto performance problemu C ... dva problemy (kdyz opomenu ostatni vyhrady, ktere proti C mam) vidim v tom:

1) tenhle pristup vyzaduje "prepsani"+rekompilaci stavajicich aplikaci
2) je dalsi vec, nad kterou musi programator premyslet

... ale C uz od zakladu zmenit nejde, to uz by nebylo C ... ironii, je ze kdyz jsem zacinal v C++, tak jsem pointery videl jako velice elegantni a dobre reseni :)

vidite to treba uz na tom, ze program v bytecode nemusite kompilovat pro kazdu platformu zvlast - az JIT vi, na jake instrukce ma byte-code prevest napriklad: program v C pro Intel spusteny na PowerPC - cas dokonceni: nikdy, kdezto program pro JIT pobezi v pohode (pokud pro PowerPC je dana VM)

rekl bych ze podobne (samozrejme s mene drastickymi nasledky) je to v ramci jedne architektury ... napriklad program v C byste musel kompilovat do nekolika variant s/bez podbory pro SSE1-4/MMX/x64/AltiVec, nebo tam udelat rozhodovaci logiku, ktera si vybere vetev s instrukcemi podporovanymi procesorem ... nemyslim, ze je to idelani pristup (i kdyz to udela kompilator automaticky) ... navic prichod novych instrukci znamena rekompilaci toho programu v C jeho vyrobcem (pokud nemate tu moznost sam), kdezto u JIT staci nova VM a vsechny programy hned hezky bezi s podporou vseho noveho

To je sice všechno moc pěkný, ale víte, jak dlouho trvá běh kvalitního kompilátoru? Na ten bych si tedy po spuštění JITu počkal pěkně dlouho. Tím nechci říct, že výkon JVM nemůže být přijatelný, obzvlášť na serverech. Na klientech to ale bude mírně horší, a co hůř, u většího kusu SW typu OpenOffice, IDE a podobně opravdu nebudu chtít, aby se až po jejím spuštění u mně začal VM rozhlížet, co s tím molochem jako provede. Použití Javy na desktopových aplikacích je ospravedlnitelé možná tam, kde aplikaci používá maximálně pár desítek nebo stovek lidí. Jinak bych ale trpěl výčitkami z toho, že jednu a tutéž věc, kterou bych mohl provést jeden stroj jednou, dělají tisíce strojů...a znovu a znovu při každém spuštění. A nemotejte do toho "specializované instrukce", tím javisté straší před spaním své C++ děti. Takové věci jako flow analysis a profile-based inlining (ale i další) jsou naprosto nezávislé na ISA, a trvají mnohem déle než rozhodnutí, co použiju za instrukce (a to i v případě, že to ovlivní věší část kompilace, protože to rozhodnutí je samo o sobě velmi krátké - mám, použiju, nemám, nepoužiju - když se provede dřív, prostě se bude provádět jiná větev kompilačního řetězce, ale trvat bude s velkou pravděpodobností stejně, ostatně Java stejně nevektorizuje, IIRC). Používat Javu je velmi neekologické. Java causes global warming! Hug a tree, use C++! ;-)

Ono by slo vyhody JIT kompileru a tradicni kompilace spojit. Vse, co lze udelat v compile-time, by se udelalo v compile-time a kod by se prelozil do nejakeho mezikodu, ktery by obsahoval i informace ze staticke analyzy. JIT compiler by pak uz jen doladil detaily. Pro tohle by se ale chtelo vzdat portabilniho bytecode, aby se format mezikodu mohl vyvijet, kdyz by spolu s obema kompilatory.

1) Preklad do byte-code je kompilace, pri ktere se uz neco dela? Prvni stupen optimalizace je zde. Ale zde toho jeste prilis udelat nejde, protoze jeste vse zustava platformne nezavisle.

2) Vsechny tridy v java.* package se cachuji zkompilovane, jakmile se jakykoliv program v Jave poprve spusti (novinka v 1.5) a jakykoliv dalsi program uz nekompiluje znovu pokud se nezmeni procesor, neupdatuje java apod.

3) Ten dynamicky inlining/deinling ve VM apod. co jsem tu zminoval a nekdo se mi smal, ze to existuje davno, prave umoznuje iteracni kompilaci kodu - nejdriv zkompilujete rychle, kdyz se kod casto pouziva udela se to znovu. Aplikace rychle nabehne a kdyz bezi dele vykon se zvedne.

4) Specializovane instrukce opravdu hodne pomahaji pri specifickych ukolech i v Jave. Jejich vykon se diametralne lisi od beznych. neni to strasak ale fakt.

5) To, ze se kompiluje na kazdem stroji znovu je dan za cross-platformost ... kdyz uzivatel Java aplikace bude prechazet z Win/Intel na Linux/PPC aspon nebude muset brecet, ze mu tam ta aplikace nejede

6) Jinak obecne s principem proc delat veci pokazde, kdyz je muzete udelat jednou souhlasim:
- proc muset testovat pri kazdem pristupu v C do pameti jestli neni pointer mimo vyhrazenou pamet? (kdyz Java tohle zajistuje uz na urovni jazyka)
- proc prepinat mezi uzivatelskym a privilegovanym rezimem? (kdyz budete mit bezpecnost na urovni jazyka)
- proc pri kazde instrukci delat predikci vetveni v kodu, resit out-of-oreder vykonavani instrukci, resit forwarding, resit jak musite pozastavit pipeline? (kdyz vsechny tyhle informace muze vyrobit JIT jednou pri kompilaci pri nacteni tridy)
- proc resit preemtivni multitasking a to jestli proces prepnete v idealni chvili? (kdyz vam JIT bude schopen tahle mista najit pri kompilaci a pridat instrukce na vzdani se procesoroveho casu a preemtivni reseni bude pouzivat jen jako doplnek)

... no a tyhle otazky si polozili i jini a proto treba existuji prototypy OS, ktere uz nepouzivaji C ... JNode, JX, Singularity apod.

PS: velka cast spotreby (ekologie) procesoru pripada prave na optimalizaci kodu za behu, protoze non-JIT kompilator neni schopen dodat optimalni kod pro dany procesor ... napriklad Itanium hodne sazelo na JIT a cela architektura je postavena na tom, ze procesor opravdu pocita a neresi optimalizaci ... bohuzel soucasne OS a spousta utilit toho potencialu nedokazi vyuzit

1) Preklad do byte-code je kompilace, pri ktere se uz neco dela? Prvni stupen optimalizace je zde. Ale zde toho jeste prilis udelat nejde, protoze jeste vse zustava platformne nezavisle.

Překlad do bytecode je v případě Javy naprosto triviální. Tam nejde nic "optimalizovat".

2) Vsechny tridy v java.* package se cachuji zkompilovane, jakmile se jakykoliv program v Jave poprve spusti (novinka v 1.5) a jakykoliv dalsi program uz nekompiluje znovu pokud se nezmeni procesor, neupdatuje java apod.

Mohu vědět, kde? Ono to není tak triviální, dynamicky zrekompilované třídy už z principu jsou dost špatně recyklovatelné. Hromada informací při generování takového kódu vyletí komínem. Mně osobně to trošku připomnělo arabská písmena, která závisejí na kontextu - když jedno vytrhnu, napasovat ho můžu v podstatě jen mezi stejná písmenka jinde. Smysl by mělo dumpnout celý kód jednoho procesu, ale ani to by nebylo extra praktické. Zvlášť v případe agresivního inliningu (o jehož užitečnosti bych i vedl spory, stačí se podívat na forthovské procesory) může být docela problematické zrecyklovat rt.jar třídy z jedné aplikace v aplikaci druhé.

3) Ten dynamicky inlining/deinling ve VM apod. co jsem tu zminoval a nekdo se mi smal, ze to existuje davno, prave umoznuje iteracni kompilaci kodu - nejdriv zkompilujete rychle, kdyz se kod casto pouziva udela se to znovu. Aplikace rychle nabehne a kdyz bezi dele vykon se zvedne.

Totéž umí profile-based kompilace jazyků typu ML a třeba i to C++. Až na to, že se ta aplikace spustí téměř optimální hned po načtení z disku. Pokud bych mohl z JITu něco vytěžit, tak nejspíš jen u hodně dlouho běžící serverové aplikace za značně se měnících podmínek (oproti prvotní profilaci), a ještě je otázka, jak velký ten marginální nárůst výkonu bude. Abych to řekl jinak: Microsoft .NET nepoužívá JIT - nebo přinejmenším po spuštění aplikace se už kód nemění, tj. nepoužívá rekompilaci. A přesto je výkon víceméně srovnatelný - někde lepší, někde horší... Na Javě se projevuje, že do ní byly napumpované desítky a stovky miliónů dolarů, takže pokud má velice dobrý serverový výkon, tak to bude tím R&D, mnohem spíš, než tím, že R&D vyprodukovalo ausgerechnet HotSpot.

4) Specializovane instrukce opravdu hodne pomahaji pri specifickych ukolech i v Jave. Jejich vykon se diametralne lisi od beznych. neni to strasak ale fakt.

Já vím, že to je fakt. Ale ten kód někdo musí napsat, a JVM to nebude. :-) Specializované instrukce bohužel vyžadují ponořit se do assembleru nebo intrinzik, nebo na daný úkol napsat knihovnu (ale ručně). To druhé funguje i v Javě, to první v Javě nejde a součaný JIT kompilátor Javy to prostě neumí. To není strašák, ale fakt. ;-) Specializované instrukce jsou velice dobrý důvod, proč se naučit aspoň trošku assembler. Třeba tu manhattanskou metriku přes PSADBW si budu muset napsat sám, vygeneruje ji za mě JIT z for cyklu? ;-)

5) To, ze se kompiluje na kazdem stroji znovu je dan za cross-platformost ... kdyz uzivatel Java aplikace bude prechazet z Win/Intel na Linux/PPC aspon nebude muset brecet, ze mu tam ta aplikace nejede

Ehm...to je spíš problém dodavatele. Znám spoustu těžce nahraditelných javovských aplikací, které jinde než na Windows nepoběží, přestože jsou psány v Javě. Ba co víc - třeba MultiTerm Extract funguje nejen pouze na Windows, ale pouze s jednou konkrétní verzí JVM, a nemůžu mít v systému nic jiného. To já už radši aplikaci v C++, která nebude blokovat ostatní svými požadavky na runtime. Samozřejmě, Java může investice potřebné k zajištění přenositelnosti snížit, ale obávám se, že se tenhle aspekt poněkdu přeceňuje. C++ například úspěšně běhá na mnohem více platformách než HotSpot.

6) Jinak obecne s principem proc delat veci pokazde, kdyz je muzete udelat jednou souhlasim: - proc muset testovat pri kazdem pristupu v C do pameti jestli neni pointer mimo vyhrazenou pamet? (kdyz Java tohle zajistuje uz na urovni jazyka)

Jistě, proto se to při každém přístupu netestuje ani v C. ;-) Tohle mě má překvapit?

- proc prepinat mezi uzivatelskym a privilegovanym rezimem? (kdyz budete mit bezpecnost na urovni jazyka)

Co to je tady "bezpečnost"? Stahování kódu z webových stránek ponechme stranou, Vy si vážně myslíte, že musím chránit počítač před aplikacemi, které si sám nainstaluji? (Digitálně podepsanými mými kolegy?) SW bariéru jsem schopen zajistit kdekoliv.

- proc pri kazde instrukci delat predikci vetveni v kodu, resit out-of-oreder vykonavani instrukci, resit forwarding, resit jak musite pozastavit pipeline? (kdyz vsechny tyhle informace muze vyrobit JIT jednou pri kompilaci pri nacteni tridy)

Nechci Vám brát iluze, ale tohle za nás na většině architektur řeší procesor, a tam, kde to neřeší procesor, tam to vygeneruje kompilátor sám, a je úplně jedno, jestli před spuštěním aplikace nebo po něm.

- proc resit preemtivni multitasking a to jestli proces prepnete v idealni chvili? (kdyz vam JIT bude schopen tahle mista najit pri kompilaci a pridat instrukce na vzdani se procesoroveho casu a preemtivni reseni bude pouzivat jen jako doplnek)

Proč tohle nemůže řešit AOT kompilátor?

... no a tyhle otazky si polozili i jini a proto treba existuji prototypy OS, ktere uz nepouzivaji C ... JNode, JX, Singularity apod.

Díky, já radši House OS. ;-) Tenhle koncept je fajn, ale přinásí základní problém - restrikci jazyka. Zeptejte se na tohle profesora Tanenbauma, co vám na to řekne. ;-) Pokud mi budete argumentovat abstraktním bezpečným mezikódem, pak Vás musím informovat: Žádný univerzální neexistuje. Alespoň ne takový, který by byl použitelný pro všechny jazyky, a já chci počítač jako univerzální nástroj, ne jako javovský telefon na kterém běhá jen Java. Hardwarová kontrola je neinvazivní a v podstatě bezproblémová.

PS: velka cast spotreby (ekologie) procesoru pripada prave na optimalizaci kodu za behu, protoze non-JIT kompilator neni schopen dodat optimalni kod pro dany procesor ...

Non-JIT kompilátor sice nemá všechny informace, které může mít JIT, ale vynášet tak silné tvrzení, že marginální výhoda JITu přebije AOT kompilaci natolik, že má smysl ji podstupovat znovu a znovu, to je opravdu odvážné. Chápu výhody JITu například u Smalltalku, to je systém, u kterého AOT nepřipadá v úvahu, ale Java není Smalltalk, ta je dynamická asi tak, jako pyramida na tekutých píscích.

napriklad Itanium hodne sazelo na JIT a cela architektura je postavena na tom, ze procesor opravdu pocita a neresi optimalizaci ... bohuzel soucasne OS a spousta utilit toho potencialu nedokazi vyuzit

Ne, Itanium sázelo na VLIW. To je velmi starý koncept, který s JIT opravdu nemá nic společného, bohužel.

1) neni pravda, ze se neda udelat nic, ale dela se lemi malo (sam jsem to psal)

2) nevim kde si je uklada, ale vzhledem k tomu, ze i za behu obsahuje Java informace dulezite pro inlining/deinlining neni problem i takhle zkompilovanou tridu znovu zmenit ... mozna jste prehledl, ze jen zkompilovane tridy z java.* package se ukladaji zkompilovane ... je to z hlediska principu, protoze tridy v tehle package muze zavest jen sama JVM (mimo jine kvuli bezpecnosti), ostatni tridy muze zavadet i vlastni kod vyvojare - tutiz Java neni schopna rict, jestli se trida neaktualizovala, a nevi jestli muze pouzit zkompilovanou verzi

3) chtel bych videt dynamicky inlining/deinlining v C++ ... kdy se napriklad pri nacteni nove tridy zjisti, ze je to potomek tridy jejiz metody jsou nekde inlinovane a vsude kde je tahle metoda inlinovana se musi vyextrahovat a nahradit jinym kodem podporujicim i novou tridu ... v C++ je proste jen staticky inlining

4) ad generovani specialnich instrukci: do toho na jake instrukce prevati co, ktera implementace JVM ... je jich hodne a ja do nich nevidim ... ale principialne neni problem

5) zalezi na dodavateli - najdou se bile i cerne ovce ... vyhoda je, ze pokud v jave neni vazba na nativni kod (C/C++), a nepouzivaji se knihovny sunu v JVM (jako ze je to krajne nedoporucene a kazde IDE vas na to upozorni), tak je vse bez problemu ... C/C++ vyzaduje nekdy znacnou snahu vyvojare navic, aby byl program na vice platforem ... to, ze C++ bezi vsude je sice hezke, ale jde o to, aby programy bezely vsude

6)
testovani: OS musi testovat, zda se nenachazite mimo vyhrazenou pamet - jinak riskujete stack-overflow bezpecnostni chyby

prepinani rezimu: myslim prepinani na urovni procesoru, kdy se prepina na moznost delat privilegovane operace (naprikald alokace pamesi), ktere muze delat jen OS ... tohle je _extremne_ draha operace a probiha relativne casto ... vy si to pletete s nejakym prepinanim mezi rootem/uzivatelem

preemtivni multitasking: protoze u programu zkompilovanym JIT (bezicim na vasem pocitaci) muzete verit, ze se toho casu program vzda ... u programu dodaneho treti stranou nemuzete spolehat na to, ze tam takove body jsou nachystane

ad jen java OS: muze na takovem zarizeni jet jakykoliv jazyk, ktery se da prelozit do bytecode (dnes jsou to python, ruby, groovy, ...) ... byte-code je turing-complete, takze v tom napisete opravdu co budete chtit ... vyhoda je, ze ale nemuzete provest zadnou operaci, ktera by narusila chod systemu, zasahovala mimo svou pamet apod. ... silne doporucuju si o language-level-security systemech aspon neco precist, nez o tom clovek zacne mluvit

optimalizace kodu za behu: rozdil je opravdu podstatny, JIT ma mnoho informaci o usporadani pipeline procesoru:
- vi jak poskladat instrukce za sebe, tak aby je procesor nemusel prehazovat
- vi jak dlouho bude cekat na vyslednou hodnotu nejake instukce, takze mezi ni a instrukci, ktera hodnotu pouziva uz muze sam vlozit neco dalsiho
- neni potreba, aby procesor uchovaval tabulku skoku, prtoze JIT vi kam se bude s nejvetsi pravdepodobnosti skakat
- ...

ad hw controla: neinvazivni, bezproblemova ... ale neodchyti vse a vzdycky (viz stack-overflow), je pomala (dela se porad a znovu), zvysuje komplexitu procesoru a zere cca 1/4 - 1/3 celkove spotreby procesoru u modernich modelu ... asm, C/C++/C# apod. jsou jazyky, ktere vyzaduji slozitejsi architekturu procesoru

ad Itanium: tak to o Itaniu skoro nic nevite, ano mimo jine pouziva i VLIW, ale to je jen jedna z novych features

"velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss" - prosím??? Co tím myslíte přesně? "alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss" - cože??? "optimalizace na velikost cache" - jaké cache?

Mám pocit, že možná mluví o alignmentu dat vůči cache lines, ale to je problematika poněkud složitější, než aby se daly dělat takovéhle paušální soudy. Kromě toho, mám pocit, že statisticky (přístupy) horký je hlavně zásobník a v GC-supported runtimech také nursery/eden/nultá generace (každý tomu říká jinak :-)), ale tam je to kompaktní už z principu. Přijde mi, že obecném případě tyhle věci téměř némá smysl řešit, protože determinismus tady jde do kytek.

"nesni JIT pouzivaji hodne agresivni strategie na optimalizaci - dynamicky inlining/deinlining apod." - co je na tom jako agresívního? To je ta nejprimitivnější optimalizace a často je sporné, jde-li vůbec o optimalizaci nebo naopak.

To bylo asi agresivní v dobách Selfu 93. ;-) Dneska by to už člověk celkem čekal.

"To bylo asi agresivní v dobách Selfu 93. ;-) Dneska by to už člověk celkem čekal." ... srovnani je mezi JIT (jakehokoliv jazyka) se statickou kompilaci ... JVM ma jeste spoustu vykonostnich rezerv, o kterych se vi, takze nepochybuju, ze self muze mit odladenejsi VM

> "Navic +- 10% vykonu je dnes absolutne irelevantni zalezitost" - pokud je myšlen celý program, tak budiž. Pokud by se to týkalo nějakého vnitřního podprogramu, tak i těch 10% je moc.

To je docela divne tvrzeni. Pokud bydes mit 10% spomaleni klicove vnitrni smycky v nejakem podprogramu, tak to za normalnich okolnosti nezpomali cely program o vice nez 10%. Pokud tedy tolerujes zpomaleni celeho programu o 10%, tak klidne muzes tolerovat zpomaleni vyznamnych programu o 10%

jak jsem psal ... zalezi vic na pouzitych algoritmech nez na jazyce ... jestlize mate 10% vyhodu diky jazyku a implementacne jej 3x zpomalite, tak vam nepomuze sebelepsi jazyk ... je to myslene v tomhle kontextu

rychlost C/C++ vs. Java se lisi test od testu a neni jasny vitez na vsechno

> kompilovane na stroji vyvojare:
> - velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss
>
> bezici ve VM - JIT (mluvim o Jave, o ktere toho vim nejvic, ale bude platit i +/- pro ostatni):
> + alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss

Tohle vicemene nesouvisi s tim, zda je jazyk klasicky kompilovany, JIT kompilovany ci interpretovany, ale s tim, zda a jaky ma garbage collector (a obecne spravu pameti). Neni problem mit klasicky kompilovany jazyk, ktery ma haldu kompaktujici garbage collector.

Nicmene i tak pochybuji, ze by kompaktni alokace mela vyznamny vliv.

doporucuju si precist clanek, na ktery jsem dal odkaz a z nej vedouci reference ... je to tam vysvetleno podrobneji a nema smysl to opakovat

ale obecne ma zasadni vliv jestli mate 3 objekty v jednom bloku cache (jedno cteni z RAM + placnu 1kB spotreba cache) ... 3 objekty ve 3 blocich cache (3 cteni z RAM + 3kB spotreba cache + spousta hlusiny v cache nesouvisejici s behem programu) ... cisla se samozrejme lisi platforma od platformy ... velikost bloku, zpozdeni pameti

Prave moze (zavisi co sa mysli "vyznamny"). Viz napr.: Vertical profiling: understanding the behavior of object-priented applications, http://www-plan.cs.colorado.edu/diwan/vertical-prof-oopsla.pdf

Je to o nastroji, ktory zistuje, kde presne nastava zadrhel (na rozlicnych urovniach od JVM, kernelu, garbage collectoru atd)

Ano, to je pravda ... trochu jsem zde promichal 2 veci

je to spis srovnani alokace pomoci malloc, ktera si zada po systemu pamet a dostane ji na "nahodne" pozici, ktera vubec neodpovida potrebam lokality dat s alokaci na halde typickou pro Javu

samozrejme muzete mit v C impelmentovanou stejnou funkcionalitu rucne

To, ze z pohledu virtualniho stroje je halda souvisla, nemusi vubec znamenat, ze je souvisla fyzicky, tj. z pohledu cache. Klidne muze byt silene fragmentovana, ale MMU v CPU to pred virtualnim strojem schova. Tazke ono to s tou lokalitou zas neni tak horke, jak to vypada. spse jde o to, ze data, ktera jsou potreba zaroven, budou pokud mozno blizko sebe (tj. napr. v jedne strance pameti), aby se zbytecne nezaplacaval cache a aby se nemusely neustale dotahovat polozky pro TBL.

A je pravda, ze v C se tohle da udelat take, sam jsem parkrat pouzil. Staci jen vsechny male veci alokovat na zasobniku (pres alloca(), ale pozor na podteceni/preteceni) a vsechny velke veci delat pres mmap() (tedy, alespon v Linuxu, *BSD a podobnych unixech).

Halda se uplne obejde, free() neni treba (mimo funkci, co sami o sobe alokuji pamet), protoze zasobnik je uvolnen automaticky po ukoncieni prislusne funkce a na mapovne oblasti je munmap(). U nammap()ovanych oblasti mate navic prehled zajisteny samotnym systemem (viz napr. /proc/<PID>/maps v Linuxu), takze v pripade potreby neni problem je zkontrolovat a v pripade nouze ty nepotrebne uvolnit.

Ani v jednom pripade nedochazi k fragmentaci, alespon te logicke (te fyzicke, jak uz jsem rekl, se ze strany aplikaci vyhnout neda, to musi delat system). A pokud se vam nechce delat mmap()ovani rucne, tak minimalne v glibc jde malloc() donutit k tomu, aby pouzival mmap() misto sbrk() i male kusy pameti.

ano, to jak je halda souvisla zalezi na tom jak ji JVM a system pod ni alokuje ... ale JVM o pamet zada ve velkych blocich (radu MB - jde nastavit) a sama si pamet uvnitr spravuje ... je predpoklad, ze OS pri jednorazove alokaci JVM poskytne souvislou pamet

ad zbytek: proc to delat rucne, kdyz to JVM za me udela automaticky a spolehliveji a ja nemusim premyslet nad tim, kde a jak pamet alokovat?

Ospravedlnujem sa trochu off-topic ale velka cast fora sa aj tak zaobera niecim inym. Pan Ponkrac je tazky super ohladom C++ vs Java napriek tomu si dovolim tvrdit ze beh velkych programov bude v Jave rychlejsi. Dolezite su nasledovne veci:
1. Kniznice/Frameworky
2. Multithreading
3. Object locking (Semafor vs. instruction lock)
4. Asynchronne operacie s OS (Sietovy interface, File, ...)
5. Platform/Processor specific optimization
6. Memory management

A prave to ze napisat skutocne optimalny program v komplikovanych nestalych podmienkach je narocne a asi aj nemozne pretoze vzdy je balance medzi univerzalny pronositelny kod vs. platformovy rychly.
Nakolko som ale dlhe roky pracoval aj s C/C++ tak je iste ze rovnaky Java program sa da prepisat do optimalnejsieho C/C++. Otazka ale znie kolko ludi to zvladne. S dobrym frameworkom aj priemerny Java programator napise kod priblizne rovnako rychly ako spickovy specialista na C/C++.

Souhlas. Nutno dodat, ze ten program v Jave zpravidla clovek napise rychleji a spolehliveji. Zatimco v C++ clovek lovi memory-leaky, aplikace v Jave uz muze davno bezet.

Mam dlouhou zkusenost s C++ a je to jazyk, na kterem jsem zacinal. Ale Java umoznuje, abych se soustredil na to, co je pro me podstatnejsi nez delat to co za me muze udelat stroj. Mozna je to tim, ze jsem spatny C++ programator, ale s timhle statutem jsem ochoten se smirit :)

ad 1. - Jaký to má podle vás vliv na rychlost? Podle mne tato věc rychlost nijak zvýšit nemůže.
ad 2. - Proč by měl mít multithreading nějaký vliv na rychlost? Navíc opět - to je věc vlastní i C++. Nevhodně udělaný multithreading bude naopak zpomalovat.
ad 3. - Souvisí s předchozím a opět nevidím nic, co by mělo mluvit ve prospěch Javy.
ad 4. - To je záležitost OS a ne programovacího jazyka - leda že by ta javovská mašinérie obalila kolem toho, co nabízi OS, ještě nějaký svůj zpomalující balast.
ad 5. - Naprostý nesmysl. Bytekód je všude stejný a jediná možná optimalizace je tedy na úrovni interpretace bytekódu. Kompilované C++ může optimalizovat "přímo" algoritmus na míru procesoru, to tedy Java z principu nemůže - takže v tomto bodě vlastně ukazujete, že v těchto otázkách musí být Java zákonitě vždy pomalejší.
ad 6. - Zákonitě pomalejší, než v C++, a to kvůli GC.

"dobrym frameworkom aj priemerny Java programator napise kod priblizne rovnako rychly ako spickovy specialista na C/C++" - Na to se dá říci jen jedno - ROFL! Takového průměrného javistu vs. takového specialistu na C++, kde by to takhle platilo, bych chtěl vidět. Špičkový javista je rád, když jeho výtvor není o mnoho pomalejší, než výtvor průměrného C++kaře.

1) Pomaly framework bude brzdit Vas program alebo si ho zase napisete sam. To ale je dovod preco je C++ tam kde je. Mala reusabilita (v porovnani s Javou).
2 a 3) Lebo multithreading a lockovanie je dost komplikovane. V Jave su rovno triedy na execution queues reentrant locks, read/write locks. Napisat ich vyzaduje hlbkovu znalost ale pouzivat ich uz moze kazdy bez znalosti ako to funguje (a funguje to optimalne).
4) Ciastocne ano ale ak napr. bezim na specifickej platforme ktora umoznuje niektore veci robit rychlejsie tak Java my ich moze prelozit pre kazdu platformu inac. Ak to dame dohromady s multithreadingom tak mozme dojst do zaujimavych performace rozdielov.
5) Java uz davno neinterpretuje ale preklada do nativneho kodu. Na danej platforme to potom moze prelozit optimalnejsie ako univerzalny C program.
6) Nemusi byt. Paralel garbage collector to moze robit skoro az neviditelne.

2), 3) Takovým věcem je nejlepší se rovnou vyhnout. ;-) Erlangisté tak učinili a udělali IMHO opravdu dobře.

5) Jak jsem se ohradil proti Biktopovi, tak se musím ohradit i proti Vám. :-) Neexistuje žádný racionální důvod si myslet, že by JIT kompilace dosáhla vyššího výkonu než staticky zkompilovaný kód jindy než v opravdu extrémních případech (server, co nikdy nevypnu, běží pořád naplno, a mění se jeho zátěžová charakteristika). Už vidím, jak Java dělá za chodu to, co třeba MLton nebo Stalin - cokoliv získám navíc oproti třeba C++, vyžaduje takové analýzy, že si je za běhu samotné aplikace nemůžu dovolit. V oblasti platformně specifického kódu nemá Java před C++ moc velkou výhodu - i kompilátor C++ má svoje přepínače, a přinejmenším na x86 není jejich vliv nijak závratný. Ostatně máme i Acovea, pokud si s tím někdo chce pohrát. Opravdu přínosné optimalizace jsou de fakto 1) platformně nezávislé, 2) výpočetně velmi náročné. Vliv na generovaný kód na úrovni instrukcí mít mohou, ale je skoro až třešínka na dortu.

5) Zajímalo by mě, co znamená "přímo algoritmus" - jestli je řeč o zdrojovém kódu, jak Java bytecode je jen o stupínek níž nez zdrojový kód. :-) Netuším, proč by zrovna tohle mělo JVM omezovat. (JVM omezuje při JITování hlavně dostupný čas na kompilaci. S tím se potýkal už Self.)

vliv GC na vykon byva neopravnene precenovan a C++kari si neuvedomuji nektere neprijemne vlastnosti C/C++ majici drasticky dopad na vykon http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

v scheme sa kodi vo fluxuse. je to live coding enviroment na realtime renderovanu grafiku
http://www.pawfal.org/fluxus/