Thread View: pl.comp.objects
11 messages
11 total messages
Started by A.L.
Thu, 26 Apr 2007 21:59
Parallel computing - historyczny papier
Author: A.L.
Date: Thu, 26 Apr 2007 21:59
Date: Thu, 26 Apr 2007 21:59
16 lines
1403 bytes
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
Author: Aleksander Galicki
Date: Fri, 27 Apr 2007 07:33
Date: Fri, 27 Apr 2007 07:33
27 lines
1798 bytes
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
Author: A.L.
Date: Fri, 27 Apr 2007 12:38
Date: Fri, 27 Apr 2007 12:38
59 lines
3417 bytes
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
Author: A.L.
Date: Fri, 27 Apr 2007 13:09
Date: Fri, 27 Apr 2007 13:09
16 lines
1243 bytes
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
Author: Wit Jakuczun
Date: Fri, 27 Apr 2007 14:51
Date: Fri, 27 Apr 2007 14:51
29 lines
2137 bytes
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
Author: A.L.
Date: Fri, 27 Apr 2007 15:04
Date: Fri, 27 Apr 2007 15:04
49 lines
2886 bytes
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
Author: Wit Jakuczun
Date: Fri, 27 Apr 2007 18:29
Date: Fri, 27 Apr 2007 18:29
60 lines
3598 bytes
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
Author: A.L.
Date: Fri, 27 Apr 2007 18:57
Date: Fri, 27 Apr 2007 18:57
19 lines
1828 bytes
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
Author: Aleksander Galicki
Date: Fri, 27 Apr 2007 22:22
Date: Fri, 27 Apr 2007 22:22
19 lines
1618 bytes
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
Author: Wit Jakuczun
Date: Sat, 28 Apr 2007 08:51
Date: Sat, 28 Apr 2007 08:51
33 lines
2387 bytes
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
Author: Piotr Kobzda
Date: Sat, 28 Apr 2007 10:43
Date: Sat, 28 Apr 2007 10:43
14 lines
1373 bytes
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