Boinc & SMP

[SandStar]

Ik loop mezelf al een tijdje te ergeren aan Boinc en de hun "implementatie" van SMP. Of eigelijk het gebrek daaraan.

Boinc heeft eigelijk geen echte SMP implementatie: er worden gewoon diverse workunits tegelijk gestart. Hoewel dit een vrij simpele oplossing is zie ik nu wel dat het ram verbruik drastisch toeneemt aangezien elke workunit weer zn eigen geheugen claimed.

Als we even voor het gemak uitgaan van een workunit dat 100mb ram verstookt valt dit nog wel mee op een dualcore systeem (200mb). Maar op 4, 6 of 8 core machines begint het toch aardig op te lopen. Als je er over na gaat denken is het eigelijk verspilling. Tevens zijn we al jaren bezig met een trend naar steeds meer cores wat het probleem alleen maar groter maakt. En nergens wordt men aangemoedigd om "echte" multi-threaded applicaties te maken; volgens mij is dat zelfs onmogelijk binnen Boinc.

Na wat speurwerk op alle Boinc projecten en het Boinc forum zelf krijg ik niet het idee dat men van dit ontwerp wil afstappen.

Wat vinden jullie hiervan? Ik krijg zelf bij Boinc een beetje een "My first Sony DC project" gevoel. Mede door dit soort dingen.

[nickb90]

ik begin me ook langzaam te irriteren aan BOINC, ben ermee begonnen oooit met rosetta en toen overgestapt naar OGR en sindsdien irriteer ik me nog meer aan BOINC. OGR had zo'n 10 MB RAM nodig op mijn i7 (8 pakketjes dus), met BOINC haal ik ruim 800MB RAM! voor de stampede draai ik boinc weer maar na de stampede snel weer weg van die logge client.

Ik denk dat als boinc niets wil veranderen dat meer mensen dat gaan doen.. gezien de hoeveelheid cores die iedereen begint te krijgen..

[DigiK-oz]

In de recentere versies van BOINC is er inmiddels wel ondersteuning voor multi-core. Een project kan per WU aangeven hoeveel cores en/of GPU er ingezet moeten worden. Project AQUA@Home is momenteel (dacht ik) de enige die ook multithreaded apps heeft. Maar de implementatie in BOINC is nog bepaald niet optimaal, met name als je meerdere projecten draait waarvan er 1 multithreaded en de rest singlethreaded is.

[ Voor 20% gewijzigd door DigiK-oz op 21-03-2010 15:18 ]

[Verwijderd]

Toen ik begon met DC was ik inderdaad ook wel verrast. Wat ik eigenlijk verwachtte was dat er een applicatie zou draaien die multi-threaded alle cores zou gebruiken. Dat bleek alleen niet zo te zijn.

Maar toen ik er wat beter bij nadacht was het ergens ook wel logisch in de zin van complexiteit. Echt efficiënt multithreaded applicaties schrijven is helemaal niet zo makkelijk en redelijk complex - en daarom ook gevoeliger voor fouten. En dan moet je nog maar eens zien dat je ook alle processoren volledig belast. Het systeem zoals het nu is is veel simpeler. Alle processoren kunnen volledig worden belast. Het is eenvoudig. Je kunt makkelijk switchen tussen meerdere applicaties tegelijk. En het geheel is makkelijker te controleren.

Dus ja, waarom zou je het complexer maken dan nodig is en alle programmeurs van DC projecten multithreading opdringen, terwijl dat niks meer oplevert in de zin van gebruik van je processoren - waar het uiteindelijk om gaat? Het enige mogelijke probleem is wellicht inderdaad geheugen gebruik. Maar daar zijn natuurlijk ook eenvoudigere oplossingen voor.

Zoals ik het begrijp is het nu al zo dat projecten vaak proberen gebruikers WU's te sturen die zoveel mogelijk gezamenlijke libraries en datapakketjes gebruiken om zo het dataverkeer zoveel mogelijk te beperken. Dit kan natuurlijk ook voor geheugen gebruik, door een grote voorkeur op te leggen voor tegelijkertijd programma's op de verschillende cores te draaien die deels gebruik maken van de zelfde libraries.

