Seuraa 
Viestejä45973

Nyt kun yhä enenevässä määrin tietokonekauppiaat myyvät dual core prosessorilla varustetttuja tietokoneita, niin onkin pulpahtanut pintaan se, että kuinka dual core koneen prosessori(t) työstää ajettavaa koodia entiseen yksi-ytimiseen prosessoriin verrattuna.

I
Että, mitä tämä tuplaydin prosessori on tuonut sellaista mukanaan, että sellaista ei ole voitu toteuttaa yksiytimisellä prosessorilla.

II
Mitenkäs oikean ohjelmoijan maailma on muuttunut tämän tuplaytimen myötä, että pitääkö oikein ruveta säikeitä suosimaan, jotta saisi uudesta prosessoristaan irti kaikki hyödyt.

Olisiko palstalaisilla tietoa asiasta ja kenties laittaa linkkiä missä käsiteltäisiin uuden tuplaytimen tuomia haasteita ohjelmoijan taikka käyttiksen näkökulmasta katsoen. Itse puolestani olen harrastajaohjelmoija mallia 1956 ja olen vältellyt säikeitä viimeiseen asti.

Kuis on?

Sivut

Kommentit (35)

Posix säikeet ovat tuttuja ja niistä lyhyesti. Yksi prosessi voi sisältää useita säikeitä joilla voit ajaa samaa koodia omassa säikeessään. Säikeet käyttävät prosessin datasegmenttiä ja jokaisella säikeellä on oma pino.

Säikeiden käyttö on multocore ympäristössä tehokasta ja dedicated L2 cache tuo oman lisänsä vielä tähän.

http://www.digit-life.com/articles2/cpu ... cache.html

Säikeitä kannattaa käyttää koska tulevaisuuden kaikki tehokkaat prosessorit ovat multicore prosessoreja. Realtime systeemejä ohjelmoivalle tekijälle multicorealustat ovat todellinen haaste ja homma saattaa mennä vaikeaksi, toteutuksesta tietysti riippuen.

Edit: Itse olen havainnut hyväksi tilailla käytettyjä kirjoja amazonin kautta.

Säikeiden kanssa joutuu myös pelehtimään mutexien, semaphorien yms. lukitusmekanismien kanssa joten uutta omaksuttavaa on jonkun verran. I

Siitäpä vain säikeilemään. Tuo vähän uutta potkua ohjelmointiin.

Jos posixi säikeet kiinnostaa niin tässä on alan yksi raamattu:
http://www.amazon.com/Programming-Threa ... 0201633922

Seppo_Pietikainen
Seuraa 
Viestejä7615
konna
Posix säikeet ovat tuttuja ja niistä lyhyesti. Yksi prosessi voi sisältää useita säikeitä joilla voit ajaa samaa koodia omassa säikeessään. Säikeet käyttävät prosessin datasegmenttiä ja jokaisella säikeellä on oma pino.

Säikeiden käyttö on multocore ympäristössä tehokasta ja dedicated L2 cache tuo oman lisänsä vielä tähän.

http://www.digit-life.com/articles2/cpu ... cache.html

Säikeitä kannattaa käyttää koska tulevaisuuden kaikki tehokkaat prosessorit ovat multicore prosessoreja. Realtime systeemejä ohjelmoivalle tekijälle multicorealustat ovat todellinen haaste ja homma saattaa mennä vaikeaksi, toteutuksesta tietysti riippuen.

Edit: Itse olen havainnut hyväksi tilailla käytettyjä kirjoja amazonin kautta.

Säikeiden kanssa joutuu myös pelehtimään mutexien, semaphorien yms. lukitusmekanismien kanssa joten uutta omaksuttavaa on jonkun verran. I

Siitäpä vain säikeilemään. Tuo vähän uutta potkua ohjelmointiin.

Jos posixi säikeet kiinnostaa niin tässä on alan yksi raamattu:
http://www.amazon.com/Programming-Threa ... 0201633922





Kannattaa muuten pitää mielessä, että säijeohjelmointi ja siihen liittyvät muut konseptit, kuten mutexit, ehtomuuttujat ja Read/Write lukot eivät välttämättä ole kovin yksinkertaisia ja aiheuttavat sangen mielenkiintoisia ongelmia, erityisesti debuggauksen kannalta ja muutenkin järjestelmän käyttäytymisen ennustettavuus on aivan eri luokkaa...

On syytä pitäytyä posix-standardeissa ja kääntäjäliput saavat
aivan omat merkityksensä, eikä säikeistettyjä ja ei-säikeistettyjä kirjastoja sovi sekoittaa yhdeksi sotkuksi...

Toinenkin asia, mikä on syytä pitää mielessä on se, että aito SMP -ympäristö käyttäyttyy *aivan* eri tavalla kuin yhden prosessorin järjestelmä, vaikka kuinka pähkälisi ja debuggaisi...

Säikeistettya sovellusta aidossa SMP-ympäristössä on erittäin
vaikeaa debugata...

--
Seppo P.
Kreationismi perustuu tietämättömyyteen, se sikiää tietämättömyydestä ja siitä sikiää tietämättömyyttä. Tietämättömyyden levittäminen on kreationismin elinehto ja tietämättömyydessä rypeminen on kreationistin luonnollinen elämisenmuoto

