Benchmark programovacích jazyků

O nejrůznějších testech výkonnosti porovnávajících software či hardware se dočteme denně. Chlapce z Debianu však napadlo benchmarkovat programovací jazyky (resp. jejich implementace). V projektu The Computer Language Benchmarks Game se tak můžete například dočíst, že se na prvním místě umístil jazyk C++ těsně následovaný klasickým C-čkem. Naopak jako poslední jsou Ruby a Prolog.

28.12.2007 17:00 | Petr Tomášek | Zajímavý projekt

Komentáře

[disorder]

1) stare

2) What fun! Can you manipulate the multipliers and weights to make your favourite language the best programming language in the Benchmarks Game?

[Josef Kufner]

No, jakmile se do toho promítne i spotřeba paměti, tak první místo patří Pascalu, druhé klasickému C a třetí Adě...

[Jiri]

A pokud se do toho promítne vliv kosmického záření, tak vyhraje SmallTalk a hned za ním bude Ruby a na posledním místě bude čínština, ale to jenom pokud použijete podporu pravopisu!!!

[Heron]

Nemělo by to být spíše v kategorii "Humor"?

[unknown_]

imho nemělo, protože je to projekt, který si "dal za cíl" udělat benchmark prog. jazyků, a zajímavý bezesporu je. Naopak do kategorie humor by se měly řadit zprávičky oznamující další *buntu

[Kyosuke]

Proč ne? Tak třeba:

1) Je to šest let staré! Minimálně bych to nedával do zpráviček, tady na ten server už několikrát řeč přišla. Ať si o svém nadšení autor napíše v blogu.

2) Má to dost nízkou vypovídací hodnotu, leckdy se vynucuje konkrétní algoritmus, aniž by se třeba bralo v úvahu, že se to dá v konkrétním jazyku napsat líp jinými prostředky (případně že by tak některé věci stejně nikdo nepsal, tristní mi přijde třeba regex-dna, co se na něj teď dívám, to je fakt dobrý "benchmark jazyka", jen co je pravda). V jednu dobu zase ty benchmarky něco "počítaly ve smyčce", takže Haskell s memoizací byl suverénně "nejrychlejší".

3) Miloslav Ponkrác!

Mám ten sajt rád, ale beru výsledky tzv. "with a boulder of salt".

[unknown_]

Máš pravdu, že 6 let starý to do zpráviček nepatří. Ale ani pro kategorii Humor nespatřuji "osravedlnění".

[Petr Tomášek]

Proč ne? Tak třeba:

1) Je to šest let staré! Minimálně bych to nedával do zpráviček, tady na ten server už několikrát řeč přišla. Ať si o svém nadšení autor napíše v blogu.

Jó, tak to soráč. Viděl jsem to v nějakým blogu, takže to člověk automaticky interpretoval jako novinku :D

[ajikdpoe]

haha, vravim si jak je mozne ze vyhralo c alebo c++? Pozriem a uz je mi to jasne. V teste sa nezucastnil kompilator Borland Delphi. Myslim to smrtelne vazne. Uz neviem najst ten clanok, bolo to asi pred mesiacom, mozno dvomi. Bolo tam aj porovnavanie cas/LOC atd. Pre asi 25 jazykov/kompilatorov. Nepamata si niekto? Netvrdim urcite ze to bolo tu.

[Kyosuke]

Bude ho možné otestovat, hned jak Borland naportuje nejnovější Delphi na Debian. Extrémně starý Win32 shootout je tady.

[ajikdpoe]

ano, to je ono

[Michal Kubeček]

haha, vravim si jak je mozne ze vyhralo c alebo c++? Pozriem a uz je mi to jasne. V teste sa nezucastnil kompilator Borland Delphi. Myslim to smrtelne vazne.

Pokud budete měřit rychlost kompilace, pak je to docela dobře možné. Ale co do rychlosti výsledného kódu… to opravdu ne.

[none]

hm... pre mna je najrychlejsi asm

[CIJOML]

myslis nasm ;)

[Kvakor]

Osobne mi tyhle benchmarky pripadaji jako soutez vozidel, ktere by se zucastnily tak rozdilna vozidla, jako je na jedne strane formule F1, nadupany sportak, zavodni special, silne silnicni auto, offroad s 4x4, rodinny vuz, pojizna nakupnit taska a na druhe silnicni valec, bagr, traktor, tank, zahradni sekacka, motorizovany invalidni vozik, zivy kun, raketove sane a Boeing 747 (muze pojizdet po runwayi? muze, tak je to vozidlo ). A pak se vsichni zacnou hadat, protoze i kdyz je mozne urcit absolutni cisla, vysledky budou zcela nesrovnatelne, protoze kazde vozidlo je navrzene pro jiny teren a jiny ucel.

Kdyz se bude zavodit na dokonale, pevne draze, nejspis vyhraje formule, nasledovana B-747, pokud se povoli zavod i ve vzduchu, B-747 je jasne nejrychlejsi. A kdyz se povoli koleje, vyhraji raketove sane (ktere budou mit i nejvetsi zrychlenni). Ale pri zavodech v tezkem terenu nejspis vyhraje tank, nasledovany traktorem, offroadem a konem.

A kdyz se usporadaji zavody v supermarketu, tak nejspis vyhraje kun, sekacka nebo invaldini vozik, protoze ostatni vozdila bud neprojdou vchodem, nebo se neotoci na miste (i kdyz, kdyz dovolime destrukci zavodni drahy, tak se so toho mohou zamichat i tank a bagr ). A pokud se vezme v potaz ekonomika provozu, tak pravdepodobne vyhraje pozjidna nakupni taska ci podobny maly vuz, protoze bude mit suverene nejmensi spotrevu v l/km, pripadne kun (pokud mate vlasni staj) ci dokonce invalidni vozik (jezdi na nabijeci baterky).

Takze - porovnavat obecne programovaci jazyky je nesmysl, pokud je to ciste obecne porovnani. Vzdyt i v ramci jedine aplikace muze byt pouzito neklolik jazyku (napr. nejnizsi rutiny v ASM, knihovny a runtime v C/C++ a samotna aplikace v Lispu).

A navic, v kazdem jazyce se puziva jiny pristup - to, co se v klasickych imperativnich hjazycich (typu Fortran/PascalC/C++/Java) napise smyckou, udelaji deklarativni jazyky (jako Prolog a Lisp) rekurzi.

I samotne uvazovani programtora je urceno tim, jake jazyky pouziva (viz Sapir-Whorfova hypoteza a programovaci jazyky), proto jsou napr. priklady v C/C++ psane Javisty obcas naprosto silene (z pohledu Cckare), s perlami typu alokace jedineho intu pres new/malloc() uvnitr cyklu (to jsem videl na vlasni oci, ten priklad jde jeste nekde vygooglit).

To, co je v jednom jazyce prirozenost, je v druhem podivnost, v tretim zvrhlost a ve ctvrtem vec, kterou vubec nesmite. Jako je treba GOTO - v assembleru se bez skoku neobejdete, v Basicu bezna soucast jazyka, Pacalu a Ccku vec, ktera se nema delat a v Lispu skok neudelate vubec.

Kdyz se navic pridaji vlasnoti typu alokace pameti (vlastnorucni vs. GC), podpora vyjimek, run-time kontrola vseho mozneho, nativni podpora vlaken a paralelizace vypoctu, nutne predpoklady pro beh (nic/OS/knihovny/runtime/interpreter) a podobne veci, tak name tolik rozdilnych kategorii, ze neexistuje jazyk, ktery by byl vhodny uplne pro vsechny.

I kdyz nektere jazyky jsou dost univerzalni, jejich univerzalnost je jako univerzalnost kuchynskeho robota, ktereho ctvrt hodiny sestavujeme, pul minuty v nem krouhame mrkev a pak pul hodiny rozebirame, cistime a uklizime, zatimco se starym dobrym struhadlem by cela prace byla hotova za pet minut vcetne cisteni.

