🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: pl.comp.objects
11 messages
11 total messages Started by A.L. Thu, 26 Apr 2007 21:59
Parallel computing - historyczny papier
#16645
Author: A.L.
Date: Thu, 26 Apr 2007 21:59
16 lines
1403 bytes
Znalazlem moj historyczny papier na temat zastosowanaiia transputerow
do symulacji gazociagow. Z czasow gdy "super PC" mial zegar 50 MHz i
kosztowal 5 tysiecy dolcow :)

http://www.psig.org/papers/1990/9304.pdf

Niestety, dzis nie mzona czegos takiego zrobic, bo nei ma sprzetu -
"network computers" nei nadaja sie zupelnie do rowiazywania rownan
rozniczkowych zw wzgledu na zbyt powolne przesylanie informacji po
networku. 

Natomiast multi-core procesory chyba jak najbardziej sie nadadza, i
wlasnei zameirzam eksperyment powtorzyc na dual-core procesorze. Moze
ktos chce wziac udzial w eksperymencie?

A.L.
Re: Parallel computing - historyczny papier
#16646
Author: Aleksander Galicki
Date: Fri, 27 Apr 2007 07:33
27 lines
1798 bytes
A.L. <fela@2005.com> napisał(a): 

> Znalazlem moj historyczny papier na temat zastosowanaiia transputerow
> do symulacji gazociagow. Z czasow gdy "super PC" mial zegar 50 MHz i
> kosztowal 5 tysiecy dolcow :)
> 
> http://www.psig.org/papers/1990/9304.pdf
> 
> Niestety, dzis nie mzona czegos takiego zrobic, bo nei ma sprzetu -
> "network computers" nei nadaja sie zupelnie do rowiazywania rownan
> rozniczkowych zw wzgledu na zbyt powolne przesylanie informacji po
> networku. 
> 
> Natomiast multi-core procesory chyba jak najbardziej sie nadadza, i
> wlasnei zameirzam eksperyment powtorzyc na dual-core procesorze. Moze
> ktos chce wziac udzial w eksperymencie?
> 

A w czym bylaby potrzebna pomoc? Bez odrobiny wiecej informacji trudno 
stwierdzic czy udzial ma sens.
W kazdym razie w wynikach eksperymentu bede tak czy siak zainteresowany.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Re: Parallel computing - historyczny papier
#16647
Author: A.L.
Date: Fri, 27 Apr 2007 12:38
59 lines
3417 bytes
On Fri, 27 Apr 2007 07:33:33 +0000 (UTC), "Aleksander Galicki"
<tretete.SKASUJ@gazeta.pl> wrote:

>A.L. <fela@2005.com> napisał(a): 
>
>> Znalazlem moj historyczny papier na temat zastosowanaiia transputerow
>> do symulacji gazociagow. Z czasow gdy "super PC" mial zegar 50 MHz i
>> kosztowal 5 tysiecy dolcow :)
>> 
>> http://www.psig.org/papers/1990/9304.pdf
>> 
>> Niestety, dzis nie mzona czegos takiego zrobic, bo nei ma sprzetu -
>> "network computers" nei nadaja sie zupelnie do rowiazywania rownan
>> rozniczkowych zw wzgledu na zbyt powolne przesylanie informacji po
>> networku. 
>> 
>> Natomiast multi-core procesory chyba jak najbardziej sie nadadza, i
>> wlasnei zameirzam eksperyment powtorzyc na dual-core procesorze. Moze
>> ktos chce wziac udzial w eksperymencie?
>> 
>
>A w czym bylaby potrzebna pomoc? Bez odrobiny wiecej informacji trudno 
>stwierdzic czy udzial ma sens.
>W kazdym razie w wynikach eksperymentu bede tak czy siak zainteresowany.

Nie wiem dokladnie :) W kregach pzremyslowych jakis czas temu panowalo
pzrekonanie ze komputery SMP "automatycznie" niejako spwoduja ze
aplikacje beda dzialaly szybciej. Oczywiscie, nie bda, bo muszza byc
zaprogramwoane w odpowiedni sposb. Ale nawet owo odpowiednie
zaprogramwoanie niewiele pomoglo: eksperymenty jakie zrobimen z 10 lat
temu pokazany ze aplikacja na 2 aktywnych procesorach dzaila szybciej
niz na jednym, ale na 4 aktywnych procesorach dziala wolniej niz na
jednym. Przyczyna byl "bus congestion" i wspolna pamiec. Co nie
przeszkadzalo niektorym firmom zalecac klienom aby kupowali
wieloprocesorowe SMP, zwlaszcza jezeli firma posredniczyla w
sprzedazy.

