(mala digresija u vezi tih benchmark testova na shootout-u)
Na Erlang mailing listi je bila pocetkom marta diskusija na temu brzine izvrsavanja jednog algoritma implementiranog u Erlang jeziku.
Implementacija nije u potpunosti iskoriscavala potencijal Erlang jezika i napisana je bez paralelizma (za zainteresovane, Erlang je
funkcionalni jezik sa ugradjenom podrskom za paralelno izvrsavanje (concurrency) procesa u soft realtime, distributivno programiranje,
itd).
Neko je na listi implementirao isti algoritam ali uz koriscenje paralelizma i unapredjenje u performansama je bilo neverovatno. Zatim
se postavilo pitanje da li bi paralelizam bio dozvoljen na shootout igri (moje licno misljenje je da bi trebalo da bude dozvoljeno).
Konkretniji primer nepoznavanja ili nekoriscenja osobina programskog jezika za povecanje performansi ne mogu da nadjem :)
(kraj digresije)
Brzina izvrsavanja programa je veoma sirok pojam (citava grana industrije, reklo bi se) gde se dodatne performanse mogu dobiti
na razne nacine. Ako predstavimo
performanse sa propusnom moci nekog programa (throughput, koliko ulaznih podataka program
moze da obradi i pretvori u izlazne podatke za jedinicu vremena) a
skalabilnost programa predstavimo sa kolicinom novca potrebnom
da se poveca propusna moc (performansa) imamo za cilj da nam program pre svega bude skalabilan (u prevodu da sa sto manjom
kolicinom novca dobijemo najvecu propusnu moc).
U tom znacenju pitanje performansi je pre svega pitanje za narucioca posla (ili programa) - koliko su performanse izvedenog programa
prihvatljive za upotrebu i koliko novca zeli da ulozi u poboljsanje tih performansi.
Za dosta narucioca s kojima sam ja imao prilike da saradjujem najbitnija stavka je tacnost programa (u prevodu, program radi ono
za sta je dizajniran) u nekim normalnim okvirima performansi (za cije merenje koristim
PLANGUAGE).
Sto se mene tice, odavno sam prestao da brinem o performansama, jer poznajuci jezik, meni i mojim klijentima performanse ne
predstavljaju nikakav problem. Slazem se da bi u nekom drugom jeziku neki od programa bili znatno brzi - narocito ako bi ih
implementirao neko ko je ekspert u tim jezicima. Meni licno bi to predstavljalo problem jer pogodnosti koje Python jezik pruza
ne bih menjao ni za sta drugo.
Verujte mi na rec, kada u timskom radu (tim od 5+ ljudi) pocnete da radite u Python jeziku vise ne zelite da radite ni u cemu drugom.
Nazalost, na poslu radim dosta u Javi i svaki put dodjem do zakljucka da bih konkretan problem znatno brze (i sa znatno manje kôda)
izveo u Python jeziku. Najbitnija stvar je da pritom ne bih izgubio nista na citljivosti i razumljivosti programa!
Alex: My favorite site is
http://localhost/
R.J. Oppenheimer: "I am become death, destroyer of worlds" (1945 AD)
tweet.13x ||
linkedin.13x