Article View: pl.comp.objects
Article #16650Re: Parallel computing - historyczny papier
From: 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 ]
Technical Details
Message-ID:
<20070427202904.53cd79da@mefisto.hades>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!nf1.ipartners.pl!ipartners.pl!news.szeptel.net.pl!news.mcnet.pl!news.nask.pl!news.nask.org.pl!newsfeed.atman.pl!news.atcom.net.pl!mefisto.hades!newsReferences:
<vq7233tfgv90o8faaag3h52q1lrln5noes@4ax.com> <f0s90d$lmq$1@inews.gazeta.pl> <6tq333h2t0oe2jl82m06uuphfabt4tddg7@4ax.com> <20070427165135.4bb8c5ef@mefisto.hades> <ap34331bcft4kst0mn20mcvgobka0ovjjv@4ax.com>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!nf1.ipartners.pl!ipartners.pl!news.szeptel.net.pl!news.mcnet.pl!news.nask.pl!news.nask.org.pl!newsfeed.atman.pl!news.atcom.net.pl!mefisto.hades!news From: Wit Jakuczun <wit@mefisto.hades> Newsgroups: pl.comp.objects Subject: Re: Parallel computing - historyczny papier Date: Fri, 27 Apr 2007 20:29:04 +0200 Organization: ATCOM ISP http://www.atcom.pl Lines: 68 Message-ID: <20070427202904.53cd79da@mefisto.hades> References: <vq7233tfgv90o8faaag3h52q1lrln5noes@4ax.com> <f0s90d$lmq$1@inews.gazeta.pl> <6tq333h2t0oe2jl82m06uuphfabt4tddg7@4ax.com> <20070427165135.4bb8c5ef@mefisto.hades> <ap34331bcft4kst0mn20mcvgobka0ovjjv@4ax.com> NNTP-Posting-Host: dhcp-239-ppp.man.atcom.net.pl Mime-Version: 1.0 X-Trace: kontener.atcom.net.pl 1177697913 22724 217.197.165.239 (27 Apr 2007 18:18:33 GMT) X-Complaints-To: news@atcom.pl NNTP-Posting-Date: Fri, 27 Apr 2007 18:18:33 +0000 (UTC) X-Newsreader: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; x86_64-pc-linux-gnu) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit