Dual Core µp (ja säikeet)

Seuraa 
Viestejä45973
Liittynyt3.9.2015

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)

Vierailija

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
Liittynyt18.10.2007
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

Vierailija

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ä.

Vierailija
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.

Vierailija
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ä.

Vierailija
konna
turnabull

tullessa monimutkaisemmiksi ( vaikea sana ).

monimutkaistuessa (pahoittelen pilkun viilausta, pakkomielle )

Vierailija

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.

Vierailija
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.

Vierailija
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.

Vierailija
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.

Vierailija
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.

Vierailija
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ä1467
Liittynyt15.11.2006
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".

Vierailija

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ä.

Vierailija
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.

Sivut

Uusimmat

Suosituimmat