Vlákno názorů k článku Scheme: kostlivec ve skřini nebo nehasnoucí hvězda? od Miloslav Ponkrác - Ach jo - já nevím, ale stále vidím,...
-
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. -
Rejpal (neregistrovaný)
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. -
Rejpal (neregistrovaný)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. -
Rejpal (neregistrovaný)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++. -
Rejpal (neregistrovaný)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. -
Rejpal (neregistrovaný)
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. -
anonymníPrvou vetou zrejme predrecnik myslel: "show us your code" a on ho benchmarke voci ekvivalentu prelozenenu v Stalinovi.
IMHO hadat sa o to, ktory jazyk je rychlejsi, je nezmysel (je tak maximalne mozne urobit par benchmarkov na konkretnych verziach prekladacov, ale o com to vypoveda, je druha vec). Aby bolo jasne, nemyslim si, ze by bol C/C++ zly jazyk (nakoniec niekolko rokov v nom pisem kazdodenne).
Napriek tomu by som mal niekolko vyhrad - IMHO ma zbytocne vela veci, ktore zvadzaju ludi pisat podivne veci - ktore napr. idu pod niektorymi prekladacmi prelozit (msvc a starsie gcc), a cistou zhodou okolnosti funguju, na novsom gcc uz nejdu (pretoze ani nemaju ist). Zbytocne je napisane nieco v norme, ked sa prekladac podla toho nesprava (a ludi, co naozaj poznaju C++ "kompletne", poznam osobne asi dvoch, aj to asi preto, ze pisali prekladac; norma tiez nie je vzdy uplne jasna).
Dalej snad kazdy prekladac ma svoje vlastne extensiony, co robi napr. spolupracu na multiplatformnom projekte komplikovanou; hlavne ked je niekto na nestandardne extensiony zvyknuty. (BTW netrapi ma, ze icc je v benchmarkoch rychlejsie nez gcc, ked som naposledy skusal jednu 10.x verziu, tak bola celkom bugovita, co samozrejme neznamena, ze gcc je bug-free).
Ad 2) samozrejme suhlasim, to je to o co ide - zbytocne je jazyk rychly, ked niekto veselo napise nieco, co ma zlozitost napr. O(n^3), pricom by to slo napr. O(n). Plus vieme odkial su buffer overflowy. -
ferren (neregistrovaný)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 -
Rejpal (neregistrovaný)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. ;-)
-
alblaho (neregistrovaný)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. -
georgo (neregistrovaný)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. -
georgo (neregistrovaný)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. -
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. -
Rejpal (neregistrovaný)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. -
anonymníMohl byste uvést nějaký příklad srovnání těchto kompilátorů, co gcc/g++ vytýkáte, co je konkrétně špatně (jsem celkem začátečník, takže mě to zajímá, i když o jejich rozdílech moc nevím). Já totiž spíš slyšel (nezkoušel), že gcc je poměrně dobrý kompilátor (na C), který se vyrovná čemukoli jinému snad s vyjímkou intelovského kompilátoru na intelech. Zajímá mě tedy váš názor.
-
Honza (neregistrovaný)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, ... -
anonymníMozna zminka o te rychlosti byla myslena tak, ze pokud obyc programator (se zakladnima znalostma C a LISPu) napise program v LISPu a stejne funkci v C, tak ten program v C bude pomalejsi, protoze tenhle programator nezna vsechny ty vychytavky, ktery by sly udelat pro optimalizaci C kodu. Kdezto ten LISP kompilator tyhle optimalizace udela, protoze je vysledny kod rychlejsi v LISPu.
Dalsi otazka je, kolik C programatoru je skutecnych profiku, ze znaji vsechny optimalizacni triky v C a kolik jich vlastne pri psani C kodu pouzijou. Zatimco profik treba zvladne pri psani kodu pouzit 90-95% vsech pouzitelnych optimalizaci v tom kodu, LISP kompiler jich pouzije 100%. Nehlede na to, ze pri psani v C se bude muset programator soustredit jednak na psany kod, ale zaroven take na optimalizacni veci, kdezto LISP programator se bude soustredit pouze na hlavni kod a kompiler pak provede optimalizacni veci. Ve vysledku tedy urcite pujde napsat C program prinejmensim stejne efektivne jako LISP, ale pokud je ten LISP kompiler fakt tak dobrej, tak by mohl ve vetsine realnych situacich LISP program behat rychlejc, prave kvuli tomu, ze se C programator bude soustredit vic na hlavni logiku C programu a mene na ty optimalizacni veci, ikdyz to bude C profik. -
Rejpal (neregistrovaný)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. -
Rejpal (neregistrovaný)
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-gensymsje 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. -
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. -
mrtve IQ pana Miloslava Ponkraca (neregistrovaný)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. -
Žá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?
-
Michaelson (neregistrovaný)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... -
Michaelson (neregistrovaný)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 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.
-
anonymníNeznam moc LISP, ale asi rozumim, co mu vadi. Nejde o to, ze by v LISPu neslo psat prehledne nebo by omezoval paradigma. Problem je spis v tom, ze tam takova omezeni nejsou. To znamena, ze si to kazdy programator udela po svem, a pokud mate program, na kterem dela (nebo spis v historii delalo) vic lidi, nastanou problemy.
Pisu ted v mainframe assembleru a tam je to podobne. Assembler je mocny, vsechno v nem napisete, a pomoci maker i prehledne, ale problem je, ze nema standardni knihovnu, a tak si to kazdy pise po svem. A i kdyby standardni knihovnu mel, tak budou lidi nespokojeni, jak je pomala/slozita/zere pamet a stejne si to budou delat po svem, proste proto, ze jim to ten jazyk dovoluje.
Python ma filozofii "there should be one preferable way to do it", a ta mu svedci, protoze pokud seberete 10 lidi do tymu, tak budou vsichni programovat zhruba stejne (pouzivat stejne zarovnani, seznam jako array a tuple jako record, pouzivat standardni knihovnu atd.). To same plati v mensi mire i u Javy a C# (i kdyz ty jazyky nemusim). U LISPu tohle neni realne, a to je jeho problem. -
anonymníVzdyt rikam, ze to neni technicky problem. Neni to ani problem lidi, protoze v jinych jazycich to takovy problem neni, a neni to ani tim, ze by lide kolem LISPu byli hloupi (spis naopak). Proste, je treba si vybrat - minimalismus je elegantni, ale prinasi i prakticke nevyhody. Takze to asi k tomu, co panu Ponkracovi mohlo vadit (nevim, zda mu vadi prave toto, jenom podotykam, ze to muze zpusobovat potize).
-
Michaelson (neregistrovaný)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...:) -
uf (neregistrovaný)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. -
Pavel Tisnovsky (neregistrovaný)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.
ČLÁNKY DO MAILU