Sisältö jatkuu mainoksen alla
Sisältö jatkuu mainoksen alla

konna kirjoitti :
Säikeitä kannattaa käyttää koska tulevaisuuden kaikki tehokkaat prosessorit ovat multicore prosessoreja.

sitten Seppo_Pietikainen kirjoittaa :

Kannattaa muuten pitää mielessä, että säijeohjelmointi ja siihen liittyvät muut konseptit, kuten mutexit, ehtomuuttujat ja Read/Write lukot eivät välttämättä ole kovin yksinkertaisia ja aiheuttavat sangen mielenkiintoisia ongelmia, erityisesti debuggauksen kannalta ja muutenkin järjestelmän käyttäytymisen ennustettavuus on aivan eri luokkaa... kirjoitti :

Joo. Niinkuin tuossa aloitustekstissäni yritin tuoda julki, että onko ohjelmoijan maailma muuttunut helpommaksi kun näitä monicoreprosessoreita on ryhdytty työntämään maailmaalle, että alkaako tosiaan ohjelmoijan maailma ja työ käymään tosi vaikeaksi ja ennalta arvaamattomaksi näiden uusien tekniikoiden myötä.

Että, ei kait sitten maailma ole tullut helpommaksi ohjelmoijaraukan kannalta kuin kaiketi siltä osin, että tohtorin tasoiset ovatkin tulevaisuudessa ne jotka ovat kykeneviä tuottamaan koodia uusille
prosessoreille ja systeemeille.

Tähän lopuksi vaan, että kun itse aikoinani tein ohjelmia yksisäikeisinä prosessiteollisuuteen, niin kyllä se oli niin, että taimerilla hommat hoidettiin eikä säikeillä. ! ja ?

Jahka sitten tulevaisuudessa olisi niin, että taskit ja virheenkäsittely olisi toisistaan niin hyvin eristetyt, että normaalikoodaajakin voisi tuottaa sellaista koodia, että eipä tässä ja nyt väliä virheenkäsittelystä, vaan lähetetäänpä virhetapaus toiseen "prosessiin" ja sieltä takaisin
paluuna breikkaus varsinaiseen ohjelman kulkuun.

Nyt meni jo yli papan osaamisen, mutta näin tässä.

Seppo_Pietikainen
konna
Posix säikee.. blaa blaa blaa.



Kannattaa muuten pitää mielessä, että säijeohjelmointi ja siihen liittyvät muut konseptit, kuten mutexit, ehtomuuttujat ja Read/Write lukot eivät välttämättä ole kovin yksinkertaisia ja aiheuttavat sangen mielenkiintoisia ongelmia, erityisesti debuggauksen kannalta ja muutenkin järjestelmän käyttäytymisen ennustettavuus on aivan eri luokkaa...

On syytä pitäytyä posix-standardeissa ja kääntäjäliput saavat
aivan omat merkityksensä, eikä säikeistettyjä ja ei-säikeistettyjä kirjastoja sovi sekoittaa yhdeksi sotkuksi...

Toinenkin asia, mikä on syytä pitää mielessä on se, että aito SMP -ympäristö käyttäyttyy *aivan* eri tavalla kuin yhden prosessorin järjestelmä, vaikka kuinka pähkälisi ja debuggaisi...

Säikeistettya sovellusta aidossa SMP-ympäristössä on erittäin
vaikeaa debugata...




Näimpä on. Suurin osa posix kirjaistoista on thread safe enkä äkkiseltään keksi yhtään joka ei olisi. Windows maailmasta ei olekokemusta, vaikka onhan sekin posix yhteensopiva. Gdb oikeilla kääntäjän parametreillä höystettynä tarjoaa aika hienon työkalun debuggaukseen joten sitä suosittelen käytettäväksi.

Juuri tähän SMP ympäristön käyttäytymiseen viittasin tuolla realtime systeemien ohjelmoinnilla jonka hanskaaminen asettaa aivan erilaiset vaatimukset ohjelmoijalle. Tietokanta yms. tiedostosovelluksissa järjestelmään saa aika helposti yllättäviä pullonkauloja aikaiseksi joten niitä on syytä miettiä tarkkaan.

turnabull

Joo. Niinkuin tuossa aloitustekstissäni yritin tuoda julki, että onko ohjelmoijan maailma muuttunut helpommaksi kun näitä monicoreprosessoreita on ryhdytty työntämään maailmaalle, että alkaako tosiaan ohjelmoijan maailma ja työ käymään tosi vaikeaksi ja ennalta arvaamattomaksi näiden uusien tekniikoiden myötä.

Että, ei kait sitten maailma ole tullut helpommaksi ohjelmoijaraukan kannalta kuin kaiketi siltä osin, että tohtorin tasoiset ovatkin tulevaisuudessa ne jotka ovat kykeneviä tuottamaan koodia uusille
prosessoreille ja systeemeille.

Tähän lopuksi vaan, että kun itse aikoinani tein ohjelmia yksisäikeisinä prosessiteollisuuteen, niin kyllä se oli niin, että taimerilla hommat hoidettiin eikä säikeillä. ! ja ?

Jahka sitten tulevaisuudessa olisi niin, että taskit ja virheenkäsittely olisi toisistaan niin hyvin eristetyt, että normaalikoodaajakin voisi tuottaa sellaista koodia, että eipä tässä ja nyt väliä virheenkäsittelystä, vaan lähetetäänpä virhetapaus toiseen "prosessiin" ja sieltä takaisin
paluuna breikkaus varsinaiseen ohjelman kulkuun.

Nyt meni jo yli papan osaamisen, mutta näin tässä.




Siinä mielessä koodajan työ on helpompaa että kirjastoja ja niihin dokumentaatiota on valtavasti saatavilla ja sellaista ongelmaa on vaikea koodata jota ei joku olisi jo jollakin palstalla käsitellyt. Lisäksi muistia ja cpu:ta on paljon. Suunnittelutyökalut ja kuvauskielet ovat myös kehittyneet huimasti.

Kaksiteräinen miekka Koodaajan työ on ja ei ole helpottunut.

Toisaalta koodaus on vaikeampaa systeemien tullessa monimutkaisemmiksi ( vaikea sana ).

Riippuu siis ihan siitä mitä teet.

Edit: Ehkä tuota ensimmäistä kommenttiani "säikeitä kannattaa käyttää" voisi tulkita siten että niihin kannattaa tutustua koska sinnepäin mennään.
edit: paljon möhellystä.

Mitä vaikeaa multicore-ohjelmoinnissa tai debuggauksessa on ?

Jos jakaa riippumattomat tehtävät eri coreille, niin niiden ei tarvitse keskustella keskenään. Pelissä esim fysiikka, äänet, grafiikka ja ryhmä "muut".

Toinen asia on että eri coret ei saa käyttää jaettuja resursseja. Muisti on mahdollista varata etukäteen, verkkokortteja voi olla useita, samoin kovalevyjä. Mutta esim pelissä levyä ei käytetä ollenkaan, ja verkkoliikenteen voi hoitaa yksi core keskitetysti.

turnabull
I
Että, mitä tämä tuplaydin prosessori on tuonut sellaista mukanaan, että sellaista ei ole voitu toteuttaa yksiytimisellä prosessorilla.



Ensiksi huomautan, että kannattaa melkein puhua modiydinprosessoreista, koska suunta on kuitenkin se, että ytimiä on tulevaisuudessa (ja jo nykyäänkin) enemmän kuin kaksi. Ollaan puhuttu ainakin sadoista ytimistä.

Lyhyesti sanottuna kyse on lisätehon saamisesta koneisiin. Sama homma ollaan voitu hoituu yhdelläkin ytimellä, mutta hitaammin, mikäli kyseessä on laskentatehoa vaativa ohjelma, missä laskentaa voi tehdä rinnakkaisesti useammassa eri ytimessä.

II
Mitenkäs oikean ohjelmoijan maailma on muuttunut tämän tuplaytimen myötä, että pitääkö oikein ruveta säikeitä suosimaan, jotta saisi uudesta prosessoristaan irti kaikki hyödyt.



Ei välttämättä. Useasta ytimestä saa säikeistyksellä hyötyä vain jos ohjelman tarvitsee (tai jos se voi) suorittaa rinnakkaisesti laskentaa. Tämä ei ole aina mahdollista ja joissain ohjelmissa ei ole juuri yhtään laskentaa. Joten näissä tapauksissa useasta ytimestä ei ole mitään hyötyä.

Käytännössä kuitenkin usean ytimen käytöstä on usein hyötyä. Helpoin esimerkki on palvelinsovellus. Esimerkiksi webbipalvelin, sähköpostipalvelin tai ssh-palvelin, mikä palvelee mahdollisimman monta asiakasta samanaikaisesti. Tässä tapauksessa on usein helpointa jakaa kukin pyyntö omaksi säikeekseen. Etenkin ssh:n yli tapahtuva tiedostonsiirto vaatii paljon laskentatehoa, joten siinä säikeistys pääsee loistamaan.

Tärkeintä on ymmärtää missä tehtävissä säikeistyksestä olisi hyötyä ja milloin siitä voisi olla jopa haittaa.

Olisiko palstalaisilla tietoa asiasta ja kenties laittaa linkkiä missä käsiteltäisiin uuden tuplaytimen tuomia haasteita ohjelmoijan taikka käyttiksen näkökulmasta katsoen. Itse puolestani olen harrastajaohjelmoija mallia 1956 ja olen vältellyt säikeitä viimeiseen asti.



Yleisimmät ongelmat:
- Tiedon jakaminen säikeiden kesken, mikä aiheuttaa ongelmia mm.:
-- Datan korruptoituminen (toinen kirjoittaa samalla kun toinen yrittää vielä lukea edellistä tekstiä)
-- Deadlockit (kuvittele että sinun ja kaverisi välillä on ovi, mutta kumpikaan teistä ei saa ovea auki, koska kiskotte sitä eri suuntiin)
-- Livelockit (kuvittele että kohtaat kaverisi kadulla ja yrität väistää, mutta kaverisi tekee samoin ja olette taas nenät vastakkain. Uudet väistöliikkeet johtavat aina samaan lopputulokseen)
-- Starvation (Olette ravintolassa syömässä kaverisi kanssa, mutta aterimia on vain yhdelle. Kaverisi pääsee syömään, mutta sinä et koskaan saa syödä.)

jne.

Lektu-Elli
Mitä vaikeaa multicore-ohjelmoinnissa tai debuggauksessa on ?



Tiedon jakaminen säikeiden kesken, mikä pakottaa erilaisten lukkojen käytön. Ja tästä seuraa taas ongelmia lukitusten ajoitusten kanssa.

Jos jakaa riippumattomat tehtävät eri coreille, niin niiden ei tarvitse keskustella keskenään. Pelissä esim fysiikka, äänet, grafiikka ja ryhmä "muut".



Jaa että fysiikka ja grafiikka on omissa säikeissään mitkä ei keskustele keskenään. Mitenkäs tuo grafiikka tietää minne fysiikkaosuus on laskenut pelihahmon lentävän, jos nämä eivät keskenään vaihda mitään tietoja?

Toinen asia on että eri coret ei saa käyttää jaettuja resursseja. Muisti on mahdollista varata etukäteen, verkkokortteja voi olla useita, samoin kovalevyjä. Mutta esim pelissä levyä ei käytetä ollenkaan, ja verkkoliikenteen voi hoitaa yksi core keskitetysti.



Eli yksi ydin hoitaa verkkoliikennettä, ilman että se keskustelee millään tavoin niiden muiden ytimien kanssa siitä mitä sinne pitää lähettää?

Ja miten niin peleissä ei kovalevyjä tarvita? Nykyajan pelit lataavat jatkuvasti kovalevyltä grafiikkaa, malleja, pelikarttoja jne. Ja tallentavat yleensä pelin tietoja myös sinne.

Tekstisi perusteella et näytä ymmärtävän rinnakkaisohjelmoinnista oikeastaan mitään.

konna
Siinä mielessä koodajan työ on helpompaa että kirjastoja ja niihin dokumentaatiota on valtavasti saatavilla ja sellaista ongelmaa on vaikea koodata jota ei joku olisi jo jollakin palstalla käsitellyt.



Se taas riippuu hyvin paljon siitä mitä tekee. Minä joudun työkseni ratkomaan usein ongelmia mistä ei reaalimaailmassa olla edes kuultu (eikä salassapitosopimuksien takia varmaan tulla kuulemaankaan).

Mutta toki peruskoodareilla on nykyään nuo mainitsemasi asiat varsin hyvässä kunnossa jos vertaa sitä siihen aikaa milloin minä aloitin. Pelkästään Googlen olemassaolo tekee peruskoodauksen 1000 kertaa helpommaksi. Mutta sitä ei tosiaankaan voi ihan kaikkeen yleistää.

Lisäksi muistia ja cpu:ta on paljon.



Paitsi sulautetut järjestelmät, sekä vanhat ylläpidettävät järjestelmät, missä raudan päivittäminen ei ole vaihtoehto.

Ja toisekseen se että muistia ja cputa on paljon käytössä ei tarkoita että niitä saisi tuhlata. Yleisimmät moitteet mitä ohjelmat saavat ovat kaatumiset ja muistin ja cpu:n kulutus. Moni saattaa hylätä ohjelman tai käyttöjärjestelmän näiden takia.

Ei pidä unohtaa myöskään vihreitä arvoja. Mitä vähemmän resursseja ohjelma tarvitsee, sitä vähemmän se vie sähköä, eli sitä halvemmat käyttökustannukset sillä on.

Gravity

Eli yksi ydin hoitaa verkkoliikennettä, ilman että se keskustelee millään tavoin niiden muiden ytimien kanssa siitä mitä sinne pitää lähettää?



Siellä rajapinnassa on tietenkin käyttiksen kontrolloima jono. Koska sovellukset ei sitä kontrolloi, niin se ei ole ohjelmoijan ongelma.

Gravity

Ja miten niin peleissä ei kovalevyjä tarvita? Nykyajan pelit lataavat jatkuvasti kovalevyltä grafiikkaa, malleja, pelikarttoja jne. Ja tallentavat yleensä pelin tietoja myös sinne.

Tekstisi perusteella et näytä ymmärtävän rinnakkaisohjelmoinnista oikeastaan mitään.




Lataaminen eli lukeminen ei aiheuta ongelmia. Kirjoittaminen aiheuttaa, jos samaan aikaan toinen säie lukee/kirjoittaa. Pelit ei juurikaan kirjoita, joten ei ongelmaa.

Ymmärrän että pidät rinnakkaisohjelmointia vaikeana. Se on mahdotonta, jos ei tee oikeaoppista koodia, omista hyviä kirjastoja tai ei tunne käyttiksen ja prossun sisäistä toimintaa. Minä en käytä C:tä tai C++:aa.

Gravity
Pelkästään Googlen olemassaolo tekee peruskoodauksen 1000 kertaa helpommaksi.



Höpö höpö. Kertoo enemmänkin opetuksesi tasosta ja lähtötasostasi kuin Googlen tarpeellisuudesta. Mene kirjastoon tai kirjakauppaan ja lainaa/osta alan kirja. Saat siitä luultavasti paljon enemmän hyötyä suhteessa ajan käyttöön kuin Googlesta.

