Keskustelu: Yleinen keskustelu: Ohjelmointikielet

Eli onko eri ohjelmointikielillä, jotain huomattavia "teho" eroja? Tai siis lähinnä tarkoitan, että suorittaako Basic ja JavaScript, jonkun samantapaisen koodin eri nopeudella?

javascriptistä en tierä mutta monet basicit ovat vähän hitaita.

En nyt Dudemaisesti lähtisi yleistämään noin.

Eroja eri kielien välillä on huomattavasti. Tosin suoraviivaista lopputulosta ei voi esittää koska kieli A voi olla kieli B:tä hitaampi tietyssä asiassa mutta jossain toisessa asiassa tilanne kääntyy täysin päinvastoin. Pitkälti riippuu siitä mihin tietty ohjelmointikieli on tarkoitettu.

Eroja syntyy myös sen mukaan onko kieli tulkattava vai käännettävä.

Älkääkä unohtako nopeus/muistieroa mikä syntyy siitä onko koodi optimoitua vai täyttä purkkaspagettimössöä..

-Grey-

Tulkattu = Hidas
Käännettävä = Ultranopee

Eikös se noin mene?

Eiks pyyttoni oo aika nopee joissain toimituksissa, vaikka se onkin tulkkikieli?

lainaus:

Tulkattu = Hidas
Käännettävä = Ultranopee

Eikös se noin mene?

Ei. Tiedän monia erittäin nopeita tulkattavia kieliä, mutta myös monia säälittävän hitaita käännettäviä kieliä.

lainaus:

Eiks pyyttoni oo aika nopee joissain toimituksissa, vaikka se onkin tulkkikieli?

Python on suht vikkelä mutta sen vahvuuksiksi kyllä luettelisin vallan muut tekijät.

Miten muuten määritellään kielen nopeus? Sen perusteella kuinka vikkelään kuva liikkuu ruudulla tai kuinka kauan kestää tehdä 100000 silmukkaa? Esim. grafiikan suhteen aika monet kielet jo käyttävät samoja grafiikka kirjastoja joten sieltä se ero ei välttämättä enää tule.

Harvemmin ohjelmointikielten määrittelyissä puhutaan mistään komentojen välisistä hidastussilmukoista tai vastaavista, eli mikään ohjelmointikieli ei ole tuomittu olemaan hidas. Ohjelmointikielen nopeus riippuu siis siitä, kuinka nopeaksi joku on onnistunut toteuttamaan sen. Tietenkään käytännössä ei paljon lohduta, jos jonkin ohjelmointikielen voisi kyllä mainiosti toteuttaa erittäin nopeaksi, mutta kaikki olemassa olevat toteutukset sattuvat olemaan hitaita.

Ensimmäinen nopeuteen vaikuttava asia on, käännetäänkö ohjelma vai suoritetaanko se tulkin avulla. Ohjelman kääntäminen tarkoittaa, että se muutetaan konekieliseksi, ja tällöin ohjelma on nopea, koska tietokone saa käyttöönsä suorat toimintaohjeet. Jos taas suorituksessa käytetään apuna tulkkia, tietokoneen pitää joka vaiheessa ensinnäkin selvittää koodista, mitä sillä hetkellä kuuluu tehdä, ja sen lisäksi vielä tehdä kyseinen asia. Toisin sanoen käännetyillä ohjelmilla on selvä nopeusetu kääntämättömiin verrattuna.

Lisäksi nopeuteen vaikuttaa, kuinka lähellä ohjelmointikieli on tietokoneen konekieltä ja mitä varmistuksia ohjelmointikieli tekee. Esim. C-kieli on melko lähellä monen tietokoneen konekieltä ja se ei tee turhia varmistuksia (esim. ohjelma saa kirjoittaa taulukon rajojen ulkopuolelle), ja niinpä C-kieltä pidetään nopeana ohjelmointikielenä. Jos taas ohjelmointikieli sisältää korkean tason komentoja, joita ei ole helppo muuttaa konekielisiksi, toteutuksesta tulee helposti hidas, ja jos ohjelmointikieli tarkistaa kaikenlaisia asioita, siihen kuluu varmasti enemmän aikaa kuin jos asioita ei tarkisteta. Esim. jos jokaista taulukkokomentoa ennen pitää tutkia, että annettu taulukon kohta ei mene rajojen ulkopuolelle, niin tämä tietysti hidastaa ohjelman toimintaa.