Op zich zou ik het wel fraai vinden als de DC projecten ook zelf de mogelijkheid te krijgen om wel multithreading te gebruiken in BOINC en zo met 1 applicatie alle cores te belasten. Die mogelijkheid is er voor sommige projecten wel, zie maar het gebruik van CUDA. Maar ik zie geen reden om dat overal op te leggen. Bijvoorbeeld omdat ook niet alle projecten zich daar evenveel voor lenen.

[DukeBox]

Helaas is het niet alleen met BOINC zo, de meeste DC clients kiezen voor de makkelijkste weg. Maar wat is eigenlijk het doel van dit topic ?
Het 'my first sony' gevoel bij BOINC heb ik al als ik naar de stats mogelijkheden (of eigenlijk, het gebrek aan) kijk..

[Xaverius]

nickb90 schreef op zondag 21 maart 2010 @ 14:55:
ik begin me ook langzaam te irriteren aan BOINC, ben ermee begonnen oooit met rosetta en toen overgestapt naar OGR en sindsdien irriteer ik me nog meer aan BOINC. OGR had zo'n 10 MB RAM nodig op mijn i7 (8 pakketjes dus), met BOINC haal ik ruim 800MB RAM! voor de stampede draai ik boinc weer maar na de stampede snel weer weg van die logge client.

Ik denk dat als boinc niets wil veranderen dat meer mensen dat gaan doen.. gezien de hoeveelheid cores die iedereen begint te krijgen..

Dat is een wat kromme vergelijking. De wiskundige projecten zijn over het algemeen redelijk beperkt in RAM-gebruik in vergelijking met medische projecten. Je kan ook geen appels met meloenen vergelijken ondanks dat het allebei fruit is. BOINC zelf neemt niet zoveel ruimte in, ik zit net boven de 10 MB. De twee Einstein WU's die op deze PC draaien gebruiken allebei ongeveer 150 MB RAM. Ja, dat is vergeleken met distributed.net veel maar er moet ook veel meer data doorgerekend worden.

[ Voor 13% gewijzigd door Xaverius op 21-03-2010 18:07 ]

[m_p_g]

SMP en Boinc gaan wel degelijk samen, met Aqua als voorbeeld. Vanwege de complexiteit en/of resources zal het tijd vergen voordat er meerdere projecten hiermee kunnen en/of zullen draaien. Niet elke applicatie leent zich even goed om te parallelliseren.

Het groeien van het geheugen gebruik van WU's loopt echter in de pas met de groeiende systeemeisen van de huidige Operating Systemen. Je wilt Windows Vista of 7 ook niet meer draaien met 256 MB geheugen, waarmee Windows 2000 nog prima mee uit de voeten kan.

Het is en blijft een kwestie van afwegen om wel of niet gebruik te maken van de nieuwe technische mogelijkheden en te kijken naar de systemen die de gemiddelde Boinc user op een zeker moment in gebruik heeft en in wil zetten. Dat de software ontwikkeling daarbij achter loopt op de hardware is een bekend gegeven.

[_Sunnyboy_]

Persoonlijk vind ik de BOINC aanpak voor multi-processing wel pragmatisch. Het is een uitruil tussen geheugengebruik en het aanpassen van de (vaak al complexe) science-applicaties voor SMP, voor zover dit al mogelijk is. Bij de meeste projecten zal een dergelijke investering niet rendabel zijn, zeker gezien de prijzen van geheugen.