Suomen kielessä on se hyvä puoli, että voi hankkia valmiiksi karsiutunutta materiaalia.

MaKo71
Seuraa 
Viestejä1481
Lektu-Elli
Gravity
Pelkästään Googlen olemassaolo tekee peruskoodauksen 1000 kertaa helpommaksi.



Höpö höpö. Kertoo enemmänkin opetuksesi tasosta ja lähtötasostasi kuin Googlen tarpeellisuudesta. Mene kirjastoon tai kirjakauppaan ja lainaa/osta alan kirja. Saat siitä luultavasti paljon enemmän hyötyä suhteessa ajan käyttöön kuin Googlesta.



Enpä kyllä usko. Kyllä mulle google on merkittävin erilaisten kielten, prosessorien, ympäristöjen ja vastaavien "referenssimanuaali".

Joo pojat.
Nyt on vaan sellainen juttu näiden ohjelmien kanssa, että ne ohjelma vasta myyvät, joillekka taataan, että ne eivät kaadu esim. GarbageCollectorin laiskuuden myötä.

Josko paukautan pöytään, että minä ostan vaan sellaisia ohjelmia, joita ei tarvitse kenenkään adminin olla räpläämässä missään vaiheessa kun ohjelma on startattu palvelimella, ja toiminee seuraavan 10 vuotta.

Että tuo startattu ohjelma on vaikkapa Etelä-Afrikkaassa kuparikaivoksessa, että sinne kaivokseen ei ole kellään menemistä ja tulemista katsomaan mitä tietokoneet työstävät. Kas kun ohjelma on myyty sillä tapaa, että se ei tarvitse mitään huoltoa taikka adminin tukea.

Mites pannaan suu, kun ohjelman tulee pyöriä palvelimella niin, että vain sähkökatkot ja hardisviat ovat niitä vikoja, joita asiakas sallii.

Mitä sitten tehdään kun muistin käyttö kasvaa ja kasvaa, kone hidastuu ja alkaakin olla niin, että ohjelman vamistajan tulee mennä paikalle omalla rahallaan maksamalla 2000 euroa lentolipuista ja hotellit päälle.

Tässä vaan haen sitä, että kuinka varmistaa ohjelmansa sillä tavalla, että ei
ryhdy syömään muistia salakavalasti, kuten nyt nämä dynaamiset listat ja sum muut venyvät "listat sallivat nykyisin".

Tässä vaan yksi näkemys säikeiden käytettävyyden ja muistin hallittavuuden ongelmallisiin käytäntöihin, että kuinka asiat sitten ihan oikeasta tehdään niin, että ohjelmat toimivat palvelimilla jopa 10 vuoden ajan.

Että, onko kokemusta sellaisesta admininin työsta taikka ohjelman tuottamisesta, joko menee niin kuin elokuvan katsominen - pelaa kuin Buick taikka junnan vessa.

Näin tässä taas tuli höpötettyä.

turnabull
Mites pannaan suu, kun ohjelman tulee pyöriä palvelimella niin, että vain sähkökatkot ja hardisviat ovat niitä vikoja, joita asiakas sallii.



Tuttua hommaa.

Tässä vaan haen sitä, että kuinka varmistaa ohjelmansa sillä tavalla, että ei
ryhdy syömään muistia salakavalasti, kuten nyt nämä dynaamiset listat ja sum muut venyvät "listat sallivat nykyisin".



Itseasiassa dynaamiset listat on tehty juuri estämään muistin kulutusta. Niiden tarkoitus on ottaa käyttäjältä pois vastuu muistin varaamisesta ja vapauttamisesta, mikä helposti aiheuttaa muistivuotoja.

Muisti voi loppua myös ilman muistin dynaamista varailuakin, jos esimerkiksi tekee rekursiivisia funktiokutsuja ja pinosta loppuu muisti.

Ison ohjelman tekeminen bugittomaksi ilman testaamista on mahdotonta. Siksi ainoa keino varmistua sen oikeasta toiminnasta on testata se. Kaikkein parhaaseen lopputulokseen pääsee todennäköisesti jos kykenee noudattamaan esim. Test Driven Development-sääntöjä orjallisesti. Eli teet ensin koodin mikä testaa esim. tietyn funktion kaikilla mahdollisilla raja-arvoilla, valideilla ja epävalideilla parametreilla, ja vasta sitten kirjoitat funktion.

Näin päin siksi, että tuossa järjestyksessä tekemällä koodi tulee pakostikin kirjoitettua testattavaksi. Tuo myös nopeuttaa oikeasti yleensä itse kehitystyötä. Siis tarkoitan että testien + funktion kirjoittaminen on nopeampaa, kuin että kirjoittaisi pelkän funktion. Koska kun jo tekovaiheessa löytää kaikki bugit siitä, niitä ei tarvitse myöhemmin suurennuslasin kanssa etsiä ja tehdä korjauksia ja ajaa manuaalisia testejä uusiksi.

TDD:n huono puoli on siinä että se vaatii kunnolla toimiakseen orjallista noudattamista. Ja isoissa projekteissa sellaista itsekuria ei tahdo löytyä kovin monelta. Viimeistään siinä vaiheessa kun vaatimuksiin tulee isoja muutoksia ja isoa osaa koodista joudutaan muuttamaan, moni turhautuu testien kirjoittamiseen, niin hyödyllisiä kuin ne ovatkin. Mutta mielestäni jo sillä että edes alkuvaiheessa sitä käyttää, saa ainakin ohjelman perusrakenteen toimivaksi ja helposti testattavaksi.

Toinen vaihtoehto on ohjelman dynaaminen valvonta ajon aikana. Jos ohjelma alkaa syömään liikaa muistia, käynnistetään se automaattisesti uusiksi (jos se on mahdollista). Yleensä tuo on kuitenkin pienempi paha kuin täydellinen jumiutuminen.

turnabull
I
Että, mitä tämä tuplaydin prosessori on tuonut sellaista mukanaan, että sellaista ei ole voitu toteuttaa yksiytimisellä prosessorilla.



Selvin etu on siinä, että ytimien määrän kaksinkertaistaminen kaksinkertaistaa FLOPSit vaikka ytimen sisällä tekniikka pysyisi jotakuinkin samantasoisena.

Esim. AMD:n prosessoreissa mallinumero kertoo suurinpiirtein yhden ytimen MFLOPS-luvun, eli jos otetaan vaikka 5000+, niin tavallinen laskee 5000 MFLOPpia sekunnissa, mutta kun lätkäistään toinen ydin viereen tulee megafloppeja jo kymppitonnin verran, se on huomattava ero jos raaka laskentateho on se mitä tarvitaan.

II
Mitenkäs oikean ohjelmoijan maailma on muuttunut tämän tuplaytimen myötä, että pitääkö oikein ruveta säikeitä suosimaan, jotta saisi uudesta prosessoristaan irti kaikki hyödyt.



Yksisäikeinen ohjelma ei hyödy moniytimisyydestä muuten kuin siten että tarvittaessa sille voidaan omistaa kokonainen ydin, mutta nykykoneiden pohjakuorma ei taida usein ylittää jotain 5%, joten nopeudenlisäykset yksittäiselle yksisäikeiselle ohjelmalle jäävät aika laihoiksi.

Ts. Jotta moniydinprosessorista olisi mitään hyötyä täytyy ajaa yhtä aikaa useampaa säiettä, eli joko monisäikeisiä ohjelmia, tai sitten vain useampaa ohjelmaa yhtä aikaa.

Ihan käytännön näkökulmasta tosin voisin sanoa, että tuplaydin kyllä sujuvoittaa koneen yleistä käyttöä vaikkei mikään yksittäinen ohjelma siitä erityisesti hyötyisikään. Erot ovat periaatteessa pieniä, mutta itse olen oppinut arvostamaan todellista moniajoa.

Toisaalta säikeistä on hyötyä vaikkei koneessa olisikaan kahta tai useampaa ydintä. Minä olen ihan vaan sunnuntaiohjelmoija, enkä yleensä tee oikeastaan mitään mikä vaatisi mitenkään hirveää suorituskykyä, mutta sen verran olen säikeisiin tutustunut, että yksi ohjelma jonka tein käsittelee huomattavan kokoista luetteloa, sen tiedostokoko on jotain 16 megaa, mikä ei nyt sinänsä ole mitenkään hirveän paljon, mutta se jumiuttaa ohjelman lataamisen ajaksi. Noh, eihän se lataaminen tietenkään vie kuin pari sekuntia, mutta debuggaamista se alkoi pidemmän päälle häiritä kun jonkun siihen luetteloon liittymättömän toiminnon testaamista piti odotella aina hetken verran. Mistä syystä päätin siirtää luettelon lataamisen omaksi säikeekseen, mikä oli aika helppoa kun sitä toimintoa ei tarvitse ajaa kuin kerran, eli luettelosta riippuvaiset toiminnot oli helppo lukita eikä asiaa tarvinnut pohtia sen pidempään. Lataamisen päätyttyä vain vapauttaa toiminnot, ja siinä se.

Vaikka siirsinkin luettelon latauksen omaksi säikeekseen lähinnä debuggausta nopeuttaakseni, niin ei se normaalikäyttäjääkään haittaa, päinvastoin. Käyttö sujuvoitui huomattavattavasti.

Niin minä kannanotollani tähän tuplaydinasiaan haluan tuoda julki sellaista, että kuinka tuottaa sellaista ohjelmaa, joka on sellainen, että pystyy tuottamaan luotettavaa virhetekstiä virhetidostoon kun esim. kaksisäikeisessä ohjelmssa liki samanaikaisesti tapahtuu virhetilanne molemiissa säikeissä, ja molommat säikeet ryhtyvätkin ilmoittamaan liki samanaikaisesta omista virhetilanteistaan virhetiedostoon.

Sitten kun tätä virhetiedostoa luetaan kenties toisella puolella maapalloa, niin kuinka voidaan olla varmoja siitä, mitä tuossa virhetiedoston tapahtumissa on totta ja väärää.

