On Mon, 2001-09-24 at 14:01, Ionel Mugurel Ciob=EEc=E3 wrote:
>=20
> =CEn data de 24/09/2001, 23:51:54, Codrut Racosanu a scris:
> >=20
> > Io, ca un absolut venit de la tzeara in materie de computere altfel dec=
at pc
> > si mac, stateam si ma intrebam... "oare dragalasenia care dirijeaza dit=
amai
> > tomograful este un Silicon Graphics dedicat? ori doar ruleaza on top
> > aplicatia?" Nu de alta, dar ala a costat, cica, vreo cateva miliarde bu=
ne -
> > si tare as fi curios de ce treaba tomografului aluia e musai de facut d=
e un
> > SGI...full options, din cate am fost lasat sa vad...
Pai asta-i smecheria. Latenta mica si bandwidth ca la balamuc. :)
E o coincidenta semnificativa, care nu e, de fapt, coincidenta, intre
faptul ca exista trei tipuri de probleme numerice, si trei tipuri de
supercalculatoare.
1. Probleme ne-paralelizabile
La astea, orice pas al problemei este complet dependent de pasi
anteriori. Aproape orice ai face, trebuie sa treci prin tot cirnatul ca
sa obtii orice fel de rezultat.
Exemple - unii algoritmi care trateaza anumite cazuri de traiectorii in
cimpuri de forte neomogene (din cite am inteles, cind au pus Apollo pe
Luna, asa ceva au avut). O jucarie de algoritm cu care ma distram prin
liceu si prin facultate tot asa era.
2. Probleme complet paralelizabile
Orice pas al problemei este complet independent de ceilalti pasi. Poti
rezolva orice bucata complet independent de restul.
Exemple - sinteza video. Cind au facut Final Fantasy, asa ceva au
folosit; fiecare imagine se poate randa complet independent de
celelalte.
3. Probleme partial paralelizabile
Pasii problemei, macar unii din ei, depind macar partial de alti pasi.
Exemple - diverse aplicatii de mecanica cuantica si simulari de molecule
(Mugurel, poate stii tu mai bine), predictia vremii, etc. In general, cu
cit te duci mai in jos spre nivelul cuantic, si cu cit intri mai adinc
in teoria haosului, cu atit ai sanse mai mari sa dai peste algoritmi
d-astia.
Problemele de tipul 1, orice ai face, trebuie sa le rezolvi pe masini
uniprocesor foarte rapide, eventual dedicate. De-asta a aparut Cray,
care nu stralucesc prin numarul de procesoare dintr-o masina, dar atitea
cite au, sint _extrem_ de rapide. De fapt, Cray-urile nu prea seamana cu
ideea de calculator asa cum o stim noi, sint mai mult "pompe de biti",
cu arhitectura dedicata.
Problemele de tipul 3 le poti sparge in subprobleme si sa le torni prin
retea intr-un cluster de Linux-uri, si fiecare nod sa rontaie fericit
felia lui.
Problemele de tipul 2, teoretic, le poti rezolva pe clustere in retea.
Dar, din cauza ca ai nevoie sa trimiti rapid informatie intre noduri (nu
doar la sfirsitul ciclului, ca la problemele tip 3, ci de mai multe ori
in acelasi ciclu de calcul), latenta te omoara. Vrind-nevrind, trebuie
sa comunici mai rapid decit poate reteaua (_orice_retea_). Singurul mod
viabil sa faci asta este sa ai toate nodurile (=3D toate procesoarele) in
aceeasi masina, si sa trimiti informatia prin memorie partajata,
semnale, etc., NU prin retea.
In principiu, cu smecherii gen Beowulf sau Mosix poti simula prin retea
masini cu multe procesoare, dar asta nu elimina problema latentei, doar
o ascunde.
Asta e "nisa ecologica" pe care a umplut-o SGI: masini cu extrem de
multe procesoare, cu bandwidth intern mare si latenta mica. Daca ce faci
tu implica probleme de tipul 2, si vrei sa nu astepti un an pina se
termina simularea, ai nevoie de asa ceva. Daca nu, nu.
> Florine, tu nu esti la vinzari, dar poate stii, am voie sa zic
> (mai ales pe liste de discutii) cit costa un Origin300 cu 4,
> 6 sau 8 procesoare, mai ales ca tocmai acum s-a lansat?
Heh, nu cred ca "nu e voie".
Oricum, chiar de n-ar fi, iti zic eu ca n-o sa te caute nici un
meninblec. ;-)
--=20
Florin Andrei
"The other night I suddenly found myself looking at the kernel debugger
which, I must say, I don't like looking at." - Sune Molgaard
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