Daarnaast gaat het toch om het zo snel mogelijk af krijgen van alle workunits, niet om het zo snel mogelijk afkrijgen van één specifieke workunit? Of je nou 8 workunits in parallel hebt draaien (zoals in Boinc) die met z'n allen in 8 uur klaar zijn, of dat je mbv SMP elke workunit met 8 processors in 1 uur klaar hebt, uiteindelijke heb je na 8 uur toch 8 workunits klaar welke aanpak je ook kiest (er vanuitgaande dat de SMP implementatie 100% effectief is, wat niet echt realistisch is. In feite zal je in het SMP scenario minder dan 8 workunits af hebben omdat werken met 8 cores in SMP meestal niet 8x zo snel is).

Daarnaast, als je een compu kan betalen die 8 threads aan kan, dan stop je er toch ook voldoende ram in (3x 2GB in een i7?) . Ik moet het doen met een simpele dual core dus is doe het met 4GB, waarvan op dit moment 80MB in gebruik voor 2 workunits

[SandStar]

DukeBox schreef op zondag 21 maart 2010 @ 17:29:
Helaas is het niet alleen met BOINC zo, de meeste DC clients kiezen voor de makkelijkste weg. Maar wat is eigenlijk het doel van dit topic ?
Het 'my first sony' gevoel bij BOINC heb ik al als ik naar de stats mogelijkheden (of eigenlijk, het gebrek aan) kijk..

Doel is een beetje te algehele stemming over het onderwerp te peilen. Ik ben gewoon erg benieuwd wat andere DPC'ers er over te zeggen hebben.

m_p_g schreef op zondag 21 maart 2010 @ 19:42:
SMP en Boinc gaan wel degelijk samen, met Aqua als voorbeeld. Vanwege de complexiteit en/of resources zal het tijd vergen voordat er meerdere projecten hiermee kunnen en/of zullen draaien. Niet elke applicatie leent zich even goed om te parallelliseren.

Het groeien van het geheugen gebruik van WU's loopt echter in de pas met de groeiende systeemeisen van de huidige Operating Systemen. Je wilt Windows Vista of 7 ook niet meer draaien met 256 MB geheugen, waarmee Windows 2000 nog prima mee uit de voeten kan.

Aqua ziet er inderdaad een stuk beter uit. Ik hoop dat deze manier wat meer gepushed wordt in de Boinc omgevingen. Wellicht dat WCG hier een mooie rol in zou kunnen vervullen. Dat is toch een wat groter project met een speler (IBM) erachter die wel voor input zou kunnen zorgen.

De opmerking over het groeiende aanwezige geheugen in pc's gaat maar deels op. Ja je kunt nu inderdaad veel makkelijk meer ram in je pc gooien maar voor de meeste taken is >4GB niet nodig.
En als we straks 6 core cpu's krijgen met HT heb je dus 12 cores. Boinc zou dan voor bijvoorbeeld Einstein@home 12 x 150mb = 1800mb ram in gebruik nemen. Dat vind ik nogal wat.
Effectief programmeren zou dus een besparing van 1650mb ram opleveren.

[Bastiaan V]

SandStar schreef op zondag 21 maart 2010 @ 21:37:
[...]


Doel is een beetje te algehele stemming over het onderwerp te peilen. Ik ben gewoon erg benieuwd wat andere DPC'ers er over te zeggen hebben.


[...]


Aqua ziet er inderdaad een stuk beter uit. Ik hoop dat deze manier wat meer gepushed wordt in de Boinc omgevingen. Wellicht dat WCG hier een mooie rol in zou kunnen vervullen. Dat is toch een wat groter project met een speler (IBM) erachter die wel voor input zou kunnen zorgen.

De opmerking over het groeiende aanwezige geheugen in pc's gaat maar deels op. Ja je kunt nu inderdaad veel makkelijk meer ram in je pc gooien maar voor de meeste taken is >4GB niet nodig.
En als we straks 6 core cpu's krijgen met HT heb je dus 12 cores. Boinc zou dan voor bijvoorbeeld Einstein@home 12 x 150mb = 1800mb ram in gebruik nemen. Dat vind ik nogal wat.
Effectief programmeren zou dus een besparing van 1650mb ram opleveren.

