Kirjoittaja Aihe: Inteliltä jopa 32 loogistaprosessoria, kahdella 8 ytimisellä prosessorilla  (Luettu 4223 kertaa)

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
http://www.tietokone.fi/uutta/uutinen.asp?news_id=36622&tyyppi=1
Lainaus
Xeonia käyttävien palvelinkoneiden kannalta asia on mielenkiintoinen. Tavallinen kahden prosessorin peruspalvelin tarjoaisi käyttöjärjestelmälle näin ollen 32 säiettä, eli ohjelmien kannalta kyseessä on 32 prosessorin kone.

Tätähän on kyllä ounasteltu tekniikkapiireissä pitkään. Kysymys onkin siitä, miten ohjelmointityökalujen pitää muuttua. Aina vain on sanottu, että ei se vielä ja kyllä vielä pärjää. Mutta entäs kun prosessorien määrän kasvu jatkaa Mooren lain mukaan?

Ainakin vanhalla ajattelumallilla tehdyt sovellukset putoaa auttamattomasti kelkasta. Omissa sovelluksissani käyttämäni pipelining / assembly line tekniikka putoaa myös, koska se vaatii ohjelmoijalta työtä suorittavien yksikköjen luomiseen.

Miten siis kirjoittaa sovellus joka hyödyntää tehokkaasti esimerkiksi tuhatta tai kahtatuhatta prosessoriydintä? Ja ettei jäädä alkukuoppiin niin lisätään noihin vielä nolla perään.

Ainakin ensimmäinen asia joka on aivan selvää on se, että tuo on huomioitava ohjelmien suunnittelussa. Python GIL on ainakin ongelma, samoin virtuaalikoneen GC, joka ei välttämättä kykene hoitamaan asiaa täysin rinnakkaisesti pyörivien sovellusten kanssa.

Mitä muuta, olennaista olen tässä unohtanut?

Jos siltä tuntuu tän saa toki siirtää tänne: Ohjelmointi, palvelimet ja muu edistyneempi käyttö
« Viimeksi muokattu: 01.02.09 - klo:15.35 kirjoittanut Ux64 »

tuke81

  • Käyttäjä
  • Viestejä: 1667
    • Profiili
Nojuu linuxillahan ton pitäis onnistua ;) Piti ihan kaivaa vanha linkki tileran 64 coreisesta prossusta(tiedän ei tietääkseni ole x86 yhteensopiva), olisi ihan mielenkiintoista nähdä tollasen cpuinfo linukan smp kerneliltä. Onkos tossa kernelissä muuten jokin raja coreissa?

Sattu nyt silmään tuosta tietokoneen sivuista tuo toinen artikkeli:
http://www.tietokone.fi/uutta/uutinen.asp?news_id=36029
Ootellukki että milloin saavat hieman valoa prossuun puolijohdetekniikan tilalle, hieman onnistuneet ja kellotaajuus heti pompsahti 340 GHz, ehkäpä kymmenen vuoden päästä tulee markkinoillekkin(nojuu ehkä hieman optimistista). Mitä nyt kouluissa olen optiikka lukenut, niin täysin optisella prosessorilla taajuudet saataneen sinne terahertsejen tietämille, mutta tämä vaatii hieman tekniikan kehittymistä kvanttimekaniikan ja epälineaarisen optiikan alalla(optinen photoneilla toimiva transistori; elektroneilla toimivan transistorin taajuusraja on jo tullut vastaan).
Miksi tehdä jotain helposti, kun sen voi tehdä vaikeastikin...

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
Nojuu linuxillahan ton pitäis onnistua ;) Piti ihan kaivaa vanha linkki tileran 64 coreisesta prossusta(tiedän ei tietääkseni ole x86 yhteensopiva), olisi ihan mielenkiintoista nähdä tollasen cpuinfo linukan smp kerneliltä. Onkos tossa kernelissä muuten jokin raja coreissa?

Ei huono. ;)

Muistelinkin jossain kun tutkin monicore / prosessori asiaa. Tutkineeni hyvin pitää artikkelia (kymmeniä sivuja) aiheesta jossa esim javaa ja pythonia oli testattu 64 prosessorisessa koneessa. Siinä käytiin yksityiskohtaisesti läpi, miten pienen pienillä suunnittelu / ohjelmointivirheillä tai VM:n parametreillä voitiin saada suorituskyky surkeaksi. Esimerkin tehtävät toimivat oikein tehtynä loistavasti 64 prosessorisella koneella. Mutta aivan pienen pieni virhe pudottaa suorituskykä ratkaisevasti. Ja normaalit Python ohjelmat vaikkakin multithreadaavia niin GILin takia pyörivät vain 1/64 osa nopeudella tuolla alustalla ilman kikkailuita. Koitin etsiä tuota artikkelia, mutta en kuollaksenikaan löytänyt sitä.

Siinä oli siis aina sourcen ratkaisevat osat ja sen jälkeen mittaustulokset hienoina graaffeina miten se vaikutti asiaa. Erittäin käyttökelpoista tavaraa mielestäni.

Korjaus, artikkeli siis ei ollut 64 "coresen" koneen artikkeli. Vaan 64 prosessorisen, miten tuo luku sitten saatiinkin kasaan. Mittaukset oli käsittääkseni tehty jollain sunin järeämmällä palvelimella, eikä intel arkkitehtuurilla. Näin ollen esim muistipullonkaulat saattoi olla olenniasesti vähäisemmät kuin X86 vermeissä.

Tais olla UltraSparc T2 alustana tuossa testissä.
« Viimeksi muokattu: 06.02.09 - klo:13.04 kirjoittanut Ux64 »

Storck

  • Vieras
Kuka ostaa ja testaa ensimmäisenä   ???    ;D ;)

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
Tässä paljon teoriaa asiasta. Eikä ongelma ole uusi, tuossa sanotaan että asiaa on tutkittu jo vuosikymmeniä.

http://www.researchchannel.org/prog/displayevent.aspx?rID=24404&fID=345

Olisi muuten kiva tietää miten huolellisesti nämä asiat käydään nykyjään CS opiskelijoiden kanssa läpi.


Vapaan koodin kananmuna

  • Käyttäjä
  • Viestejä: 1536
    • Profiili
Saa olla melko suuret suorituskykyvaatimukset ennen kuin rinnakkaisuutta kannattaa vielä nykypäivänä lähteä toteuttamaan, jos sitä ei saada "ilmaiseksi" tehtyä. Rauta halpa, rinnakkaisuudesta jotain ymmärtävä ohjelmoija kallis.
Epäilisin noiden moniprosessorikoneiden menevän vielä toistaiseksi erilaisiin virtualisointiympäristöihin ja muihin ratkaisuihin, joissa on tarkoitus ylläpitää useampaa toisistaan riippumatonta palvelua samalla koneella.
Siinä vaiheessa kun prosessorien yksittäiset ytimet alkavat hidastua merkittävästi (hiukan epätodennäköistä), jotta niitä saataisiin todella monta samalle kiekolle, muuttuu tilanne ratkaisevasti.
« Viimeksi muokattu: 10.02.09 - klo:15.56 kirjoittanut Vapaan koodin kananmuna »
En Vastaa Vaikeisiin Kysymyksiin.

Asmo Koskinen

  • Käyttäjä
  • Viestejä: 4443
    • Profiili
Saa olla melko suuret suorituskykyvaatimukset ennen kuin rinnakkaisuutta kannattaa vielä nykypäivänä lähteä toteuttamaan, jos sitä ei saada "ilmaiseksi" tehtyä.

Mihin väliin LTSP-viritys putoaa?

Minä olen ollut siinä luulossa, että mitä enemmän prosessoreita ja muistia, niin sen parempi. Tällä hetkellä LTSP:lle kahdeksana prosessorina näyvä i7 vaikuttaa aika mielenkiiintoiselta. Itselläni Linux/LTSP on kaksi palvelinta, neljä/kahdeksan prosessoria ja 6/12 G muistia.

http://www.arkki.info/howto/Wiki/LTSP5-Mantykangas/htop-master.png
http://www.arkki.info/howto/Wiki/LTSP5-Mantykangas/htop-slave.png

Jos Firefox/Flash olisi oikeasti optimoitu tällaiseen ympäristöön, niin kaikki rutina LTSP-käytöstä loppuisi siihen. Ja kun hallitus elvytystoimena vielä vetäisi sen kuidun kodista kouluun ja koulusta kouluun, niin jaa-a.

Ystävällisin terveisin Asmo Koskinen.

Vapaan koodin kananmuna

  • Käyttäjä
  • Viestejä: 1536
    • Profiili
Saa olla melko suuret suorituskykyvaatimukset ennen kuin rinnakkaisuutta kannattaa vielä nykypäivänä lähteä toteuttamaan, jos sitä ei saada "ilmaiseksi" tehtyä.

