Distribuovane pocitani v Perlu?

[Jan Kasprzak]

	Prijemny patek preji,

mam dotaz ohledne paralelniho pocitani v Perlu: mam problem, ktery by sel
idealne resit na vypocetnim klastru: jde o to, ze data problemu se nevejdou
do pameti jednoho "bezneho" pocitace, a pritom problem je docela dobre
paralelizovatelny. Mel jsem single-threaded prototyp v Perlu, chodil
docela rozumne rychle, nez vytekl z RAM. Ale je navic paralelizovatelny,
takze by mohl chodit n-krat rychleji. No a ted jde o to, ze bych
chtel vedet, jestli existuje nejaky modul, ktery by mi usnadnil
programovani takoveto veci, abych nemusel vsechna ta socketova volani
delat rucne.

	Co bych potreboval:

- jeden ridici stroj, n pracovnich uzlu klastru
- nejaka komunikace uzlu s ridicim strojem,
- ale zejmena potrebuju aby kazdy uzel mel otevreny socket s kazdym dalsim,
	protoze algoritmus v jiste fazi vyzaduje takovouto komunikaci
	kazdeho s kazdym.
- nejaky prikaz pro synchronizaci/setkani ("pockam az vsichni dobehnou sem").
- vetsinou pujde o zasilani malych kousku dat, ale v zaverecne fazi
	bude kazdy uzel posilat rekneme az gigabajt dat ven,
	cili potrebuju nejak umet poslat (treba) obsah souboru,
	aniz by nejaka ta paralelni knihovna se snazila ten obsah
	treba zabalit do Perloveho skalaru nebo nedej $deity jeste
	nejak dal kodovat. Pokud by v teto fazi byla pouzita sluzba
	jadra sendfile(), bylo by to uplne idealni (skutecne pujde
	o obsah souboru).
- uzly klastru budou mit stejnou architekturu, stejny OS (Linux), stejnou
	verzi jadra, knihoven i Perlu, neni treba nejake kodovani
	dat kvuli jine sirce slova nebo jine endianite.
- nepotrebuju uplne resit vsechny mozne vypadky. Moje predstava je ze
	vypocet pobezi jako periodicka uloha (rekneme po par minutach)
	s tim, ze kdyz uzel v prubehu vypoctu spadne, tak se holt pristi
	beh spusti uplne odznovu na mensim poctu stroju.

Co byste doporucili? Parallel::MPI? Parallel::Mpich? Rucni praci
se sockety? Nebo?

	Diky,

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
>> Rule #1 in kernel programming: don't *ever* think that things actually <<
>> work the way they are documented to work.             --Linus Torvalds <<