Teraz SMP sa niemodne, natomiast multi-core sa modne i panuje
powszechne przekonanie ze wystarczy miec multicore procesor zeby byl
oszybciej. Niestety nie jest; na przyklad doniesienia z rynku gier
donosza ze gry puszczane na multicore processorach chodza WOLNIEJ niz
na normalnym procesorze. 

Pojawia sie wiec problem: jak zrownoleglic aplikacje tak aby miala
jakis pozytek z multicore, i czy wspolna pamiec znow nie bedzie
"bottleneck". Jak rowniez, czy taka na przyklad Java i jej support dla
watkow wie cokolwiek o dwoch procesorach.  Aplikacje ktore mam na
mysli to roznego rodzaju optumalizacja kombinatoryczna, daleko
wykraczajaca poza MIP.

Przyszlo mi do glwoy zeby zrobic "czysty" eksperyment gdzie na pewno
pamiec nie bedzie problemem, i dlatego odgrzenalem ow papier. A
konkretnie, che zaimplementowac ta sama strukture logiczna, tyle ze
nie na transputerze a w Javie i zobaczyc jak wyglada czas wykonania
przy roznej "granurality"  owych "workers".

To tyle na razie. 

A.L.
Re: Parallel computing - historyczny papier
#16655
Author: A.L.
Date: Fri, 27 Apr 2007 13:09
16 lines
1243 bytes
On Fri, 27 Apr 2007 07:33:33 +0000 (UTC), "Aleksander Galicki"
<tretete.SKASUJ@gazeta.pl> wrote:

> 
>W kazdym razie w wynikach eksperymentu bede tak czy siak zainteresowany.
>

Podano dzisiaj benchmarki dla rownoleglej implementacji pakietu
programowania liniowego CPLEX firmy ILOG

http://plato.asu.edu/ftp/ser_par.html

Wyniki wygladaja dosyc dobrze... Aczkolwiek czasami zrrownoleglenie
przynosi niewiele, albo zgola szkodzi...

A.L.
Re: Parallel computing - historyczny papier
#16648
Author: Wit Jakuczun
Date: Fri, 27 Apr 2007 14:51
29 lines
2137 bytes
Dnia Fri, 27 Apr 2007 07:38:51 -0500
A.L. <fela@2005.com> napisał(a):

> Pojawia sie wiec problem: jak zrownoleglic aplikacje tak aby miala
> jakis pozytek z multicore, i czy wspolna pamiec znow nie bedzie
> "bottleneck". 
Z moich doświadczeń to najlepiej jak wątki są niezależne. Niestety taka
sytuacja jest ciężka do uzyskania w ogólnym przypadku :(.

> Jak rowniez, czy taka na przyklad Java i jej support dla
> watkow wie cokolwiek o dwoch procesorach.  
A to nie jest kwestia systemu operacyjnego? Nie do końca rozumiem czego
oczekujesz od języka, żeby wskazywać procesor, na którym ma być odpalony 
proces? 

> Aplikacje ktore mam na mysli to roznego rodzaju optumalizacja kombinatoryczna, daleko
> wykraczajaca poza MIP.
> 
Ale i przy MIP można wiele wywalczyć równoległością. Choćby różnego rodzaju
schematy dekompozycji, w których podproblemy są rozłączne.

O jakiego rodzaju optymalizacjach kombinatorycznych mówisz?

Pozdrawiam
-- 
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]
[ Short offer: data mining, operational research, 
  time series forecasting, consulting ]
Re: Parallel computing - historyczny papier
#16649
Author: A.L.
Date: Fri, 27 Apr 2007 15:04
49 lines
2886 bytes
On Fri, 27 Apr 2007 16:51:35 +0200, Wit Jakuczun <wit@mefisto.hades>
wrote:

>Dnia Fri, 27 Apr 2007 07:38:51 -0500
>A.L. <fela@2005.com> napisaĹ?(a):
>
>> Pojawia sie wiec problem: jak zrownoleglic aplikacje tak aby miala
>> jakis pozytek z multicore, i czy wspolna pamiec znow nie bedzie
>> "bottleneck". 
>Z moich doświadczeń to najlepiej jak wątki są niezależne. Niestety taka
>sytuacja jest ciężka do uzyskania w ogólnym przypadku :(.
>

Nei wystarczy zeby watki byly niezalezne, bo watki korzystaja z tej
samej pamieci. Jezeli kazdy watek korzysta z innego segnentu, i dostep
do pamieci jest 'regularny" tak ze da sie duze kawalki danych
pomiescic w cache, to jest OK. Jezeli natomiast dostep do wspolnej
pamieci jest przypadkowy i "roproszony", to cache niewiele pomoze i
sprawnosc spada dramatycznie. Nawet w przypadku niezaleznych watkow.


>> Jak rowniez, czy taka na przyklad Java i jej support dla
>> watkow wie cokolwiek o dwoch procesorach.  
>A to nie jest kwestia systemu operacyjnego? Nie do końca rozumiem czego
>oczekujesz od języka, żeby wskazywać procesor, na którym ma być odpalony 
>proces? 
>

Niczego specjalnego nei oczekije od Javy, ale wlasnei interesuje mnie
jak system operacyjny poradzi sobie z upakowaniem watkow tam gdzie
tzreba.

>> Aplikacje ktore mam na mysli to roznego rodzaju optumalizacja kombinatoryczna, daleko
>> wykraczajaca poza MIP.
>> 
>Ale i przy MIP można wiele wywalczyć równoległością. Choćby różnego rodzaju
>schematy dekompozycji, w których podproblemy są rozłączne.
>

MIP zrownolegla sie bardzo dobrze, podobnie jak zwylky LP czy
programowanei nieliniowe. Patrz post ponizej o rownoleglym CPLEXie.

>O jakiego rodzaju optymalizacjach kombinatorycznych mówisz?
>

O constraint programming, TSP i VRP-like gdzie struktury danych nie sa
regularne a dostep do danych przypadkowy.

A.L.
Re: Parallel computing - historyczny papier
#16650
Author: Wit Jakuczun
Date: Fri, 27 Apr 2007 18:29
60 lines
3598 bytes
Dnia Fri, 27 Apr 2007 10:04:04 -0500
A.L. <fela@2005.com> napisał(a):

> On Fri, 27 Apr 2007 16:51:35 +0200, Wit Jakuczun <wit@mefisto.hades>
> wrote:

> Nei wystarczy zeby watki byly niezalezne, bo watki korzystaja z tej
> samej pamieci. Jezeli kazdy watek korzysta z innego segnentu, i dostep
> do pamieci jest 'regularny" tak ze da sie duze kawalki danych
> pomiescic w cache, to jest OK. Jezeli natomiast dostep do wspolnej
> pamieci jest przypadkowy i "roproszony", to cache niewiele pomoze i
> sprawnosc spada dramatycznie. Nawet w przypadku niezaleznych watkow.
> 
Ok. Pomieszałem nomenklaturę. Pisząc niezależne, miałem na myśli takie, które
można bez problemu przerzucić na oddzielną maszynę. Bawiłem się kiedyś
prostymi obliczeniami numerycznymi na klastrze komputerów, przy 
wykorzystaniu MPI. Wnioski były takie, że opłacało się korzystać z klastra gdy:
a) pamięci na pojedynczym komputerze było za mało
b) liczba danych przesyłanych była o dwa rzędy mniejsza od liczby operacji
    (kiepska sieć była)

> >> Jak rowniez, czy taka na przyklad Java i jej support dla
> >> watkow wie cokolwiek o dwoch procesorach.  
> >A to nie jest kwestia systemu operacyjnego? Nie do końca rozumiem czego
> >oczekujesz od języka, żeby wskazywać procesor, na którym ma być odpalony 
> >proces? 
> >
> 
> Niczego specjalnego nei oczekije od Javy, ale wlasnei interesuje mnie
> jak system operacyjny poradzi sobie z upakowaniem watkow tam gdzie
> tzreba.
> 
Rozumiem.

> >> Aplikacje ktore mam na mysli to roznego rodzaju optumalizacja kombinatoryczna, daleko
> >> wykraczajaca poza MIP.
> >> 
> >Ale i przy MIP można wiele wywalczyć równoległością. Choćby różnego rodzaju
> >schematy dekompozycji, w których podproblemy są rozłączne.
> >
> 
> MIP zrownolegla sie bardzo dobrze, podobnie jak zwylky LP czy
> programowanei nieliniowe. Patrz post ponizej o rownoleglym CPLEXie.
> 
Tak widziałem ale nie analizowałem dokładnie.

> >O jakiego rodzaju optymalizacjach kombinatorycznych mówisz?
> >
> 
> O constraint programming, TSP i VRP-like gdzie struktury danych nie sa
> regularne a dostep do danych przypadkowy.
> 
Ok. A co z metodami "local search"? One wydają się podatne na zrównoleglanie.

