[Java lista] Parallel computing

Kristof Jozsa kristof.jozsa at gmail.com
2009. Ápr. 24., P, 08:01:01 CEST


ezt nezd meg, segithet: http://hadoop.apache.org/core/

K

2009/4/24 Molnár Miklós <timortinj at freemail.hu>

> Sziasztok,
>
> Ma reggel a tárgybeli problémával ébredtem. Talán egy pénteki levlistás
> hozzászólás kereteibe belefér a vázolása.
>
> A problémát indukáló téma: nagy számításigényű adatbányászati algoritmusok.
>
> A problémát inspiráló téma: valós és sikeres seti at home projekt vagy
> prímfelbontásos projektek.
>
> A probléma megnevezése: univerzális keretrendszer párhuzamos számításokhoz.
>
> A keretrendszer komponensei (egy általam elképzelt vezióban):
> - Egy feladatot lebontó és eredményeket aggregáló szerver, ez projektenként
> mindig külön-külön implementálandó.
> - Egy feladatszeleteket kiosztó és eredményeket begyűjtő (adminisztráló)
> egység/szerver (innentől indulna lefelé az univerzális keretrendszer)
> - Vékony(szerver általat "pusholt" működésű) vagy vastag(előre "egyenrangú"
> telepĂ­tett) kliensek.
>
> A keretrendszer triviális alapfeladatai lehetnek:
> - Van-e szabad elérhető erőforrás - adott egységnyi processzor+memória
> (lekérdezés)
> - Kliensenként mennyi feladat indítható (egyeztetés)
> - Szerver1: feladat kiosztása és ennek leadminisztrálása
> - Szerver2: eredmény begyűjtése és ennek leadminisztrálása
> - Kliens feladafogadás (adat+végrehajtandó kód), -végrehajtás
> (értelemszerűen) valamint output-küldés.
>
> MJ: a kliens fogalmat kétféle értelemben használom. Egyfelől úgy tekintek
> rá, mint aki elvégzi a neki dedikált részfeladatot, másfelöl telepített
> programot jelent, ami kommunikál az alacsonyabb szintű szerverrel. Ilyen
> értelemben lehetséges azonosítani "logikai kliens"-t (egy
> nyolcprocesszor(mag)os gépen nyolc ilyen logikai egység lehet, ugye) és
> "fizikai kliens"-t (ami hardver + opcionális kliens program zárt egysége)
>
> "CPU" erőforrásfajták:
> - Szál (ezt akár ignorálhatom is, csak a teljesség kedvéért írtam)
> - Processzormagok
> - NVidia CUDA, ATI Stream, OpenCL típusú grafikuskártya-erőforrások
> - Grid ("új/szűz" gép, telepített oprendszerrel és opcionálisan telepített
> kliens programmal.
> - P2p kötelező klienssel (megszállott alkalmazott otthoni gépének
> erőforrásait is be tudja integrálni a projektbe)
> - Egyéb????
>
> Kérdéseim:
> - Életszerű-e a problémafelvetés vállalati környezetben? Szerintem security
> oldalról teljesen rendben van a dolog még p2p/internet verzió esetben is.
> - Sci-fi fantazmagĂłria a koncepciĂł?
> - Esélyes-e/életképes-e/Jó-e az egész elgondolás? Pláne és elsősorban open
> source alapon. Például Oracle Grid, semmiképpen nem opció költségigénye
> miatt.
> - Univerzalizálható-e egy többszálú működés és egy p2p-működés? E téren
> vannak aggályaim, és ekkor inkább a többszálú működést és/vagy a grafikus
> kártyás mókákat dobnám ki. Vagy rosszul gondolom?
> - Implementálható-e egy ilyen keretrendszer?
> - Mekkora meló? Én valamiért úgy érzem annyira tragikusan nem nagy a
> várható
> előnyökhöz viszonyítva (és főleg akkor, ha évekig nem lesz ilyesmire
> esély).
> Az igazán nagy feladat a feladatlebontásokban és aggregálásokban van,
> ismerve az adatbányászati algoritmusok nehézkességét (pl.:svm=support
> vector
> machine)
> - Van-e már ilyen, látszik-e ilyen kifejlődni a közeljövőben szerintetek?
> - Mennyire eliminálható az elképzelésből a vastag kliens?
> - Mennyire megoldható, hogy a vastag klienst ne kelljen projektenként
> programozni (tudja fogadni a szervertől a végrehajtandó feladat
> algoritmusának implementációját)?
>
> Megköszönve _minden_ észrevételt:
> MM
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20090424/feaf7ef0/attachment.html 


További információk a(z) Javalist levelezőlistáról