Että kun puhe oli monisäikeisten ohjelmien luotettavuudesta ja kommervenkkisyydestä, niin edelleenkin väitän, että on vain olemassa yksisäikeinen tapa olla varma siitä mitä virheilmoitukset ilmoittavat.

Edelleen haluan kohdistaa huomiota siihen, että nyt ei keskustella sellaisista sovellukista, joidenka ääressä istuu admin ja jolla on etäyhteys taikka muu tapa hallita kaukana maantieteellisesti sijaitsevaa palvelinta ja sen ohjelmaan.

Muuten, tuo nimimerkki Aslak on sitten sellainen lapin mies, että eipä ole parempaa ja hyväsydämisempää miestä.

turnabull

Sitten kun tätä virhetiedostoa luetaan kenties toisella puolella maapalloa, niin kuinka voidaan olla varmoja siitä, mitä tuossa virhetiedoston tapahtumissa on totta ja väärää.



Luulisin että jokaisen säikeen virheenkäsittelijä merkkaisi tiedostoon missä säikeessä virhe on tapahtunut, ettei tule sekaannusta kuka teki mitä.

Underseboot

Esim. AMD:n prosessoreissa mallinumero kertoo suurinpiirtein yhden ytimen MFLOPS-luvun

Tämä "nyrkkisääntö" kyllä hajoaa aika tehokkaasti käsiin kun aletaan tarkastelemaan mihin ne mallinnumerot perustuvat ja mikä on niiden prosessoreiden oikea suorituskyky. Yllättäen käsite MFLOPS ei ole ihan niin yksiselitteinen asia kun puhutaan moderneista cisc-prosessoreista.

Esimerkiksi AMD Phenom 9700 saavuttaa eräässä synteettisessä testissä 31 000 MFLOPS joka tietää 7750 MFLOPS per ydin. Asiaan vaikuttaa suuresti mm. käytetty koodi, onnistuuko prosessori ennustamaan ohjelman haarautumista, kuinka paljon dataa välimuistiin mahtuu, kuinka paljon "huteja" tulee välimuistista haun kanssa (dataa ladataan isoissa palasissa prosessoriin/prosessorista), kuinka hyvin laskentayksiköt tulevat hyödynnettyä missäkin laskutoimituksessa...

Eli oikeastaan sille ei voida määritellä mitään tiettyä suorituskykyä jonka yksikkö on MFLOPS. Mallinnumero heijastaa pelkkää PR-osaston mielipidettä siitä minkä niminen tavara kuluttajille menee helpoiten.

Näytönohjaimissa on helpompi laskea teoriassa kuinka monta laskentaoperaatiota sekunnissa laite suorittaa, koska niissä homma on yksinkertaisemmin toteutettu. Yksi shader-yksikkö suorittaa 2 liukuluku-operaatiota kellojaksossa, Radeon HD4850 näytönohjaimessa on 800 shader-yksikköä, ja sen ytimen kellotaajuus on 625 MHz. Siispä näytönohjain kykenee suorittamaan tasan 1 TFLOPS.

Ja se on samperin iso määrä dataa, ja myös osoitus siitä minkä takia varsinainen raskas laskenta siirtyy pois prosessorin harteilta tulevaisuudessa. Intelin suunnittelema näytönohjain "Larabee" tulee tottelemaan hyvin samanlaisia komentoja kuin kaikki x86 prosessorit, joka laajentaa sen käyttömahdollisuuksia valtavasti muihin verrattuna ja tuo todella massiivisen rinnakkaislaskennan helpommin käytettäväksi kuin mitä CUDA tai ATi/AMD:n viritykset sallivat.

Ideana on se, että sama koodi voi pyöriä sekä prosessorilla että näytönohjaimella, jolloin tavallinen tietokone muuttuu supertietokoneeksi kun siihen laitetaan Larabee kortti kiinni, tai jos kone laskee pelkkää valtavan suurta datasettiä niin prosessorilla voi heittää kuikkaa ja suorittaa laskutoimitukset pelkästään sillä kortilla.

Esimerkiksi peleissä voidaan toteuttaa grafiikka täysin ray-tracing -menetelmällä jossa jokainen ruudun pikseli voidaan laskea omassa erillisessä säikeessään riippumatta muista, ja saada aikaan todella fotorealistista grafiikkaa jossa valo taittuu lasissa (tai missä tahansa väliaineessa) fysiikan lakien mukaan ja varjot ja heijastukset elävät muutenkin kuin etukäteen laskettuina tummina läntteinä ja tekstuureina. Nykyiset näytönohjaimet jotka on viritetty perinteistä rasterointigrafiikkaa varten eivät siihen kykene, koska ne eivät ymmärrä siihen laskentaan tarvittavia komentoja vaan grafiikkaydin pitää "huijata" tekemään oikea laskutoimitus.

Se mikä nykyään on peleissä "erikoisefekti", hieno iltarusko, sateenkaari taivaalla, ilmakehän sineen katoavat vuoret taivaanrannassa tai sumu taistelukentän yllä on tulevaisuuden pelissä sen virtuaalisen ympäristön aito "fysikaalinen" ominaisuus, eikä se oikeastaan ole edes vaikea laskea. Se vaatii vain massiivista rinnakkaisuutta jotta näytölle saadaan riittävän nopeasti uutta kuvaa edellisen tilalle.

turnabull
Niin minä kannanotollani tähän tuplaydinasiaan haluan tuoda julki sellaista, että kuinka tuottaa sellaista ohjelmaa, joka on sellainen, että pystyy tuottamaan luotettavaa virhetekstiä virhetidostoon kun esim. kaksisäikeisessä ohjelmssa liki samanaikaisesti tapahtuu virhetilanne molemiissa säikeissä, ja molommat säikeet ryhtyvätkin ilmoittamaan liki samanaikaisesta omista virhetilanteistaan virhetiedostoon.



Tuo ratkaistaan lukoilla ja synkronoinnilla. Tehdään esim. luokka mikä huolehtii logikirjoittelusta ja muu ohjelma lähettää sen jonoon tekstit mitkä pitäisi tulostaa. Kyseinen jono pitää olla lukoilla suojattu, että siihen voi kirjoittaa vain yksi säie kerrallaan. Luokka sitten omaan tahtiinsa tulostelee jonosta tekstit sitä mukaa kuin ehtii. Kun vielä säikeet kertovat oman id:nsä, on logeja melko helppo seurata.

Toinen vaihtoehto on, että jokainen säie tulostaa logit omaan tiedostoonsa, mikä on epäkäytännöllistä jos säikeitä on tuhansia.

Veikko
Underseboot

Esim. AMD:n prosessoreissa mallinumero kertoo suurinpiirtein yhden ytimen MFLOPS-luvun

Tämä "nyrkkisääntö" kyllä hajoaa aika tehokkaasti käsiin kun aletaan tarkastelemaan mihin ne mallinnumerot perustuvat ja mikä on niiden prosessoreiden oikea suorituskyky. Yllättäen käsite MFLOPS ei ole ihan niin yksiselitteinen asia kun puhutaan moderneista cisc-prosessoreista.

Esimerkiksi AMD Phenom 9700 saavuttaa eräässä synteettisessä testissä 31 000 MFLOPS joka tietää 7750 MFLOPS per ydin. Asiaan vaikuttaa suuresti mm. käytetty koodi, onnistuuko prosessori ennustamaan ohjelman haarautumista, kuinka paljon dataa välimuistiin mahtuu, kuinka paljon "huteja" tulee välimuistista haun kanssa (dataa ladataan isoissa palasissa prosessoriin/prosessorista), kuinka hyvin laskentayksiköt tulevat hyödynnettyä missäkin laskutoimituksessa...

Eli oikeastaan sille ei voida määritellä mitään tiettyä suorituskykyä jonka yksikkö on MFLOPS. Mallinnumero heijastaa pelkkää PR-osaston mielipidettä siitä minkä niminen tavara kuluttajille menee helpoiten.




No, voihan olla ettei suorituskyvyn tarkka määrittely ole ihan yksiselitteistä, mutta ei se nyt kuitenkaan ihan PR-osaston keksintöä ole että AMD:n prosessorit laskevat testeissä jotakuinkin mallinumeroitaan vastaavat määrät flopseja.

Ja toisaalta vaikkeivät flopsit ehkä ihan koko totuutta kerrokaan, niin on se ainakin paljon lähempänä totuutta kuin kellotaajuus. Kyse on kuitenkin vain vertailusta. Voi olla että jonain päivänä flopsitkin vanhenevat yhtä hyödyttömiksi kuin kellotaajuus, mutta ainakaan toistaiseksi minä en keksi mitään parempaakaan. Testejä voidaan kuitenkin tehdä myös eri valmistajien prosessoreilla, ja kuten sanottu, flopsit eivät ole ehkä ihan koko totuus, mutta kyllä se silti laskutehosta jotain kertoo.

Ja lopulta eihän pelkällä prosessorin laskuteholla vielä mitään tee, se data täytyy ensiksi saada sinne, ja siinä vaiheessa pitää ottaa huomioon emolevy, muistit jne. Samakin prosessori voi toimia ihan eri teholla jollain toisella kokoonpanolla. Eikä sovi unohtaa sitäkään mitä on tekemässä. Esim. pienet ja paljon laskentatehoa vaativat ohjelmat hyötyvät suurista välimuisteista eniten, kun suuret ohjelmat vaativat lähinnä paljon keskusmuistia.

Mutta ymmärtääkseni ei ollut tarkoitus puhua vertailun vaikeudesta, vaan tuplaytimen hyödyistä. Tuplaytimen selvin hyöty tavalliseen verrattuna on siinä että se kaksinkertaistaa laskentakapasiteetin. Mikä ei tietenkään vielä tarkoita oikeastaan yhtään mitään, se kapasiteetti täytyy vielä hyödyntääkin, ja siihen tarvitaan säikeitä, tai moniajoa. Vertailu eri kokoonpanojen ja käyttötarkoitusten välillä ei ole mitenkään yksiselitteistä, eikä missään nimessä pelkistettävissä flopseiksi, mutta jos puhutaan prosessorin kyvystä suoriutua laskutehtävistä, niin siitä on hyvä aloittaa.

Sivut

Suosituimmat

Uusimmat

Sisältö jatkuu mainoksen alla

Suosituimmat