https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904#c10
Ei taida olla paljoa merkitystä sillä kuinka hyvää koodia kirjoitat, kääntäjän laatu lopulta ratkaisee. Linux olisi pitänyt alusta alkaen kirjoittaa standardi C kielellä ja kirjoittaa kokonaan oma kääntäjä sitä varten. Nyt Linux on niin sidoksissa GCC-kääntäjään ettei virallinen ydin käänny millään muulla kääntäjällä ja ytimestä on tulossa ihan paska pelkästään GCC-kääntäjän ongelmien takia (ja politiikan). Hieno homma. FreeBSD here I come
Ei taida olla paljoa merkitystä sillä kuinka hyvää koodia kirjoitat, kääntäjän laatu lopulta ratkaisee. Linux olisi pitänyt alusta alkaen kirjoittaa standardi C kielellä ja kirjoittaa kokonaan oma kääntäjä sitä varten. Nyt Linux on niin sidoksissa GCC-kääntäjään ettei virallinen ydin käänny millään muulla kääntäjällä ja ytimestä on tulossa ihan paska pelkästään GCC-kääntäjän ongelmien takia (ja politiikan). Hieno homma. FreeBSD here I come
Vastaukset 12
Vanhimmat
"Ei taida olla paljoa merkitystä sillä kuinka hyvää koodia kirjoitat, kääntäjän laatu lopulta ratkaisee."
Ja GCC on huippuluokan kääntäjä, erittäin korkealaatuinen.
"Linux olisi pitänyt alusta alkaen kirjoittaa standardi C kielellä ja kirjoittaa kokonaan oma kääntäjä sitä varten."
Standardi C:tähän se onkin niiltä osin kuin on mahdollista. Kyseessä kun on kerneli niin siellä on rajuja matalan tason optimointeja ja optimointivivut tässäkin niitä harmeja aiheuttaa. Katso vaikka niitä vipuja siinä... Ihan standardimallisessa koodissa ei noin rajusti optimoida.
@Ja GCC on huippuluokan kääntäjä, erittäin korkealaatuinen.
Voise ollakin huippuluokan kaantaja mutta suosiosta johtuen se on paisunut kuin pullataikina ja jos luet tuosta linkista Torvaldsin vuodatuksen niin ymmarrat yskan. Eri versioissa on bugeja joita kaikissa versioissa ei ole ja on mahdotonta tietaa etukateen missa ne bugit on. Jos kaantaa silla versiolla jossa on bugit niin ne siirtyy siihen kaannettavaan ohjelmaan kuten nyt tassa tapauksessa Linux kerneliin. Torvalds valittaa sita etta hanelle sataa vikaraportteja vaikka itse LInuxin koodissa ei ole vikaa.
Taman sekoilun lisaksi GCC uusimmissa versioissa on GPLv3 lisenssi joka on niin poliittinen etta esim FreeBSD siirtyi suosiolla Clang kaantajaan. Clang on muuten alunperin Applen talon sisainen projekti, kaantaja on moninverroin nopeampi kuin GCC eika mukana tule ylimaaraista, vaikeaa politiikkaa. FreeBSDn kehittajien argumentti, ihan validi sellainen, on etta GPLv3 lisenssiehdot ovat menneet niin pitkalle ettei kyseessa ole enaa vapaa ohjelmisto. GPLv2 lisenssissa oli porsaanreika joka mahdollisti monta hyvaa asiaa, v3 lisenssissa nama on tukittu. FreeBSDn kayttama lisenssi takaa sen etta ohjelmat on aidosti vapaita, siksi FreeBSD oli pakotettu kayttamaan GCC versioita joissa oli viela v2 lisenssi, mutta ne versiot alkaa olla auttamatta liian vanhoja kaytettavaksi.
@Standardi C:tähän se onkin niiltä osin kuin on mahdollista.
Melkoisesti sidottu GCC kaantajaan. Virallista ydinta pitaa muokata melkoisesti etta sen saa kaantymaan toisella C kaantajalla. Sita varten on toki olemassa projekteja kuten LLVMLinux joka alkoi vuonna 2010 mutta kerneli ei vielakaan kaanny silla vuonna 2014 eli se kertoo jo jotain. Tarinan mukaan Intelin kaantaja pystyi kaantamaan kernelin vuonna 2004 mutta siita ei ole sen koommin kuultu mitaan uutta eli siellakin varmasti luovutettiin suosiolla.
"Voise ollakin huippuluokan kaantaja mutta suosiosta johtuen se on paisunut kuin pullataikina ja jos luet tuosta linkista Torvaldsin vuodatuksen niin ymmarrat yskan. Eri versioissa on bugeja joita kaikissa versioissa ei ole ja on mahdotonta tietaa etukateen missa ne bugit on."
Juu, mutta bugeista huolimatta, GCC:tä testataan kyllä perusteellisesti. Siinä on valtavan laajat testisarjat. Sen lisäksi ennen kuin se pääsee tuotantoympäristöön niin sitä testataan pitkään käyttöjärjestelmävalmistajan toimiesta. Ei siinä Debian stablessa, Red Hat Enterprisessä, Ubuntu LTS:ssä jne. ole se ihan tuorein versio vaan on pidempään testattu jotain versiota.
Ja Torvalds säätää kerneliä, tässä on käytössä jotain "kosmisia" optimointivipuja ja virityksiä mitä ei muualla käytetä (muualla tyyliin gcc -O2 tai -O3 tms.) eli käyttävät toimintoja joita ei ihan vakio optimointijutut vielä käytä kun ovat ns. experimental ominaisuutta vielä. Kerneliversiokin joku uudenkarhea.
Kyllähän tuossa se riski bugeille maksimoidaan tuossa.
"Melkoisesti sidottu GCC kaantajaan."
Yleensä softaprojektit sidotaan johonkin toolchainiin, normaalia. Ja koska tässä hinkataan ja optimoidaan matalalla tasolla (ASM:ia, SIMD optimointieja jne.) niin niille ei edes ole mitään standardia.
Ei vaan joku muu säätää ja Torvaldsille tulee vikaraportteja. Kun luulevat että vika on Linuxissa. Linuxin postituslistalla Torvaldsin äänensävy ei ollut ihan niin nätti kuin tuolla GCC vikaraportissa.
En ihan tarkalleen tiedä mitä "spilling" on suomeksi mutta se tarkoittaa sitä kun _muuttuja_ siirretään rekisteristä muistiin. Tässä nimenomaisessa tapauksessa GCC siirtää _vakion_ rekisteristä muistiin. Mutta ei siinä vielä kaikki..
https://lkml.org/lkml/2014/7/24/584
Tosin sitä en tiedä miksi Torvalds väittää että Debian käyttää gcc-4.9 versiota, todellisuudessa versiot ovat gcc-4.6 ja gcc-4.7
"Standardi C:tähän se onkin niiltä osin kuin on mahdollista. Kyseessä kun on kerneli niin siellä on rajuja matalan tason optimointeja ja optimointivivut tässäkin niitä harmeja aiheuttaa. Katso vaikka niitä vipuja siinä... Ihan standardimallisessa koodissa ei noin rajusti optimoida."
Windowsiahan ei taideta optimoida millään tavalla kun se käytännössä on sidottu x86 prosessoriarkkitehtuuriin? (Mitä nyt on tämä WindowsRT söhellys ARM:ille?)
Linuxdistrot ja bsdunixit toimivat "lähes kaikilla" tunnetuilla prosessoriarkkitehtuureilla joten ne vaativat enemmän optimointia vaihtelevissa käyttöympäristöissä. Käyttöjärjestelmien "siirto" eri prosessoriarkkitehtuureille ei ole aivan helppo juttu. Linux kernel alkuperäisessä asussa kirjoitettiin x86 arkkitehtuurille.
Tällä lienee oma merkityksensä.
"Windowsiahan ei taideta optimoida millään tavalla kun se käytännössä on sidottu x86 prosessoriarkkitehtuuriin?"
Ei ole. x86, x86-64 ja ARM, hyvin ovat saaneet siirrettyä. Toimiihan se Windows Phone myös ARM:lla. Aikaisemmin Windows oli siirrettynä myös PowerPC:lle siinä Xbox 360:ssä.
Jatkossa kokoajan enemmän tietokoneista menee ARM arkkitehtuurille.
Prosessoriarkkitehtuureilla on oma merkityksensä. Paljon puhutaan siitä "optimoinnista" mutta vähemmän puhutaan (tai ei juuri ollenkaan) prosessorien dokumentoimattomista osista.
Prosessorivalmistajat eivät aina ole julkaisseet aivan kaikkea avoimesti, vaan osa on jätetty "omille" sopimusosapuolille. Tämä on antanut suurille sopimusosapuolille tavallaan paremman "etulyöntiaseman" verrattuna näihin avoimen lähdekoodin tuottajiin.
Kyllä siinä on oma lisätyönsä kun käyttöjärjestelmä kirjoitetaan toiseen prosessoriarkkitehtuuriin. Aikoinaan WindowsNT kirjoitettiin myös Alpha prosessorille joka oli risc tyyppinen. Intelin x86 prosessorit ovat tyypillisiä cisc prosessoreja.
Käyttöjärjestelmissä on eroja siinä suhteessa kuinka hyvin ne "taipuvat" prosessoriarkkitehtuurin muutoksiin. Apple tietää tämän muutoksen ongelmat, kun se siirtyi 68000 perheestä Intelin x86 perheeseen Mac OS X:n käyttöönotossa. Se vanhempi MacOS ei ollut enää käyttökelpoinen.
Oma osuutensa tulee sitten ohjelmointikielten kääntäjistä eli miten hyvin ne kääntävät ohjelmia toisessa prosessoriarkkitehtuurissa. Näissä C/C kielen kääntäjissäkin on eroja, useimmat näistä toimii parhaiten juuri x86 arkkitehtuurissa. Jotkin kääntäjät eivät vielä huomioi uusimpia C kieleen tehtyjä muutoksia. Näin se vaan on ja tämän mukaan on toimittava eli se kääntäjäkin on joskus valittava tarkemmin. Ja oman lisäongelmansa tuottavat ne jotka kääntävät ohjelmointikieltä toisesta toiseen, itse olen kokeillut kääntäjää joka suorittaa muunnoksen pascalista c-kieleen. Lähdekoodi kirjoitetaan pascalilla ja ohjelma suorittaa sen kääntämisen c-kieliseksi. Voitte arvata: tuottaako tämä täydellisesti optimoitua koodia?
Samoin olen kokeillut kääntäjää joka kääntää fortrania c-kielíseksi.
Kannattaa suorittaa tälläisiäkin kokeiluja kääntäjillä ainakin oppimismielessä, ainakin kääntäjien erot tulee ilmeisiksi. Kääntäjän valinnalla on oma merkityksensä joka on syytä huomioida.
"Kyllä siinä on oma lisätyönsä kun käyttöjärjestelmä kirjoitetaan toiseen prosessoriarkkitehtuuriin."
Itseasiassa ei.. Normaalisti käännetään vaan koodi uusiksi. Tietysti jos jotain osia on tehty assemblerilla optimoiden niin ne optimoidut versiot ei suoraan mene vaan jää se kääntäjän tekemä versio. Jossain hyvin matalan tason jutuissa voi joutua säätämään uusiksi.
Suurin työ tehdään kääntäjässä, että se tuottaa toiselle arkkitehtuurille optimoitua koodia.
"Lähdekoodi kirjoitetaan pascalilla ja ohjelma suorittaa sen kääntämisen c-kieliseksi. Voitte arvata: tuottaako tämä täydellisesti optimoitua koodia?"
Ei, koodi kirjoitetaan tietysti uusiksi C:llä (tai jos kyse on sovelluksesta niin ennemmin joku oliokieli, C on systeemitasonohjelmointia) ja se käännetään sitten kääntäjällä. Pascal oli legacyviritys, kova juttu silloin 80-luvulla kun oli turbo pascal. Sen jälkeen sitä käytti lähinnä Delphi.
No käyttöjärjestelmä on kylläkin vähän eri asia kuin tavallinen ohjelma. Linux esimerkiksi on kirjoitettu osin C-kielellä, osin assemblyllä, joten ne tiedostot jotka on asmia joudutaan kylläkin kirjoittamaan uusiksi. Jos lataat Linuxin sorsat niin näet että siellä on jo vaikka kuinka monelle arkkitehtuurille kirjoitettu ne tiedostot, eli kun käännetään Linux jollekin tuetulle arkkitehtuurille niin ne tiedostot ovat siellä puussa jo olemassa. Konfigurointivaiheessa tehdään sitten ne valinnat mitä tiedostoja kääntäjä huomioi ja millä asetuksilla. Linuxissa on skripti tälle, en muista nimeä mutta tältä se näyttää
http://static.howtoforge.com/images/kernel_compilation_ubuntu/1.png
Ei ole kyse prosessoriarkkitehtuurista tässä tapauksessa. Vian on raportoinut yksi Linux ytimen kehittäjistä (grafiikkapuolelta) joka oli kääntänyt ydintä x86-64 arkkitehtuurille. Seuraava kohta valottaa asiaa ehkä
We do *not* follow the
x86-64 ABI wrt redzoning, because we *cannot*: interrupts while in
kernel mode *will* use the stack without a redzone. So that
"-mno-red-zone" is not some "optional guideline". It's a hard and
harsh requirement for the kernel, and gcc-4.9 is a buggy piece of shit
for ignoring it.
-mno-red-zone vipu tässä tapauksessa on vaatimus eikä ns. optimointia. GCC-kääntäjä jättää sen tylysti huomioimatta.
http://en.wikipedia.org/wiki/Red_zone_(computing)
Täällä lisää (vuodelta 2009)
http://forum.osdev.org/viewtopic.php?t=21720
Tähänkö se kaatuu?
Kyllä, se kaatuu osaamattomuuteen. Java kultti on vienyt monen ohjelmoijan taidot ja sitten ei enää osata C/C kieltä riittävästi. Monet eivät enää osaa edes valita sopivaa C/C kääntäjää.
Näitä kääntäjiä on useampia eikä kaikki tarvitse Microsoftin kääntäjää. (ei se huono ole, mutta se on viritelty Windows ohjelmointiin).
C/C kieli on vaan sellainen mikä on. Sen hallinta ei ole aivan yksinkertaista koska se vaatii ohjelmoijalta paljon. Ja kun työssä painaa päälle tietyt aikataulut niin heikompi ohjelmoija on pulassa "valmista pitää tulla mutta aikaa ei ole tarkistuksiin". Unohtamatta niitä jatkuvia yt-neuvottleujen riskiä.
Tässä varsinaisesti ei ole mistään tuollaisesta kyse vaan siitä että eräs Linuxin kehittäjä (grafiikkapuoli) luuli että Linuxin koodissa on vikaa. Tämä johtuu siitä että hänen kääntämänsä kernel aiheuttaa random oops/panic tilanteita jotka normaalisti ovat viallisen koodin lieveilmiöitä. Vika ei nyt kuitenkaan ole Linuxin koodissa vaan siinä mitä GCC-kääntäjä sillä tekee. GCC-kääntäjähän ei ole kaupallinen tuote ja sitä kehitetään vapaaehtoisten voimin kaikessa rauhassa, mitään paineita uusiin julkaisuihin ei ole. Varmasti ovat myös pätevää porukkaa. Mielenkiintoista nähdä mistä tämä vika johtuu ja miten tuohon on tultu.