Proto nema smysl delat bencmarky mimo tech typu, kde je presne specifikovana oblast (napr. nejrylejsi jazyk na psani toho a toho algoritmu) a ani potom nejde presne urcit viteze, protoze ten nejrychlejsi nemusi byt ten nejjednodussi a nejlepe napsatelny a odladitelny.

[Kyosuke]

...a v Lispu skok neudelate vubec.

A vo co že jo?

(defun funkce1 ()
  (tagbody
     (labels ((funkce2 () 
		;; Ackoliv je tag OUT lexikalne vymezen formou TAGBODY,
                ;; muze byt skok na nej proveden z vnorene funkce o nekolik
                ;; stack frames nize. V takovem pripade se ovsem korektne 
                ;; odroluje zasobnik a provede se cleanout cehokoli, co je 
                ;; zapotrebi. Cize zadne pitome JMP, ale dobre osetreny 
                ;; bailout jako u vyjimky. Mame preci jednadvacate stoleti! :)
                ;; (Nekteri z nas uz takovych tricet let... :D)
		(unwind-protect (funkce3)
		  (print "Zasobnik se odrolovava, cistime resources!")))                         
	      (funkce3 ()
		;; Fuj, GOTO ahead! ;) Kdyz tam nedam tu podminku, smaze 
		;; mi kompilator kus kodu jako nedosazitelny, parchant jeden! :D
		(if (/= (random 2) 0) (go out)))) 
       (funkce2)
       (print "Normalni navrat.")
       (return-from funkce1))
     out
     (print "Navrat skokem na OUT")))

[Miloslav Ponkrác]

Ne ne, to není goto Vy už simulujete výjimky a odrolování zásobníku Ale kdysi mě napadlo, kdo vlastně poprvé v životě zešílel strachy a neudržel moč při pohledu na goto a rozšířil tak dogma o škodlivosti goto - a on to Dijkstra. Takže zastřelte Dijkstru a goto přestane být škodlivé a začne se objevovat ve většině jazyků

[Kyosuke]

Já nic nesimuluju. Tady se prostě projeví high-level jazyk - obyčejné (GO OUT) může vést na různý zkompilovaný kód podle kontextu. (Tedy podle MIT školy. Cčko je New Jersey school a tam se prostě vrzne JMP, a co JMP neumí, to nebude umět ani goto a basta fidli. ) Kdyby to bylo v rámci jedné funkce, bude to jen JMP i v tom Lispu. (I když tech konstrukcí, které se musejí ošetřit, je několik - ovšem jen pokud okolo jsou.)

[Miloslav Ponkrác]

Vidím, že komantář píšete v dost podezřelou hodinu, budu si Vás muset poznamenat do podezřelých osob

Jasan, já to chápu. Co takhle zavést inline asm do LISPu a to goto tam natvrdo napsat To by teprve byl bordel

[Kyosuke]

Matně vzpomínám, který Lisp vlastně nemá inline assembler... S výjimkou CLISPu, který nemá generátor kódu v runtimu, jelikož nemá nativní kompilátor, o žádném nevím. A minimálně v OpenMCL je to docela dlouho oficiálně podporovaná fíčura kvůli vektorovým operacím. Nicméně zatím si vystačím s GO. BTW, Vy taky píšete v podezřelou hodinu, ale Vás už mám na seznamu od nepaměti.

[Tom.š Ze.le.in]

Nemate nejaky odkaz na dokumentaci inline assembleru pro sbcl? Hledal jsem pred nejakou dobou, lec nenasel. Diky.

(kdybych byl rejpal, tak se zeptam na inline assembler pro Emacs Lisp, ale predpokladam, ze mluvite o CL. A docela by me prekvapil i u ABCL)

[Kyosuke]

No, o přímém veřejném API (typu defppclapfunction/defx86lapfunction v OpenMCL) pro SBCL nevím. Ale poměrně konformní cestou, jak nějakou operaci dostat do SBCL skrzevá assembler, by mělo být napsání vlastního VOPu. Navíc je to mírně granulárnější než napsání funkce a snad by to mohlo hrát líp se zbytkem kompilátoru. Zatím jsem to nepotřeboval, ale docela by se mi na některé věci hodila instrukce PSADBW, hlavně na metrické stromy . Předpokládám, že na to by mi měl stačit i jen ten VOP. Co takhle se zeptat rovnou vývojářů, pokud máte v tomhle větší potřebu než já? C. Rhodes se o tom kdysi zmiňoval na comp.lang.lisp, se slovy "Jak to udělat, máte popsané tady", a uvedl dnes již neplatný link. :-/