dat gaat niet op, we zijn nu met veel grotere datasets bezig, en dan kan je kiezen, inladen in mem, of op disk laten staan met alle io van dien...

[SandStar]

Bastiaan V schreef op maandag 22 maart 2010 @ 16:52:
[...]


dat gaat niet op, we zijn nu met veel grotere datasets bezig, en dan kan je kiezen, inladen in mem, of op disk laten staan met alle io van dien...

Errr ik geloof dat ik je niet helemaal volg.

Ik doel op het feit dat je effectiever met je resources omgaat als je op een quad met 4 threads aan 1 workunit werkt dan simpelweg 4 workunits laden. Met dat laatste laad je dus 4x zoveel ram voor ruwweg dezelfde performance.

[Bastiaan V]

SandStar schreef op maandag 22 maart 2010 @ 16:56:
[...]


Errr ik geloof dat ik je niet helemaal volg.

Ik doel op het feit dat je effectiever met je resources omgaat als je op een quad met 4 threads aan 1 workunit werkt dan simpelweg 4 workunits laden. Met dat laatste laad je dus 4x zoveel ram voor ruwweg dezelfde performance.

I stand corrected

[Xorsist]

De performance is niet hetzelfde want je hebt zodra je gaat multithreaden te maken met overhead welke naarmate er meer simultane threads lopen ook verder oploopt. We krijgen binnenkort 6 core 12 thread Intels en 6 en 12 core AMD's en dan ga je echt dat verschil wel merken.

Als je 4 afzonderlijke apps start binnen je boinc zul je inderdaad 4x de hoeveelheid geheugen gebruiken maar wel 4x zo snel zijn als 1x diezelfde app. Daarentegen zul je door de overhead welke inherrent is aan multithreaden op bijvoorbeeld 3,8x zo snel uitkomen. Ga je dit verder doorprojecteren op de eerder genoemde nieuwe Intel en AMD processors dan kun je zo maar het werk van een halve tot een hele core/thread kwijt raken aan overhead. Dit kan dus op dag of maandbasis aardig in de puntjes gaan lopen welke je mist

Geheugen kost tegenwoordig bijna niets meer dus is de simpelste en meest efficiënte (processorcycle gewijs) oplossing om meerdere apps naast elkaar te draaien.

[AtHomer]

Ik draai zelf 64 bit Linux. Als er een applicatie 2 GB geheugen op zou nemen van de 4 die ik in totaal heb, dan heb ik daar geen enkel probleem mee. Enige probleem daarmee zou ik hebben op het moment dat ik VMWare opstart, maar dan gaat Boinc sowieso uit.

[Verwijderd]

Voor DC lijkt me single threaded WU's toch ook effectiever en datageheugen delen tussen 4 threads zal de performance nogal de das om kunnen doen.
Geheugen genoeg maar toch 160 MB voor een EAH WU-tje is nogal wat.
Moeilijk in te schatten hoeveel data er in het geheugen moet staan voor de reken- en vergelijkingsinstructies maar vermoed dat de programmeurs van BOINC-projecten hun code best wel eens wat mogen optimaliseren.

[DigiK-oz]

Optimalisatie is wel eens nodig, ja. Ik had ooit eens 8 WU's tegelijk draaien van Lattice, en die vraten gemiddeld 750 MB aan memory

Bij AQUA lukt het vrij aardig om 8 CPU's aan de gang te houden, met iets van 80MB aan geheugen. Dat heb ik dan toch wel wat liever, hoewel ik redelijk ruim in mijn geheugen zit met 12 GB

Nou kan je projecten niet vergelijken, maar naar mijn idee is de overhead bij multi-threaded programma's niet per definitie erg groot. Als alle threads onafhankelijk van elkaar draaien, kan die overhead zelfs bijna 0 zijn. En als een WU 80MB geheugen gebruikt, zie ik liever 8 threads die elk 10MB verwerken, en dus de WU in 1/8 van de tijd afwerken, dan 8 WU's/processen die elk hun eigen 80MB vreten.