Ohjelmointikielten nopeuksissa on todellisia eroja, mutta yllättävän usein syy ohjelman hitauteen onkin ohjelmoijassa. Esim. jos Basic-ohjelma on hidas, moni mielellään valittelee kielen huonoutta, vaikka selitys onkin kehnosti suunnitellussa koodissa. Lisäksi riippuu aika paljon käyttötilanteesta, milloin ohjelmointikielen nopeudella on merkitystä. Jossain pelissä voi vaikkapa olla tärkeää, päivittyykö kuva sadasosasekunnin vai sekunnin välein. Mutta yleensä ei ole mitään merkitystä, millä kielellä ohjelman tekee, kunhan ohjelman laatii järkevästi, mikä tarkoittaa sitä, että käytetyt algoritmit on valittu hyvin.

Laaksosen hyvään vastaukseen vielä lisäyksenä että muistinhallinta on yksi mikä usein hidastaa tulkattavia kieliä. Jos käyttäjän/ohjelmoijan ei tarvitse huolehtia muistin varaamisesta ja vapauttamisesta, tulee koneen tehdä se, ja tämä luonnollisesti syö resursseja ja hidastaa ohjelman toimintaa.

E.K.Virtanen: No ainaki vanhemmat microsoftin basicit.

Dude. Niin no joo. Mutta nyt sinullekin tiedoksi että BASIC tänään <> BASIC 20v sitten.

Visual Basicit ennen versiota 5 olivat aina tulkattuja/P-koodia, eivätkä konekielelle käännettyjä. Versiossa 5 sitten tuli käyttöön kääntäjä, joka pohjautui pitkälti johonkin C-kääntäjään. Luonnollisesti kääntäjissä on tapahtunut merkittävää kehitystä vuosien varrella, ja lisäksi jotkut kääntäjät osaavat optimoida "purkkakoodia" - toisaalta samaiset huippuoptimoivat kääntäjät voivat optimoinneillaan aiheuttaa virheitä. Homma kun perustuu siihen, että yksinkertaistetaan sitä mitä koodissa oikeasti tehdään, ja joskus sitten voi jäädä tekemättä jotakin mitä on tarkoitettu tehtävän.

Toinen asia sitten on tietysti se, että nykyiset kääntäjät osaavat myös ottaa huomioon nykyaikaisemmat prosessorit, jolloin ohjelma ei toimi enää vanhemmilla koneilla, mutta nopeus uusilla prosessoreilla on parempi laajemman käskykannan antamien lisämahdollisuuksien ansiosta.

JavaScriptin nopeus taas riippuu sitä suorittavasta selaimesta. Esimerkiksi uusi kolmosversion Safari on huomattavasti nopeampi JavaScriptin kanssa kuin vanha kakkosversio. Samalla se käyttää paremmin/vähemmän muistia niin JavaScriptin kuin muiden sivun osasien kohdalla.

Aliothin benchmark-leikki antaa joskus hieman viitettä, mikä on ns. nopea kieli ja mikä ei.

http://shootout.alioth.debian.org/

Tämä ei varsinaisesti kerro, mikä kieli on hyvä. Se ei edes kerro, mikä kieli on nopea. Se kertoo vain mille kielille on tehty ohjelmia, jotka toimivat nopeasti testatuilla ympäristöillä. Huono tulos kielellä X voi kertoa pelkästään siitä, että sillä testatut ohjelmat ovat huonosti tehtyjä.

Testissä ei ole mukana Microsoftin tuotteita.

Hassua vielä nähdä vuonna 2008 väitteitä, että roskienkeruu hidastaa ohjelmien toimintaa. Tim Sweeneykin käyttää itse toteuttamaansa mark and sweep -roskienkeruuta Unreal-pelimoottorissa, kuten tästä viestistä paljastuu.

http://lambda-the-ultimate.org/node/1277#comment-14252

Hänen mukaansa pelissä, jonka on tarkoitus on pyöriä nopeudella 30 framea sekunnissa voi käyttää roskienkeruuta nykykoneilla. Että se siitä hitaudesta.