KESKUSTELU

Se "turha tieto" on kuitenkin homman varsinainen pihvi, jota ilman on turha haaveilla tavallisen koodarikulin hommia hohdokkaammista tehtävistä - ellei sitten ole todellakin superluokan virtuoosi - joita on ehkä yksi 1000 ylisuurella egolla varustettua pikkunörttiä kohden.

Ehkä monella on jokin harhakuva, että korkeakouluissa olisi tarkoitus opetella "koodamista" ja että valmistuttua työ olisi puhdasta koodamista aamusta iltaan. Tärkein oppi piilee kuitenkin aivan muissa aiheissa, kuten vaatimusmäärittelyissä, ohjelmistoarkkitehtuurien suunnittelussa, projektihallinnassa, muutosten- ja julkaisujen hallinnassa, ohjelmiston elikaarissa jne. jne.

Jos tuollainen kuulostaa tylsältä ja haluaa vain koodata, niin sitten oikeampi oppilaitos olisi varmaankin joku ammattikorkeakoulu.

Kerropa nyt mille prosessorille olet koodannut FFTn ja minkä kääntäjän suhteen teit vertailut.

Mitä kääntäjien optimointeihin tulee, niin hyvät kääntäjät ovat jo vuosikausia osanneet tarvittaessa "inlinetä" funktiot tai laventaa loopit, jos sillä saavutetaan nopeusetua.

Vastaavasti modernit prosessorit ovat sisäisesti sen verran kompleksisia, että konekielinen käsinoptimointi aiheuttaa helposti liukuhihnojen jumittumisen ja rinnakkaisten yksiköiden tyhjäkäynnin. Muistaakseni jossain tapauksessa kääntäjän koodiin tiukkaan laskentalooppiin laittaman NOP:n (no operation) poistaminen hidasti koodia.

Kyllä onnistuu, on onnistunut jo tovin. Siis nykyaikaiselle DSP-prosessorille tehdylle C-kääntäjälle. Tuollainen tilanne on ollut vanhempien prossujen kanssa, mutta niin kuin kse sanoi, nykyaikaisten DSP:iden kanssa saa olla melko pohjamutiaan myöten perehtynyt prossun arkkitehtuuriin, että pääsee edes C-kääntäjän tasolle koodin tehossa.

Sama muuten koskee yhä enenevissä määrin "tavallisia" PC-prosessoreita, sitä luulee tekevänsä optimoitua assy-koodia ja nauraa kääntäjän tekemälle "törylle", kunnes huomaa, että oma optimoitu assy-koodi aiheuttaa niin karmeita pipeline stalleja, yksiköiden tyhjäkäyntiä ja vastaavia, että se on 10 kertaa kääntäjän tekemää "sekavaa törkyä" hitaampi



Niin tunnen itsekin. Työnantajalle tuollainen kaveri on aina vähän "riskisijoitus", koska jotkut syyt kouluja käymättömyyteen ovat sellaisia, että ne tekevät kaverista kehnon työntekijän. Ehdottomasti siis kannattaa hankkia tutkinto.



Olen aivan samaa mieltä.

Mielenkiintoinen ajatus: Kääntäjä osaa paremmin työnsä kuin tekijänsä.

Tietääkseni ohjelman suoritusaika riippuu koodin määrästä, ei siitä, miten koodi on kehitetty, eikä siitä minkälaisia pipe- tai muita linejä tieto virtaa prosessorissa. Muuten voisi käydä niin, että ohjelman suoritusnopeus ei riippuisi koodin määrästä, tai olisi peräti pienempi, jos koodin määrä olisi suurempi.

Tosiasia nyt kuitenkin on, että kääntäjä ei pääse samaan kuin asiansa osaava koodaaja. Muuten kävisi niin, että koodaaja etsisi kääntäjän suorituksesta virheen (tietääkseni mikään kääntäjä ei osaa täydellistä optimointia), korjaisi kääntäjän, kääntäjä jälleen kääntäisi paremmin kuin koodaaja jne. ad infinitum. Selvä ikiliikkuja.

Eipä taida nykymaailma olla enää näin suoraviivainen...

Esimerkkinä vaikkapa käteismuistin esihaut (jurionreille suomennettakoon: cache prefetch), joita prossu tekee samalla siinä sivussa, kunhan vain sopivassa välissä joku muistaa moista operaatiota pyytää tehtäväksi. Kääntäjä osaa aika hyvin, käsipelin asmeissa saattaa mennä äkkiseltään pieleen.

Yksinkertainen esimerkki: tee pistetulo käsin asmilla ja vertaa C-kääntäjän tulokseen. Kumpi on nopampi?

Taitaapa edelleen olla tuo maailma noin lineaarinen. Jos teet käsin saman kuin C-kääntäjä, niin tulos on aivan sama.

Jos joku on C-kääntäjän tehnyt, niin joku toinen pystyy tekemään sen vielä paremmin. Jos näin ei olisi, niin oltaisiin samassa tilanteessa kuin aikaisemmin, eikä mitään edistystä tapahtuisi.

Joku varhainen gcc on todella kaukana nykyisistä, mutta ei tuo sitä osoita, että konekäännökset olisivat nykyään jotenkin täydellisiä.

Yksinkertaisesti: Käsin pääsee samaan tai parempaan kuin konekääntäjällä. Jos näin ei olisi, niin kone olisi etevämpi kuin rakentajansa. Esitä koneen käännös, niin joku siitä kuitenkin pystyy viilaamaan tavun pois, ellei kyseessä ole joku antiikkinen triviaali mov ah,4C int 21. Tuotakaan en ole koskaan nähnyt minkään kääntäjän tarjoavan semmoisenaan.

Kääntäjien tekijät käyttävät tuhottomasti aikaa ymmärtääkseen arkkitehtuurin ja monet DSP-kääntäjät purkavat C-koodin ensin atomeiksi, ennen kuin alkavat kehittää siitä konekoodia. Usein kehitysvaiheessa ei C-kääntäjässä pidetä kaikkia optimointeja päällä, koska muuten tuloksena on koodia, jota on hankala debugata source-tasolla, koska operaatiot on limitetty.



Kuten mal tuossa sanoi, asia ei ole aivan näin yksinkertainen. Perusperiaate on tietysti se, että pipeline stallit ovat nolla ja kaikki rinnakkaiset yksiköt 100% kuormitettuna (onneksi kääntäjät osaavat usein kertoa, kuinka tehokkaasti ne pystyivät pipelineä ja yksiköitä käyttämään looppeja rakentaessaan).

Huonosti valitut peräkkäiset käskyt saattavat aiheuttaa näkymätöntä latenssia (pipelinestä) ja jotta niistä päästäisiin eroon, joudutaan organisoimaan operaatiot uudestaan, silläkin uhalla, että käskyjen määrä kasvaa. Rinnakkaisilla yksiköillä on usein jokaisella omat rekisterinsä ja DSP pystyy yhden kellojakson aikana siirtämään vain tietyn määrän tietoa yksiköiden välissä, joten organisoimalla rekisterien käyttö oikein vältytään ylimääräisiltä latensseilta.



Näin todellakin voi käydä.



Käytännössä kääntäjää parempaan tulokseen pääseminen vaatii pitkällisen tutustumisen & harjoittelun, ja yleensä jossain tietyssä ongelma-alueessa (esim. FFT ja sen kaltaiset; usein kuitenkin kirjastojen mukana tulee kelvolliset implementaatiot perusalgoritmeista ko. prosessorimallille) ja tietyllä prosessorimallilla, ja aina koodia muutettaessa joudutaan tuhraamaan aikaa assembler-koodin ylläpitoon.

Jos pakottavaa tarvetta ei ole, niin tuskin kannattaa lähteä assemblerilla vääntämään - jos on eikä sellaista ole aiemmin tehty, niin kannattaa varautua pitkään learning curveen (ja käyttää kääntäjien tuottamaa koodia pohjana), ennen kuin koodari alkaa saada looppinsa optimoitua kääntäjää paremmin. Jos se on hintansa arvoista, niin sitten se kannattaa tehdä.

Ei nyky-DSP:n ohjelmointi assemblerilla tietenkään mahdotonta ihmiskoodarille ole, mutta se ei ole kyllä todellakaan niin suoraviivaista kuin vanhemmilla prosessorisukupolvilla. Joutuu heittämään romukoppaan yhden jos toisenkin vanhoista peukalosäännöistä...

Itselläni siis kokemusta TI:n DSP-sarjoista, mm. C6400 -sarjasta:

http://focus.ti.com/docs/prod/folders/p ... c6416.html

Datasheet: http://focus.ti.com/lit/ds/symlink/tms320c6416.pdf

Toki. Omalta kohdaltani voin kuitenkin suosiolla todeta, että henkinen kapasiteettini tai (työnantajan) kärsivällisyys ei moiseen riitä. Vähän sama kuin yrittäisi voittaa konetta shakissa.

On totta että ei kannata työnantajalle ruveta jotain yksittäistä suodatinta lähteä vääntämään assemblerilla, jos sen saa kaupasta sellaisenaan tai ainakin kehityslaitteiston. En vain oikein ymmärrä, miten valmiin ohjelman ostaminen tai parametrien syöttäminen valmiiseen systeemiin liittyy ohjelmointiin tai sen opiskeluun.

Vähän niinkuin ostaisi valmiin matopelin tai Otellon tai shakkipelin sen sijaan, että perehtyisi asiaan syvällisemmin.

??? Siis tottahan C-koodaaminen on koodaamista, ja tottahan valmiita kirjastoja kannattaa koodauksessa hyödyntää. Itse asiassa, iso osa koodaajan käytännön ammattitaitoa on se, että tietää, mitä kaikkea esimerkiksi kääntäjien tai talon sisällä kehitettyjen kirjastojen kätköistä löytyy ja miten niitä käytetään ja missä.

Muistutan nyt kuitenkin tässä vaiheessa, mistä tämä keskustelu lähti liikkeelle:

Eihän kyse ole paremmin tai huonommin tekemisestä vaan monimutkaisen optimointitehtävän automatisoinnista. Ihminen pystyy pitämään työmuistissaan vain pari asiaa kerrallaan ja kun homma menee monimutkaisemmaksi, niin sitten tarvitaan kynää, paperia ja paljon kahvia.

Mietipä vähän vaikka niinkin yksinkertaista prosessoria, jossa on 1 liukulukuyksikkö ja 2 kokonaislukuyksikköä, joiden liukuhihnojen syvyydet ovat vaikkapa 5 ja 3. Käytännössä sinun pitäisi jatkuvasti miettiä konekielistä koodiasi 1*5+2*3=11 käskyn liukuvassa ikkunassa - varmistua siitä, ettei yksikään käsky esiintyessään muun 10 kanssa jumiuta liukuhihnoja vaan jokainen yksikkö pyörii katkoitta täysillä.

Onnistuisiko?

Kannattaa myös muistaa, että noin yksinkertaisia prosessoreita oli joskus 10 vuotta sitten ja nykyiset yleiskäyttöiset prosessorit ovat monin verroin monimutkaisempia eli suoritusyksiköitä on enemmän ja mukaan on tullut mal:n mainitseman käteismuistin esihakujen lisäksi hyppyjen spekulativiinen ennustaminen (speculative branch prediction), jossa prosessori ei jää odottamaan hyppyyn vaikuttavan ehdon laskemista vaan arvaa mikä haara hypyssä valitaan, hakee ko. käskyt etukäteen ja alkaa suorittamaan niitä niin pitkälle kuin kerkiää.

Kaikkiin näihin esihakuihin ja spekulaatioihin voidaan vaikuttaa käytetyillä komennoilla (muistaakseni joissain arkkitehtuureissa on jokaisesta hyppykäskystä kaksi versiota - toinen ilmaisee prosessorille, että hyppy on todennäköisempi kuin ei-hyppy, ja toinen päinvastoin). Kääntäjä osaa näissäkin tapauksissa yleensä opitimoida (jos ei muuten niin profiloinnin avulla) käytetyt käskyt.

Onnistuisiko sama lyijykynällä norttiaskin kanteen?



Kerropa sitten miksi yhdessä prosessorissa (MIPS, Sparc? ei jaksa muistaa) kääntäjän generoiman NOP:n poistaminen kasvatti suoritusaikaa? Eihän NOP-komento tee yhtään mitään?

Joskus tuli törmättyä C80-sarjan prossuun ja kun selvisi, että siinä on 8 kpl VLIW (aikasmoisen pitkä käskysana) -prosessoreja kytkettynä toisiinsa ristikytkimellä, niin totesin suosiolla, että tätä ei sitten enää käsin ohjelmoidakaan.

Olikos se niin, että jokaisessa VLIW-ytimessä oli 5-6 yksikköä, joista jokainen suoritti oman siivunsa yhdestä käskysanasta? Eli yhdellä kellojaksolla piti huolehtia 40-48 suoritusyksikön optimaalisesta ruokkimisesta?

C80:stä:



C80:een en ole törmännyt, Wikipedia väittää niiden olevan "multiprocessor chippejä":

http://en.wikipedia.org/wiki/Texas_Instruments_TMS320

Tuossa C6400-sarjassa DSP-coressa on 2 funktioyksikköä (A ja B) ja ne molemmat suorittavat 4 käskyä yhtä aikaa eli yhteensä suoritetaan 8 kpl 32-bittistä käskyä kellojaksossa (VLIW-käsky siis 256-bittiä) ja max. 28 operaatiota kellojaksossa (yksi käsky voi sisältää useamman operaation).

Se, mikä homman tekee kiharaiseksi, on se, että yksiköt eivät ole aivan identtisiä (eli jotkut käskyt voi suorittaa vain tietyillä yksiköillä, esim. D-yksiköt (.D1 ja .D2) aksessoivat muistia ja M-yksiköt tekevät kertolaskuja) eikä rekistereiden sisältöjen siirto yksiköiden välillä ole aivan yksioikoista. Siinä kuluu kahvia ja tupakkaa, kun järjestelee käskyjä ja rekistereitä [luku/kirjoitus] niin, että yksiköt pysyvät mahdollisimman hyvin kuormitettuina

Mutta kuten sanottu, kääntäjä pelaa ihan hyvin ja komentoriviparametrilla sen saa kertomaan assembler-filen kommenteissa, kuinka hyvin se mielestään onnistui käännöksessä; siitä on sitten hyvä lähteä liikkeelle, yleensä ensin C-koodia muokkaamalla prossulle paremmin sopivaksi.

Lainaus:
"Kerropa sitten miksi yhdessä prosessorissa (MIPS, Sparc? ei jaksa muistaa) kääntäjän generoiman NOP:n poistaminen kasvatti suoritusaikaa? Eihän NOP-komento tee yhtään mitään?"


Minä tiedän mielestäni varsin mainiosti, mikä on kääntäjän merkitys lähdekoodin käsittelyssä ja käsittelyn automatisoinnissa.

Oli prosessi monimutkainen tai ei, niin joku kuitenkin pystyy asian tekemään myöhemmin paremmin, jos siltä tuntuu. Tavalla tai toisella.

Jonkin liukuluku- tai muun sellaisen yksikön olemassaolo ei ole mitenkään olennainen asia tietokoneessa. Sellainen voi olla olemassa tai voi aivan hyvin olla olemattakin.

Taivutetaan nyt rautalangasta:
Olisi todella outoa tökätä ekaluokkalaiselle funktiolaskin tai läppäri kouraan, ja sanoa, että tuolla pärjäät hyvin koko lopun elämäsi. Vaikka sinä kuinka hyvin tuntisit ziljoonan prosessorin ytimen rakenteen, niin ei se muuta muuksi tosiasiaa, että jos joku haluaa aloitaa ohjelmointiharjoittelun, niin hän on ekalla luokalla.

Muistan kyllä, että joissain AMD:n varhaisissa malleissa oli ongelma, jonka saattoi korjata NOP:illa, kun matikka- tms. prosessori toimi eri tahdissa kuin muu kone. Tuo ei kuitenkaan ole mikään poikkeus, joka kumoaa tai vahvistaa säännön. Pistä 1E6 NOP-käskyä silmukkaan ja pyöritä silmukkaa i kertaa. Listaa i:n funktiona suoritusaika, niin kyllä siitä jotain valkenee. Prosessorista riippuen tuon NOP:in käsittely vie yleensä 1...n kellojaksoa.

Pitipä sitten oikein kaivaa netistä datalehti esiin...

Muistinkin väärin: prosussa oli vain 4 (tai halppisversiossa 2) signaalinkäsittelycorea ja systeemiä ohjaamassa erillinen RISC-prosessori samalla sirulla.

Äkkipäätä muistia virkistäessä näyttäisi siltä, että nuo DSP-coret syövät 64-bitin käskysanoja, joilla ohjataan kertolasku-, ALU-, muistiosoitus- ja ohjelmakontroliyksiköitä. Noista ALU oli splitattava eli se pystyi laskemaan saman aikaisesti Nx8bit, N/2x16bit tms. komennot (olisiko N=8?), muistinosoitusyksikkö pystyi laskemaan samanaikaisesti osoitinoperaatiot sekä ulkoiseen että sisäiseen muistiin ja kontrolliyksikössä oli useampia looppilaskureita ja hyppykontrollereita.

C80 oli aikanaan aika oiva mm. kuvankäsittelyssä eli konvoluutiot, FFTt ja sen semmoiset sujuivat ihan kelvollisen sutjakkaasti.