A samozřejmě mluvím o CL, přičemž ABCL je AFAIK zatím docela nedotažené, proto ho neuvažuju. Navíc jeho autor se teď věnuje XCL, nevím, jak moc se ABCL vůbec bude věnovat v budoucnu. (Možná jsem mohl doplnit i GCL a podobné věci, ale ty mi stejně poslední dobou přišly ta nějak mrtvé...)

[Pavel Čejka]

Brr.. GOTO Ješte lepší jsou samomodifikující se kusy kódu ... a tohle není hardcore příklad, ale dejme tomu taková ukázka běžného použití.

CONTROLS	ld	a,(CONSEL_B)
		out	(254),a
		ld	a,(CONSEL_CL)
		ld	(CLS_COL),a
		call	CLS
		ld	hl, CONTR_TXT
		call	TEXTOUT
CONTROLS0	call	PAUSENK		; počkej dokud uživatel nepustí klávesu
		call	INKEY
		cp	49
		jr	z,CONTR_KB	; uživatel zvolil klávesnici
		cp	50
		jr	z,CONTR_AM	; uživatel zvolil AMOUSE
		cp	51
		jr	z,CONTR_KM	; uživatel zvolil KMOUSE
		cp	113
CONTR_QA	jp	z,CONTROLS	; tato adresa má být přepsána adresou pro ukončení programu
		jr	CONTROLS0

CONTR_KB	xor	a
		jr	CONTR_END

CONTR_AM	ld	a,1
		jr	CONTR_END

CONTR_KM	ld	a,2
CONTR_END	ld	(MOUSE_HID),a	; nastaví human interface device
CONTR_EA	jp	CONTROLS	; tato adresa má být přepsána adresou pro pokračování běhu

[Miloslav Ponkrác]

Na Z80 samomodifikující kód mohl dost výrazně zlepšit rychlost prgoramu. Na dnešních procesorech naopak samomodifikující se kód výrazně, a to velmi velmi výrazně zpomalí program, a v předchozích typech procesorů dokonce samomodifikující kód mohl znamenat, že půlka modifikací se vůbec nevykoná.

Jinak toto je ještě hodně slabá ukázka - dějí se daleko větší divočiny ohledně samomodifikace, hlavně z důvodů ztížení reverse engineeringu a běžně se skáče doprostřed instrukce, aby tak vznikla instrukce naprosto jiná, nečekaná.

[Lukáš Zapletal]

Překvapil mě Free Pascal, slušný výkon, porazil i Javu od Sunu, na které přece tolik pracují

[Miloslav Ponkrác]

To mícháte hrušky s jabkama. Při dobře udělaném a skvěle optimalizujícím kompilátoru musí low level kompilované jazyky jasně porazit Javu. C/C++/Ada/Fortran/Pascal/atd.. pokud jsou pomalejší, než Java, pak máte buď špatný kompilátor, nebo mizerného programátora, který by méně škodil jako kopač kanálů.

Jinak nejkouzelnější jsou "seriózní a objektivní" testy provedené javisty, ze kterých jim běžně vychází, že Java je mnohem rychlejší, než C/C++, a sem tam dokonce, že Java je rychlejší, než asm a stroják. Ovšem při pohledu na ten zdroják, který pustí do testování se mi chce brečet. Například javista běžně alokuje lokálně 10 proměnných a všechny je vytvoří pomocí malloc/new !!! A hezky o pár řádků dále na konci lokálního bloku je zase pěkně po sobě uklidí pomocí free/delete !!! A ještě si stěžuje, že tohle by v Javě řešit nemusel, že by gc ty proměnné uklidil sám A nepřijde mu to divné, proč taky, v Javě se to tak dělá, tak jaký křeče. Většinou je totiž C/C++ zdroják přesným opisem Javy, včetně toho, že třeba enum je v C++ dokonalá třída se vším všudy, včetně konstruktoru, destruktoru a virtuálních metod.

