Kirjautuminen

Haku

Tehtävät

Keskustelu: Yleinen keskustelu: Kääntäjien erot

Sivun loppuun

Jokotai [21.02.2010 11:42:28]

#

Onko kääntäjillä paljon eroa, koodin kanssa, entä kääntö- ja suoritusnopeuden kanssa.

Macro [21.02.2010 11:53:21]

#

Kai se riippuu paljonkin siitä, mitä kieltä käännät, ja mitkä ovat vaihtoehdot.

Jokotai [21.02.2010 14:37:35]

#

VC++ vs. GCC
XEmacs vs. Javan oma kääntäjä

aaämdee [21.02.2010 14:44:56]

#

Tietääkseni VC++ tuottaa hieman tehokkaampaa koodia kuin GCC, mutta VC++ on vain Window-järjestelmille. GCC:llä kääntää melkein mille kohdejärjestelmälle tahansa.

Javakääntäjien tuotoksissa voi olla ehkä jotain optimointieroja, mutta tietääkseni javan tavukoodin optimoinnilla ei saavuteta suurta hyötyä (jos ollenkaan), sillä Javan virtuaalikone optimoi tavukoodia ajon aikana.

Metabolix [21.02.2010 15:02:46]

#

GCC on todella laajalti käytetty kääntäjä, ja lisäksi sillä on suuri kehittäjäyhteisö, mikä minusta kertoo myös hyvästä laadusta. Toki MS:n omat kehittäjät silti tietävät paremmin Windowsin niksit, joilla voi saada kyseisessä ympäristössä pientä etua.

Joka tapauksessa kannattaa muistaa, että kääntäjästä aiheutuva nopeusero on minimaalinen. Mikään ei pelasta tilannetta, jos algoritmi on surkea.

Ja eiköhän se XEmacs ole vain tekstieditori, joka vain käyttää jotain muuta koneelta löytyvää Java-kääntäjää...

ajv [21.02.2010 16:35:56]

#

Voiko VC++-kääntäjää oikeasti verrata GCC:hen? Eikös ensin mainittu tuota tavukoodia, jota .NET runtime tulkkaa (=kääntää binääriksi sitä mukaa kun suoritetaan) ja jälkimmäinen suoraan natiivia binäärikoodia.

Korjatkaa jos olen ymmärtänyt väärin.

Edit: Siis oletan, että puhutaan VC++ .NETistä.

Grez [21.02.2010 16:37:07]

#

VC++ kääntäjällä voi tuottaa sekä CLR-koodia että natiivikoodia. Ennen .net-aikaa VC++ kääntäjät tuottivat ainoastaan natiivikoodia.

ajv [21.02.2010 16:38:10]

#

Ok, kiitos tarkennuksesta. Kysyjän kuitenkin hyvä tiedostaa tämä (ellei jo tiedostanut).

Blaze [21.02.2010 17:32:27]

#

Jokotai kirjoitti:

XEmacs vs. Javan oma kääntäjä

Hetkinen... Mitäs sellaista yhteistä näillä kahella on, että niitä voi vertailla?

jalski [21.02.2010 20:34:39]

#

Kääntäjän valinta on pitkälti makuasia. Kannattaa valita se paketti, minkä työkalut istuvat omaan työskentelytapaan parhaiten.

Esimerkkinä itse käyttämäni OpenWatcom:

- Tekee kohtuullisen optimoitua koodia.
- Tuki DOS:sille, 32-bittiselle DOS:sille extenderin avulla (dos4gw tai CauseWay).
- Tuki OS/2 ja Windows käyttöjärjestelmille.
- IDE, hyvä Debuggeri ja profileri.
- Jos tykkää sotkea assemblyä C-koodin joukkoon, niin todennäköisesti joustavin ja antaa inline assemblyn kanssa todennäköisesti parhaan kontrollin rekistereiden kanssa.
- Miinuksena C++ tuki puutteellinen.

Jokotai [21.02.2010 20:40:51]

#

Blaze kirjoitti:

Jokotai kirjoitti:

XEmacs vs. Javan oma kääntäjä

Hetkinen... Mitäs sellaista yhteistä näillä kahella on, että niitä voi vertailla?

XEmacs ja Javan oma kääntäjä kääntävät Javaa.

jalski [21.02.2010 21:03:21]

#

Jokotai kirjoitti:

XEmacs ja Javan oma kääntäjä kääntävät Javaa.

XEmacs on tekstieditori, jota laajennosten avulla voi käyttää useammankin eri ohjelmointikielen IDE:nä. Siinä itsessään ei kuitenkaan ole Java-kääntäjää mukana.

Jackal von ÖRF [22.02.2010 00:20:44]

#

Ja Javan kääntäjä (javac) ei tee mitään optimointeja. Javassa kaikki optimoinnit tehdään ajonaikaisesti. JVM:n eri versioiden JIT-kääntäjien välillä puolestaan on eroja - yleensä uudempi versio tuottaa nopeampaa natiivikoodia, koska uudemmassa on enemmän optimointeja.

Jokotai [22.02.2010 10:31:29]

#

Entä koodi puoli, onko samoja kirjastoja(algoritmitmeihin yms.)?

Jackal von ÖRF [22.02.2010 11:26:44]

#

Toki myös kirjastoihin ja esim. roskienkerääjän algoritmeihin on tullut aikojen saatossa parannuksia. Täältä löytyy yksityiskohtia: http://java.sun.com/javase/6/docs/technotes/guides/performance/speed.html
http://java.sun.com/docs/performance/index.html

Macro [22.02.2010 11:27:57]

#

Itse en ole minkään kääntäjän kanssa huomannut nopeuseroja, mitä olen käyttänyt. Minusta se on makuasia, minkä sitten valitsetkin.

Jackal von ÖRF [22.02.2010 11:56:32]

#

Nopeuserojen pitää olla melko suuria, jotta ne pystyy silmin havaitsemaan. Jos nopeus ei vähintään kaksinkertaistu, niin sitä on vaikea havaita ilman mittausta.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"
-- Donald Knuth

Jokotai [22.02.2010 20:30:24]

#

Jackal von ÖRF kirjoitti:

Nopeuserojen pitää olla melko suuria, jotta ne pystyy silmin havaitsemaan. Jos nopeus ei vähintään kaksinkertaistu, niin sitä on vaikea havaita ilman mittausta.

Paitsi että koko Suomen kansan 1000 kertaa läpikäyminen on ajankulutukseltaan sen verran iso että sillä on väliä.

Metabolix [22.02.2010 20:45:33]

#

Tuosta päästäänkin taas algoritmikysymykseen: Miksi ihmeessä pitää käydä Suomen kansa läpi tuhat kertaa? Mitä sellaista tällä saavutetaan, ettei samaan tulokseen voisi päästä tehokkaammalla algoritmilla, joka toimisi monin verroin nopeammin vaikka hitaalla tulkilla ajettuna?

Minusta tämä koko keskustelu on vähintäänkin epämääräinen, kun alkuperäinen kysymys on tasoltaan "onko jossain jotain eroa". Toki eri ohjelmilla on eroja, mutta yleisesti käytettyjen ohjelmien on pakko olla melko hyviä: eihän kukaan käyttäisi vakavissaan huonoa ohjelmaa, jos tarjolla olisi paljon parempiakin. Eroilla ei kannata vaivata päätään, ennen kuin tekee jotain sellaista, että asialla on merkitystä.


Sivun alkuun

Vastaus

Aihe on jo aika vanha, joten et voi enää vastata siihen.

Tietoa sivustosta