Suorituskyky: Lähdekoodi Vs. binääridistribuutiot

[rationaalinen]

Tervehdys hyvät foorumilaiset!

Olisiko kenelläkään teistä ensikäden kokemuksia ja/tai tietoa binääri ja lähdekoodipohjaisten Linux jakeluiden välisestä suorituskykyerosta, mikäli eroa on?

Tietokanta serveri sovellutuksissa eroa varmasti onkin enemmän tai vähemmän, mutta entä normaali työpöytäkäyttö käsittäen tekstinkäsittelyn, multimedian ja omien optimoitujen ohjelmien ajamisen?


Vertailukohteina voisivat olla esim. geneerinen AMD64 koodi (optimointitasona ilmeisesti -O2) vs. -O2/Os -SSE3 -fast math yms. optimoinneilla käännetyt ohjelmat, joista on poistettu turhat laajennukset(esim. jos käyttää KDE työpöytää niin tuki GNOME :lle on poistettu). Ylimääräisten moduulien ja ajurien poistaminen kernelistä nopeuttaa ilmeisesti vain koneen boottaus ja sammuttamisnopeuksia?

Miten suurista eroista käytännössä puhutaan keskimäärin; 5%, 20% tjsp.?

Omia kokemuksia ja luuloja:

Olen pikaisesti kokeillut Gentoo Linux :a ja PCBSD itsekäännetyllä koodilla. Mielestäni eron valmiiksikäännettyyn geneeriseen binäärikoodin huomaa jo perus työpöytäkäytössä. Yksinkertaisesti suuret menut/valikot ja ohjelmat tuntuvat aukeavan/käynnistyvän nopeammin. Tosin binääridistronkin (esim. Fedora ja Debian) tuntuu saavan kiireisen tuntuiseksi säätämällä ja kaikki turhat palvelut sammuttamalla. Esim. Sidux vaikuttaa erittäin liukkaalta jakelulta. Sidux on KDE työpöydällä varustettu jakelu, joka pohjautuu Debianin epävakaaseen sid haaraan.

//t: Rationaalinen

[Asmo Koskinen]

Omia kokemuksia ja luuloja:

Oma luuloni on, että kun ohjelmoijat eivät osaa hyödyntää moniytimisiä prosessoreita, niin meillä loppukäyttäjillä on aika vähän tehtävissä. Voihan sitä asentaa jonkun optimoidun distron, mutta jos sitä ei ole optimoitu quad-prosessorille, niin mitä sitten?

Vaikka näin:

"The computer industry is undergoing a paradigm shift. Chip manufacturers are shifting development resources away from single-processor chips to a new generation of multi-processor chips known as multicores.

This fundamental change in our core computing architecture will require a fundamental change in how we program. The art of multiprocessor programming, currently mastered by few, is more complex than programming uniprocessor machines, and requires an understanding of new computational principles, algorithms, and programming tools."

http://www.cs.tau.ac.il/~multi/?p=intro

Tämä on itselleni ihan relevantti ongelma - olemme maksaneet koululla kahdesta palvelimesta, joissa kummassakin on kaksi kaksi-ytimistä prosessoria, jotka ovat lisäksi vielä 64-bittisiä.