[Jarda]

No, nemusi. JVM dokaze delat za behu dalsi optimalizace, ktere ani ten nejskveleji optimalizujici kompilator bez kristalove koule v compile time zvladnout nemuze. Bohuzel, na prikladech typu vynasob dve matice a udelej to rychle, se to neprojevi.

Jinak pokud se vam nelibi pouzite kody, tak jim poslete lepsi.:)

[Miloslav Ponkrác]

Ad první odstavec: Bohužel oproti možnostem dobrého kompilátoru JVM moc možmostí nemá. Všechny ty optimalizace za běhu mají totiž dvě obrovské nevýhody:

1) Optimalizace za běhu zpomaluje běh programu, protože zkrátka probíhá ve stejném čase jako program. Každé profilování za běhu zpomaluje program, každá změna, či dynamická optimalizace za běhu opět dále ještě více zpomaluje program. Tudíž z toho vyplývá, že JVM se opravdu moc rozšoupnout nemůže, protože kdyby moc optimalizovala, tak výsledkem je zpomalení, protože čas potřebný pro optimalizaci bude větší, než ušetřený čas.

2) Praktické zrychlení dynamické optimalizace JVM a její vliv na větší rychlost, než u kompilátorů nikdo nikdy v praxi nepředvedl a to naprosto na žádném příkladě, nejen na násobení matic. Zatím se o tom jenom kecá, všude se píše o možnostech optimalizace, ale na benchmarku se to ještě nikdy nikomu neprojevilo. Nějaké dobré výsledky oproti kompilátoru C/C++ vlivem optimalizace JVM se nikdy v praxi nedosáhlo (a ono není divu, viz bod 1), přesto se o tom kecá. Ale zůstává to pouze snem, utopií a přáním některých jedinců.

Co se týká použitých kódů, k tomu bych dodal - pokud neumím psát v C++, nedělám jeho benchmark. Dělám to co umím a nelámu se do toho, na co jsem levý jako šavle - to na adresu podobných testů a benchmarků. Od javistů by to chtělo trochu sebekritiky a trochu přiznání si skutečného stavu a neschopnosti. Nemůžu za to, že lemplové od javistů se snaží o to, na co nemají - a nemá smysl je podporovat v jejich lemplovství tím, že jim budu dělat co neumějí - on by totiž člověk nedělal nic jiného a čas je docela vzácná komodita.

[mj41]

Jednou jsem narazil na Parrot -Ofun (diskuse), kde Leo tvrdil, ze u rekurzivnich funkci muze mit (ma) JIT navrch.

Jinak o tom, ze JIT neni vzdy to prave pise i Dan.

OFFTOPIC: Mimochodem tihle dva se nepohodli, takze pred par lety Dan prestal makat na Parrotu a posledni mesice je Leo vytizen svym zamestnanim, takze jsem uz o nem taky dlouho neslysel. Hold open source projekt bez penez. Aspon, ze Mozilla dodala 10tis$ a Patrick trochu pohnul a snad jeste pohne s implementaci Perlu 6.

[Miloslav Ponkrác]

Pokud, jak je obvyklým zvykem se to porovnává s mizerně optimalizujícím gcc kompilátorem, tak se tím nemá cenu moc zabývat. Zajímavé je, že 99% benchmarků vůči C/C++ jsou provedeny na gcc/g++, čímž jsou znehodnoceny. Je to jako dělat test rychlosti formule 1 na autu z vrakoviště po 30 letech používání, tudíž vypovídací hodnota nulová - nebo spíše lživá.

Problém je totiž ten, že dobře a kvalitně optimalizující C kompilátor rekurzivní funkce může urychlit naprosto stejným způsobem, jako to dělá JIT plus má výhodu mnoha dalších optimalizací a výhodu toho, že kompilátor má na optimalizace čas, což JIT nemá.

[Kyosuke]