Mihin väliin LTSP-viritys putoaa?

Mitä enemmän käyttäjiä ytimiä kohti sitä vähemmän tyhjäkäyntiä ja sitä helpommin palvelun laatua voidaan parantaa lisäämällä ytimiä. Sovellusalue (esim. rankka laskenta / kääntäminen silloin tällöin vs. kevyehkö tekstinkäsittely) vaikuttaa myös tietysti jonkin verran.
En Vastaa Vaikeisiin Kysymyksiin.

Ville Pöntinen

  • Käyttäjä
  • Viestejä: 2078
    • Profiili
Mihin väliin LTSP-viritys putoaa?

Minä olen ollut siinä luulossa, että mitä enemmän prosessoreita ja muistia, niin sen parempi. Tällä hetkellä LTSP:lle kahdeksana prosessorina näyvä i7 vaikuttaa aika mielenkiiintoiselta. Itselläni Linux/LTSP on kaksi palvelinta, neljä/kahdeksan prosessoria ja 6/12 G muistia.

Jos Firefox/Flash olisi oikeasti optimoitu tällaiseen ympäristöön, niin kaikki rutina LTSP-käytöstä loppuisi siihen. Ja kun hallitus elvytystoimena vielä vetäisi sen kuidun kodista kouluun ja koulusta kouluun, niin jaa-a.

Mitä enemmän käyttäjiä ytimiä kohti sitä vähemmän tyhjäkäyntiä ja sitä helpommin palvelun laatua voidaan parantaa lisäämällä ytimiä. Sovellusalue (esim. rankka laskenta / kääntäminen silloin tällöin vs. kevyehkö tekstinkäsittely) vaikuttaa myös tietysti jonkin verran.

Tarvitaankos tässä edes FF:n tai muun optimointia useille prosessoreille? Kun joka käyttäjän firefox on kuitenkin oma prosessinsa niin eikös siinä tule usea prosessori hyödynnettyä automaattisesti? (Yhden käyttäjän Firefox ei paljoa kahdeksasta prosessorista hyödy...) Ja samaten se ssh-putkitus, jota LTSP käyttää kuvan/työpöydän siirtoon päätteille.

Vapaan koodin kananmuna

  • Käyttäjä
  • Viestejä: 1536
    • Profiili
Mihin väliin LTSP-viritys putoaa?

Minä olen ollut siinä luulossa, että mitä enemmän prosessoreita ja muistia, niin sen parempi. Tällä hetkellä LTSP:lle kahdeksana prosessorina näyvä i7 vaikuttaa aika mielenkiiintoiselta. Itselläni Linux/LTSP on kaksi palvelinta, neljä/kahdeksan prosessoria ja 6/12 G muistia.

Jos Firefox/Flash olisi oikeasti optimoitu tällaiseen ympäristöön, niin kaikki rutina LTSP-käytöstä loppuisi siihen. Ja kun hallitus elvytystoimena vielä vetäisi sen kuidun kodista kouluun ja koulusta kouluun, niin jaa-a.

Mitä enemmän käyttäjiä ytimiä kohti sitä vähemmän tyhjäkäyntiä ja sitä helpommin palvelun laatua voidaan parantaa lisäämällä ytimiä. Sovellusalue (esim. rankka laskenta / kääntäminen silloin tällöin vs. kevyehkö tekstinkäsittely) vaikuttaa myös tietysti jonkin verran.

Tarvitaankos tässä edes FF:n tai muun optimointia useille prosessoreille? Kun joka käyttäjän firefox on kuitenkin oma prosessinsa niin eikös siinä tule usea prosessori hyödynnettyä automaattisesti? (Yhden käyttäjän Firefox ei paljoa kahdeksasta prosessorista hyödy...) Ja samaten se ssh-putkitus, jota LTSP käyttää kuvan/työpöydän siirtoon päätteille.
Se oli ikäänkuin kirjoituksen pointti, että käyttöjärjestelmätason moniajolla (jos sitä kutsutaan sillä nimellä?) päästään pitkälle noissa tapauksissa.

Nykypäivän selain on kuitenkin ainakin välilehtien osalta helposti säikeistettävissä ja se voidaan viedä jopa "äärimmäisyyksiin", kuten chromen tapauksessa jolloin jokainen välilehti on oma prosessinsa.
En Vastaa Vaikeisiin Kysymyksiin.