Nyt käytämme noissa koneissa Ubuntu 6.06.1 32-bittistä ympäristöä, Voin asentaa niihin 64-bittisen ympäristön (http://wiki.ubuntu-fi.org/Edubuntu_7.10_Classroom_Server_%28x86_64%29), mutta milloin me saamme aidosti käyttöömme kummankin palvelimen 4 prosessoria kaikissa ohjelmissa?

Ystävällisin terveisin Asmo Koskinen.

[Asmo Koskinen]

Oma luuloni on, että kun ohjelmoijat eivät osaa hyödyntää moniytimisiä prosessoreita, niin meillä loppukäyttäjillä on aika vähän tehtävissä.

Vuosi sitten (noinkohan  tilanne olisi yhtään parempi vuotta myöhemmin) pelimaailma ei osannut hyödyntää uutta tilannetta - ja siellä sentään on rahaa pilvin pimein:

"For example, most current (as of 2006) PC games will run faster on a 3 GHz single-core processor than on a 2GHz dual-core processor (of the same core architecture),[citation needed] despite the dual-core theoretically having more processing power, because they are incapable of efficiently using more than one core at a time."

http://en.wikipedia.org/wiki/Multi-core_(computing)#Disadvantages

Osaakohan KDE 4, OpenOffice 3 tai Firefox 3 tätä yhtään paremmin lähitulevaisuudessa?

Ystävällisin terveisin Asmo Koskinen.

[Asmo Koskinen]

Osaakohan KDE 4, OpenOffice 3 tai Firefox 3 tätä yhtään paremmin lähitulevaisuudessa?

Voisiko joku oikeasti asiaa ymmärtävä kommentoida?

Jos KDE 4 menee moniydin-alueelle, niin minä menen perässä Edubuntu 8.04 Classroom Server x86_64 -versiolla ensi kesänä.

03/09/2007:

"c't has tested ThreadWeaver on an experimental 4 core system with hyperthreading, and it scales very nicely with the CPU power. Loading 56 4MBit images files took a little over 2 seconds. I guess that is fast."

http://www.kdedevelopers.org/node/2714

KDE 4 julkaistaan vielä tämän vuoden puolella, joten se ehtii viilattuna Kubuntu 8.04:ään. Hyvin mielenkiintoista.

http://en.wikipedia.org/wiki/KDE_4#Release_schedule

Ystävällisin terveisin Asmo Koskinen.

[rationaalinen]

Rinnakkaistaminen on kieltämättä hyvin mielenkiintoinen aihepiiri, jota on pähkitty niin maailmalla kuin kotimaassakin. Harmillista vain on, että nykyisten miljardien avointen koodirivien rinnakkaistaminen vaatii aikaa ja eritoten taitoa. Rinnakkaistamisenkin voi toteuttaa vähintään kolmella eri tasolla: komento-, säe- ja ohjelmatasolla. Lisäksi täytyy miettiä millä tekniikalla tietoa siirretään ytimien välillä niin, että laskenta-aika/tiedonsiirto-aika suhde on suuri. Mikäli tietoa vaihdetaan/siirretään jokaisen bitin käännön välillä, tukkeutuu suorittimien välinen kaista.

Mikäli työpöytäympäristö ja sen jälkeen myös sovellutukset saadaan rinnakkaistettua, on kyseessä suuri harppaus eteenpäin ja "myyntivaltti", joka tekee *unix järjestelmät entistä houkuttelevimmiksi. Henkilökohtaisesti luotan siihen, että yksittäisen suorittimen nopeus ei tule enää kasvamaan kovinkaan paljoa vaan suorittimien määrä kasvaa pikkuhiljaa linjalla 2^n (2, 4, 8, 16, 32 ...).

Koodin perkaamiseen aikani ja taitoni eivät valitettavasti riitä, tästä johtuen olen kiinnostonut koodin optimoimiseen alustakohtaisesti kääntäjäoptioiden avulla.

Pähkintää:
Koko käyttöjärjestelmän lähdekoodin kääntäminen ei varmaankaan ole loppujen lopuksi viisasta puuhaa. Ajatellaan esimerkiksi ohjelmaa, jonka kääntämisen käytetään 1h CPU aikaa. Ohjelmaa käytetään muutama kerta ennen seuraavan päivityksen tuloa, jolloin ohjelma käännetään uudestaan. Parin viikon ajan optimoitua ohjelmaa käytettäessä säästettiin CPU aikaa esim. 5 minuuttia verrattuna geneeriseen versioon. 5 :n minuutin säästö 60 minuutin käännösaikaan verrattuna on riittämätön.  Paljon CPU aikaa vaativat esim. tieteelliset ohjelmistot kannattaa siis ehdottomasti optimoida sekä koodi että kääntäjätasolla. Käyttöjärjestelmän itsekääntämisen järkevyys on siis hyvin epäilyttävää.

//t: Rationaalinen

[muep]

Tämmöisiä luuloja täältä:

Nykyiset prosessorit ovat jo sen verran nopeita, että itse ohjelmakoodin optiomoinnilla ei suuria etuja tavallisessa työpöytäkäytössä saavuteta. Suurin osa viiveistä tulee tietojen lataamisessa muistiin kiintolevyltä, ei niinkään prosessorin tehojen mukaan. Vähän ohjelmia sisältävät jakelut toimivat usein suurempia ripeämmin, kun esimerkiksi tietokoneen käynnistyessä täytyy levyasemilta hakea vähemmän dataa, ja lisäksi se usein voi olla vähemmän pirstaloitunut pitkin levyä.

Itse en tällä hetkellä näe ongelmaksi sitä, että yksittäinen ohjelma ei välttämättä hyödynnäkään kaikkia prosessoriytimiä yhtäaikaa. Tietokone kuitenkin suorittaa yleensä useampaa ohjelmaa kerralla. Lisäksi useimmat tällä hetkellä kuluttajakäytössä olevat ohjelmat, kuten selaimet, mediatoistimet, tekstinkäsittelyohjelmat ja vastaavat ovat sen verran simppeleitä, että ne toimivat yhdenkin prosessoriytimen varassa oikein mainiosti. Prosessoria raskaammin kuormittavissa ohjelmissa säikeistyksellä toki varmaan saavutetaan nopeusetu, joka kannattaa hyödyntää, jos siihen osaaminen riittää. Kaiken maailman miinaharavoiden, tekstiedotorien ja laskinohjelmien säikeistämistä en pidä mielekkäänä, kun hyvin ne nytkin toimivat. Toisaalta sitten esimerkiksi videoeditorin tai tehoja vaativan simulaation tai pelin sitten kai kannattaa ne kaikki tehot pyrkiä hyödyntämään, kun niiden toimivuus on enemmän koneen laskentatehoon sidottu.

[MikkoJP]

Yksinkertaisesti suuret menut/valikot ja ohjelmat tuntuvat aukeavan/käynnistyvän nopeammin. Tosin binääridistronkin (esim. Fedora ja Debian) tuntuu saavan kiireisen tuntuiseksi säätämällä ja kaikki turhat palvelut sammuttamalla.

Käyttötuntumaa sähäköittää huomattavasti esimerkiksi KDE:n asetusten käyminen läpi. Esimerkiksi alapalkin piilotus nopeammaksi, animaatiot nopeammaksi, ikkunoiden sisällön näyttö pois siirrettäessä jne.

[Ux64]

Rinnakkaistamisen sijasta on vielä yksi optio, eli pipelining. Jossa tehtävät pilkotaan liukuhihnalle. Joissain ratkaisuissa tämä toimii varsin mainiosti. Kuten esimerkiksi datan pakaamisessa joka on monivaiheinen prosessi. Kokonaissuorituskyky kasvaa vaikka rinnakkaistamista ei ole toteutettu lainkaan. Tätä lähestymistä olen käyttänyt tekemissäni softissa aika usein. Tietysti ongelmana on se, että täyttä käyttöastetta tällä ei välttämättä saavuteta. Mutta moni prosessi tehostuu silti olennaisesti, varsinkin neliytimisellä koneella. Datan sisäänlukeminen, esikäsittely, prosessointi, jälkiprosessointi ja tallentaminen kaikki omissa threadeissan. Valmiit objektit sitten kopitetaan threadista toiseen. Näin myös datan "jatkuva" jakaminen prosessoriytimien kesken jää vähäiseksi. Joka voi olla ongelma ns. täydellistä rinnakkaistamista hakiessa. Pitkiä synkronointeja tulee tolkuttomasti kun veivataan jatkuvasti jaettuja suuria datamassoja.

Kokemusta esim. valtavien XML aineistojen konvertonnissa tietorakenteesta toiseen, homma pelaa hienosti. Jos tehtävän prosessointi vaihe on riittävän raskas ja mielekkäästi rinnastettavissa, sen voi vielä rinnastaa N threadiin. Mutta aina ei olla niin onnekkaita.

Tuo pipelining oli yllättävän helppo toteuttaa. Konvertointi sovellus oli alunperin kirjoitettu javalla ja toimi jo valmiiksi järkevissä askeleissa vaikkakin suoritettiin yhtenä threadina. Askeleiden eriyttäminen omiksi säikeikseen ei tuottanut sen suurempia tuskia. Ongelmia alkoi muodostua kun aineiston käsittelyyn alkoi yöajossa menemään yli kuusi tuntia. Nyt aika on alle puolittunut neliprosessorisessa koneessa. Ainakin omasta mielestäni pidän tuota säätämisprojektia onnistuneena.

Mitä tulee tavallisiin työpöytäsovelluksiin. Olen aika pitkällä sillä linjalla, että kunhan se TOIMII niin kaikki on hyvin. Mielettömään optimointiin ja tuunaukseen ei kannata käyttää resurseja nykyjään. Kehitystyö on se kallein resurssi, rautaa saa aina halvemmalla lisää. Sama pätee myös siihen miksi käytetään aina vain korkeamman tason ohjelmointikieliä. Äärimmäisyyksiin vietynä: Jos tekisi kaikki softat assemblerilla, jokaiselle prosessorille tehtäisiin oma optimoitu versio ja toteutettaisiin vain välttämättömät funktiot saataisiin lisää vauhtia sovelluksiin käsittämättömän paljon. Kaunis visio, mutta aika kaukana todellisuudesta.

Pythonia olen tässä viimeaikoina katsellut, lienee ilmeisen suosittu *nix puolella. Ruby olisi kuulemma vielä parempi, mutta sen kehitys on ilmeisesti hieman vaiheessa, kääntäjän ilmoitukset todella hämäriä jne. No eipä nuo Javankaan virheilmoitukset järkyttävän selkeitä ollut ennen kuin niihin oikein perehtyi.

Sitten käytännön ongelmiin. Esim uusissa prosessoreissa hehkutettiin uusia multimedia toimintoja? Mitä sitten? Kun softat ei edes tue vielä moniytimisyyttä. Arvatkaa vaan kummalla olisi suurempi tehtostava vaikutus sovellusten toimintaan.

FFMPEG ei tue h.264 videon purkamista monisäikeisenä. Näin ollen Q6600 @ 2.4 GHz prosessorin tehot loppuu yhden coren osalta videon toistossa. Pitäisi varmaan hommata tehokkaampi prosessori (huom, ei prosessorit).

[janne]

Olen pikaisesti kokeillut Gentoo Linux :a ja PCBSD itsekäännetyllä koodilla. Mielestäni eron valmiiksikäännettyyn geneeriseen binäärikoodin huomaa jo perus työpöytäkäytössä.

minä käytin aikaisemmin gentoota ja täytyy sanoa, että kyllä ne softat aavistuksen vikkelämpiä olivat. tietysti se näkyi enemmän paljon laskentaa vaativilla sovelluksilla, mutta kaikista suurimman eron sain aikoinani kuitenkin aikaan vaihtamalla kernelin skeduleria. käytin hetken jotain tosi bleeding edge syytä-vain-itseäsi kernel patchia (olisiko ollut love sources) ja sillä työpöydän responsiivisuus (ei nyt tule mieleen sitä kotimaista vastinetta) oli ihan omaa luokkaansa. minulla oli samaa aikaan kaksi erillistä, raskasta, kääntöä meneillään ja työpöytä ei lagittanut yhtään.