A uděláte si někdy čas a popíšete nám ty nedostatky GCC co do optimalizací, aby se na to mohl třeba Honza Hubička, Zdeněk Dvořák, nebo další naši i přespolní kompilátoroví machři podívat a něco s tím udělat, nebo si to budete další dva roky nechávat pro sebe, jako ty předchozí?

[Miloslav Ponkrác]

Já jsem to podrobněji nezkoumal, já jsem prostě otestoval, že kód z gcc je o dost pomalejší, než kód z MS kompilátorů, nebo neřku-li z Intel kompilátorů. Samozřejmě jsou i horší kompilátory, než gcc, třeba Borladnské.

Když si čas od času dělám interní benchmarky kompilátorů, tak poslední výsledek je tento (budu brát Intel kompilátor jakožto 100% a čísla budou vyjadřovat kolikrát více času potřebuje program přeložený v kmpilátoru na stejnou úlohu, tedy menší číslo znamená lepší kompilátor - všechny kompilátory jedou na max. optimalizace):

(Test řešení numerické úlohy zdůrazňující double čísla): Intel: 100% Microsoft: 116% Digital Mars: 137% gcc: 152% Borland: 160%

(Test rychlost kódování mp3 pomocí lame - zde se zdůrazňuje rychlost práce s integer čísly): Intel: 100% gcc: 225% Microsoft: 229% Digital Mars: 249% Borland: 473%

Jak jistě vidíte, v každém případě Intel ještě vytáhl rychlost minimálně o navíc o třetinu výše oproti gcc - takže veškeré testy, které používají gcc ani zdaleka nejsou maximem, co se dá z C/C++ programů vymáčknout.

Nedělám si velké nároky na serióznost testu, dělám si jej čas od času znovu pro své interní potřeby. Vše je testováno v jednotném prostředí na Windows. Bohužel rozdíly mezi gcc a Microsoftem se na Windows uměle přibližují, protože gcc používá runtimovou knihovnu od Microsoftu - MSVCRT.DLL přeloženou Microsoftem, takže hodlám vymyslet test, který bude naprosto minimalizovat používání runtime knihovny - což dělá třeba ta verze s double čísly, ale ta není pro int směrodatná.

Jinak jsem občas porovnával i asm a bylo vidět, že asm z gcc občas není ještě zcela uhlazená, dalo by se to zrychlit. Ono x86 architektura je velmi náchylná na pořadí instrukcí a stačí přehodit pořadí dvou strojových instrukcí a rychlost Vám to změní i o mnoho procent.

Nicméně, jak je jasně vidět, rozdíl mezi Intel a gcc kompilátorem je značný a v reálných aplikacích to bývá mnoho desítek až stovek procent v neprospěch gcc. A jak moc mám brát benchmark, který testuje rychlost C/C++ programu, když vím, že program může být až několikanásobně rychlejší, když se nepoužije gcc?

[jj]

Mozete dat prosim link na nejaky Vas testovaci program ? velmi rad by som ho vyskusal.

[Kyosuke]

"JVM dokaze delat za behu dalsi optimalizace, ktere ani ten nejskveleji optimalizujici kompilator bez kristalove koule v compile time zvladnout nemuze. Bohuzel, na prikladech typu vynasob dve matice a udelej to rychle, se to neprojevi."

Jak píše pan Ponkrác, AOT kompilátor zase může v compile time provádět další optimalizace, které ani nejskvělejší optimalizující JVM nemůže bez stroje času provést, protože na ně prostě nemá čas. Přičemž recyklování optimalizací prováděných JVM (těch, které stojí za to), pokud se někdy bude provádět, nebude až taková sranda. Jako potomek Strongtalku HotSpot s největší pravděpodobností generuje kód, u kterého se těžko dá říct, co patří ke které funkci.

[okbob]

Javu porazil i Oberon, a to je jen slusne napsany minimalisticky prekladac bez optimalizaci.

[Lukáš Zapletal]

Ano a zhruba sem jsem mířil, že mě to překvapilo. Do diskuzí, které započal M. Ponkrác, se ale zapojovat nebudu...