[Java lista] Parallel computing

[Molnár Miklós]

Hali,
 

Na akkor némi feedback, ha már ennyi infót kaptam. Remélem sikerül
tartózkodnom nagy baromságok leírásától. :o)


1.
>>>>>>>>>>>>>>>>
http://en.wikipedia.org/wiki/List_of_distributed_computing_projects#Custom.2
FUncategorized_Platforms
http://boinc.berkeley.edu/
>>>>>>>>>>>>>>>>

Ezzel az a baj, hogy én pont a fordítottját céloztam meg, már ha jól értem
az üzenetet. Nem a saját itthoni gépem közösbe adása az elsődleges cél egy
más által már definiált projekthez. Hanem pont, hogy én szeretnék definiálni
projekte(ke)t és ezekhez vonódnának be gépek, amik feltételezés szerint
rendelkezésre állnának.


2.
>>>>>>>>>>>>>>>>
http://gridcafe.eu-egee.hu/
http://www.eu-egee.org/
http://egee.ik.bme.hu/ 
>>>>>>>>>>>>>>>>

Ezzel meg az látszik problémásnak, hogy mások EU-ban szétszórt gépeit
lehetne használni (amit ugyan nagyon finom módon adminisztrálnak is,
gridileg), csak ez alapvetően (1)kutatási célokat szolgál, (2)biztottság
vizsgálja, hogy  ki, hogyan, miképp csatlakozhat rá, és az (3)alkalmazásnak
nagyon szigorú kritériumoknak kell megfelelnie, és ráadásul (4)az én egész
problémafelvetésem üzleti orientációjú/motivációjú.

Van még egy kőkemény security probléma is, ami napközben jutott eszembe, de
ez nem csak ide vonatkozik. Egy TOR-nál (www.torproject.org) én is meg
mindenki elhiszi hogy az adott résztvevő számítógépen semmilyen módon nem
reverse enginelhető semmi információ hiába ül mögötte akár a legokosabb
ASVA-s ember is. Az én problematikámban viszont hiába obfuszkált a kód,
hiába közlekedik kódoltan az adat, előbb-utóbb kicsomagolódik a memóriában a
cucc és az már lehallgatható. Hogy ha például egy wav-állomány voice
miningjáról beszélünk egy deperszonalizálás közel sem triviális feladat,
illetve egy banknak nagyon nehéz bitang stabil garanciát adni, hogy érzékeny
adat véletlenül sem kerül ki. Gondolom Iván is valami ilyesmire utalhatott
"Gond viszont a konzervatív biztonsági szemlélettel való komoly
ütközés."-mondattal.


3.
>>>>>>>>>>>>>>>>
http://hadoop.apache.org/core/ 
>>>>>>>>>>>>>>>>

Előnyök/Hátrányok:

+ Na ez eddig a legígéretesebb, ráadásul open-source.

+ Ez már setupolható egy bankban is.

+ A lényeg megvan, azaz akárhány gép bevonható a számításba. 

+ Számomra a legszimaptikusabb Google Map/Reduce algoritmust implementálja. 

+ Több programozási nyelvből elérhető. 

+ Szabványos, amit a referencia miatt könnyebben elfogadnak a potenciális
akár banki megrendelők. 

+ Baromira tetszik az implementált HDFS(=Hadoop Distributed FileSystem), ami
nagyban hasonlít/koppintott a Google infrastrukturájáról, ami lássuk be nem
kicsit professzionális és hatékony. :o)

- Viszont a CUDA/ATI STREAM/OPENCL-típusú videókártyás metódust abszolúte
nem támogatja azzal külön kell(ene) foglalkozni. Mivel mostanság már akár
1000 stream-processzor is lehet egy videókártyán, baromi gyors DDR5
memóriával ezért nem szívesen kukáznám a szempontot.

- Illetve én kicsit rugalmasabb és merészebb platformot álmodtam meg, az
persze nincs meg ebben. Az is kérdés, hogy a szabványosság, HDFS, Map/Reduce
bír-e akkora előnnyel hogy ejtsem az én speciális lila ködben fogant
hagymázasan fantaszta víziómat (ami egyik megközelítésben egyszerűbb,
elemibb célokat fogalmaz meg, más megközelítésben meg pont hogy
nehezebbeket). Nyílván a hadoop-ban elérhető finomságok nagyon jók és
fontosak, viszont így első ránézésre kiegészíteni más fikcsikkel semmiképpen
nem tűnik triviálisnak. Önmagában már az nem semmi, hogy tömörítve 42Mb az
Apache-cucc.


4. 
>>>>>>>>>>>>>>>>
És akkor pár apróság:
>>>>>>>>>>>>>>>>

>a kérdés csak az, milyen munkával tudja azt ellátni.

Igen, valóban nem McDonaldsról beszélünk. :o) 

És nem is adatbázis alapú gridről, mert hiába drága egy Oracle Grid,
garázsfejlesztésben reimplementálni őt valószínüleg nem kéne. ;) 

Itt akár O(n^4)-ben műveletekről beszélünk. Ahol rekordokszinten is milliók
lehetnek, és attribútumszinten is akár ezres nagyságrend is elképzelhető,
sor-oszlop transzformációk révén brute force módon elszaporodó attribútumok
révén. Ha valakinek van idegrendszere hozzá, akkor ellátogathat a
legfrissebb KDDCup2009-es (France Telecom pénzdíjas) verseny oldalára. Ahol
pár napja lezárult versenyszakaszban az volt a feladat, hogy sokezer
attribútum alapján kellett öt napon belül prediktálni. /BTW: Imádtam volna a
feladatot, ha nem az ötödik napon a lejárat elött négy órával vettem volna
hírét a versenynek./

Az sem cél, hogy folyamatosan csúcsra járatott legyen a grid. Amikor
csúcsterhelés van, akkor lehessen bevonni gépeket.

Az öngyógyuló elosztott adatbázis nagyon jó téma, érdekes volt belegondolni,
de tárgyunk témáján most sajnos - vagy más szempontból hálistennek :o) -
kívülesik.

Nem PhD a cél. ;) Hanem egyszerű(?) köztes réteg specifikálása és
implementálása a régóta meglévő információk és lehetőségek alapján, vagy
esetleg meglévő eszközhöz való alkalmazkodás. Továbbra is feltéve, hogy van
az egésznek értelme és realitása.

Nyílván van mit bőven kutatni. Így érzésre és némi utánaolvasás után például
egy CUDÁS-s és egy grides erőforrás-allokálás és -felhasználás
transzparenssé tétele nem éppen triviális feladatnak néz ki.

MM