Autor: Andrzej Lewandowski (lewando_at_ibm.net)
Data: Tue 03 Mar 1998 - 01:42:00 MET
Krzysztof Halasa <khc_at_intrepid.pm.waw.pl> wrote:
>lewando_at_ibm.net (Andrzej Lewandowski) writes:
>To rzeczywiscie te programy musza bardzo intensywnie korzystac
>z pamieci - biorac pod uwage, ze kazdy CPU ma kilkaset KB (bo to tylko
>Intel) cache, to w zasadze te programy musza caly czas cos zapisywac,
>nic innego prawie nie robiac. Bo w innych warunkach to trudno nasycic
>RAM.
>Takie problemy rzeczywiscie sa dobrze znane, tylko ze raczej w systemach,
>gdzie dostep do RAM jest nieco wolniejszy niz w tak skupionych systemach
>jak PC.
Jest nowa architektura zwana NUMA (Non-Uniform Memory Access) ktora
podobno nie ma tych wad. Ale na razie produkuje to Data General i duzo
kosztuje (za duzo).
>> Dla kazdej aplikacji mozna wyprowadzic wzor ktory
>> pozwala obliczyc tzw. "speedup" przy okreslonej ilosci procesorow.
>> Czynnikami wplywajacymi na ow "sppedup" sa: a) wlasnosci problemu -
>> dla wielu problemow speedup zalezy logarytmicznie od ilosci
>> procesorow, b) stosunku ilosci kodu ktory mozna zrownoleglic do ilosci
>> kodu ktorego nie mozna zrownoleglic, c) strat zwiazanych z komunikacja
>> miedzy procesorami. Wynik 7.2 (a nawet 6.5) uwazam za bardzo dobry.
>Stosunej _ilosci_ kodu to akurat niespecjalnie wplywa na cokolwiek
>- juz raczej stosunek ilosci wykonywanych instrukcji (taka petla liczaca
>od 1 do 10e20 prawie nie ma kodu, a program z nia doskonale sie
>zrownolegla).
Skrot myslowy. Akurat wplywa, ale moze rzeczywiscie nie stosunek kodu
tylko "wysilku obliczeniowego" . Odpowiedni wzor nazywa sie "Prawem
Gustaffsona".
>Czyli Twoj problem obliczeniowy duzo sie synchronizuje, i nie da sie tego
>poprawic.
Na ogol tak wlasnie jest w programowaniu rownoleglym. Cala sztuka to
tak sformulowac algorytm zeby sie dalo.
>> Optymalizacja dostaw towarow od producenta do odbiorcy. Wymaga
>> rozwiazywania gigantycznych problemow nieliniowej optymalizacji
>> kombinatorycznej i programowania liniowego. W czasie rezczywistym -
>> jak sie "nie wyrobi" na okreslona godzine gdy zamowienia na transport
>> musza byc wyslane do przewoznikow (elektronicznie, zreszta) to jest
>> "po ptakach".
>A ile jest tych towarow, producentow, i odbiorcow?
Zalezy. W tym ktory wymaga obliczen rownoleglych ok. 20 zrodel, 2000
punktow dostaw, 20 tysiecy zamowien dziennie. Sa wieksze problemy niz
ten, i mniejsze.
>> Tak zreszta, number crunching to tylko 1/3 calosci. Reszta to data
>> management, obrobka danych, obsluga bazy danych i sieci, komunikacja,
>> wizualizacja itd.
>1/3 calosci? Tzn. 1/3 obciazenia obliczeniowego maszynek?
>Hmm... To jakiej wielkosci sa te dane, ze ich obsluga zajmuje az
>2 x tyle co obliczenia?
1/3 kodu. Czas zajmuja glownie obliczenia oraz interakcja z baza
danych. Cala reszta to znikomy procent.
>Mam nadzieje jednak, ze np. wizualizacja nie zajmuje jednak znaczacego
>czasu CPU w tym procesie?
>--
Nie. Wizualizacja jest bardzo prosta i wcale nie graficzna.
Uzytkownicy nie lubia grafiki. Chociaz jest nowy GUI w Javie z
dostepem przez Internet.
A.L.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 17:04:18 MET DST