[SETI@Home] Clustering

[Verwijderd]

Ik ben me nog aan het verdiepen in clustering, dus don't punish me als ik een verkeerde aanname maak
Clustering staat nog in de kinderschoenen. Wat betreft het clusteren van data gaat het al de goede kant op. Het is volgens mij nog steeds erg moeilijk om met, bijvoorbeeld, een PIII 500Mhz, PII 360Mhz en een PIV 2,4Ghz aan hetzelfde stuk te rekenen en de resultaten te combineren (vanwege de erg verschillende architecturen). Het kan wel, maar de software moet erg goed weten wat er gebeurd.

Met veel seti-software kan je sparen, ed. Weet een van jullie of het ook mogelijk is om één paketje te laten berekenen door meerdere, qua architectuur afwijkende, PC's?

[TFHfony]

Verwijderd schreef op 25 juli 2003 @ 21:47:
Ik ben me nog aan het verdiepen in clustering, dus don't punish me als ik een verkeerde aanname maak
Clustering staat nog in de kinderschoenen. Wat betreft het clusteren van data gaat het al de goede kant op. Het is volgens mij nog steeds erg moeilijk om met, bijvoorbeeld, een PIII 500Mhz, PII 360Mhz en een PIV 2,4Ghz aan hetzelfde stuk te rekenen en de resultaten te combineren (vanwege de erg verschillende architecturen). Het kan wel, maar de software moet erg goed weten wat er gebeurd.

Met veel seti-software kan je sparen, ed. Weet een van jullie of het ook mogelijk is om één paketje te laten berekenen door meerdere, qua architectuur afwijkende, PC's?

Nee, deze software is er niet. De client die namelijk het echte rekenwerk verricht is niet open source. Alleen Berkeley zelf brengt hier verschillende versies van uit en die heeft zelfs geen versie uit die meerdere threads, dus meerder processoren ondersteund...

[Verwijderd]

Kan me voorstellen dat het voor clustering erg moeilijk is om te maken. Multi-processor of hyperthreat ondersteuning moet wel te maken zijn.

Waarom zouden ze dat niet gedaan hebben? Vanwege het wedstrijdelement? Te weining geld of tijd? Of toch te moeilijk?

Ze zouden er toch erg veel voordeel bij hebben zou ik zo denken... Maar tja, denken, dat moet ik misschien niet doen :-)

[Sequence]

hoe groot zou het voordeel zijn? alle processoren een losse client is toch net zo efficient?

[Verwijderd]

Sequence schreef op 26 July 2003 @ 00:20:
hoe groot zou het voordeel zijn? alle processoren een losse client is toch net zo efficient?

weet het wel zeker dat dat zo is.. heb de sgi eens geprobeert als een cluster te laten draaien.. net zosnel als gewoon elke cpu zijn eigen client geven

[Adm.Spock]

Verwijderd schreef op 26 July 2003 @ 00:27:
[...]


weet het wel zeker dat dat zo is.. heb de sgi eens geprobeert als een cluster te laten draaien.. net zosnel als gewoon elke cpu zijn eigen client geven

Inderdaad! In principe is elke processor z'n eigen client geven clustering. Immers iedere client rekent een stukje van de data uit. Eigenlijk zijn DC-projecten (zoals Seti) Megaclusters

[Verwijderd]

Ja, oke. Maar ik wil tijdswinst pakken door alles proberen te laten draaien zodat de software denkt dat er 1 cpu rekend van bijvoorbeeld 3,233Ghz, terwijl het er drie zijn (opgeteld 500Mhz, 2,4Ghz en 333Mhz). Dan zou het nogal wat uitmaken. Alleen is bijna onmogelijk omdat de software erg intteligent moet zijn en er zulk verschillende architecturen zijn.

[TFHfony]

Ach, het zou al beter zijn als Berkeley gewoon geoptimaliseerde clients had gemaakt.
Waar een WU nu op een P4 3Ghz rond de 2 uur zit, zou deze als de client specifiek voor die processor was gemaakt hem binnen een uur afwerken.

De clients zijn gemaakt in een generieke programeertaal en daarna voor de verschillende procesoren en OS-en gecompileerd met maar hele lichte optimalisaties. Hierdoor gaan er veel CPU cycles verloren.
Wie herinnert zich de Microsoft client nog?? Microsoft had dmv reverse engineering zelf een geoptimaliseerde Wintel client gemaakt. Ging in een noodgang door de WU's heen. Berkeley accepteerde het alleen niet omdat het zelf de controle over de clients wou houden.

Iedereen die seti draait, gooit dus eigenlijk iets van 2/3 van zijn CPU cycles de prullenbak in... Maargoed, niet bij stilstaan en doorgaan. En vooral hopen hopen dat ze met BOINC het iets professioneler aanpakken.

[Verwijderd]

Tja, hopelijk doen ze dat. Maar de creatie van die clients zou wil aan de financiering liggen, ed.

Dus of dat ook goed komt...