Pozdrawiam
-- 
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]
[ Short offer: data mining, operational research, 
  time series forecasting, consulting ]
Re: Parallel computing - historyczny papier
#16651
Author: A.L.
Date: Fri, 27 Apr 2007 18:57
19 lines
1828 bytes
On Fri, 27 Apr 2007 20:29:04 +0200, Wit Jakuczun <wit@mefisto.hades>
wrote:
 
>> O constraint programming, TSP i VRP-like gdzie struktury danych nie sa
>> regularne a dostep do danych przypadkowy.
>> 
>Ok. A co z metodami "local search"? One wydają się podatne na zrównoleglanie.
>

Owszem, nadaja sie doskonale na "network computing" - kazdy komputer
moze dostac swoja czesc "neighborhood" do przeanalizowania. Takie
problemy probowalem na "blade severs"; skalowaly sie dobrze do 32  CPU
- wiecej procesorow nei przetestwoalem bo nie mialem.  Ale poziotaje
problem jaby sie one skalowaly na multi-core czy SMP. Na network
computer kazdy procesor moze dostac kompletny zbior danych ktore moze
sobie samorzadnie i neizaleznie obrabiac. Na multicore pamiec jest
wspolna.

A.L.
Re: Parallel computing - historyczny papier
#16653
Author: Aleksander Galicki
Date: Fri, 27 Apr 2007 22:22
19 lines
1618 bytes
A.L. <fela@2005.com> napisał(a): 

> Przyszlo mi do glwoy zeby zrobic "czysty" eksperyment gdzie na pewno
> pamiec nie bedzie problemem, i dlatego odgrzenalem ow papier. A
> konkretnie, che zaimplementowac ta sama strukture logiczna, tyle ze
> nie na transputerze a w Javie i zobaczyc jak wyglada czas wykonania
> przy roznej "granurality"  owych "workers".
> 
> To tyle na razie. 

To moze bedzie ze mnie jakas korzysc. (Zawsze byla mozliwosc, ze trzeba 
bedzie portowac stary kod np. w C i wtedy pozytek ze mnie bylby maly.) Jak 
bedzie wiadomo mniej wiecej co trzeba zrobic to zapraszam na priv.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Re: Parallel computing - historyczny papier
#16652
Author: Wit Jakuczun
Date: Sat, 28 Apr 2007 08:51
33 lines
2387 bytes
Dnia Fri, 27 Apr 2007 13:57:12 -0500
A.L. <fela@2005.com> napisał(a):

> On Fri, 27 Apr 2007 20:29:04 +0200, Wit Jakuczun <wit@mefisto.hades>
> wrote:
>  
> >> O constraint programming, TSP i VRP-like gdzie struktury danych nie sa
> >> regularne a dostep do danych przypadkowy.
> >> 
> >Ok. A co z metodami "local search"? One wydają się podatne na zrównoleglanie.
> >
> 
> Owszem, nadaja sie doskonale na "network computing" - kazdy komputer
> moze dostac swoja czesc "neighborhood" do przeanalizowania. Takie
> problemy probowalem na "blade severs"; skalowaly sie dobrze do 32  CPU
> - wiecej procesorow nei przetestwoalem bo nie mialem. 
> Ale poziotaje problem jaby sie one skalowaly na multi-core czy SMP. 
To akurat chętnie bym przetestował, ale jestem sceptyczny.

> Na network computer kazdy procesor moze dostac kompletny zbior danych ktore moze
> sobie samorzadnie i neizaleznie obrabiac. 
Dokładnie. To miałem na myśli mówiąc o niezależnych wątkach.

> Na multicore pamiec jest wspolna.
> 
Jestem sceptyczny, ale chętnie pomogę w testach.

Pozdrawiam
-- 
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]
[ Short offer: data mining, operational research, 
  time series forecasting, consulting ]
Re: Parallel computing - historyczny papier
#16654
Author: Piotr Kobzda
Date: Sat, 28 Apr 2007 10:43
14 lines
1373 bytes
A.L. wrote:

> Przyszlo mi do glwoy zeby zrobic "czysty" eksperyment gdzie na pewno
> pamiec nie bedzie problemem, i dlatego odgrzenalem ow papier. A
> konkretnie, che zaimplementowac ta sama strukture logiczna, tyle ze
> nie na transputerze a w Javie i zobaczyc jak wyglada czas wykonania
> przy roznej "granurality"  owych "workers".
> 
> To tyle na razie. 

Wedle możliwości, także chętnie pomogę.  Szczegóły na priva proszę.


piotr
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads