Seminarium Zakładowe IDSS
Równoległe obliczenia
metaheurystyczne z
wykorzystaniem klastra
obliczeniowego
Krzysztof Kowalczykiewicz Marek Kubiak Dawid Weiss Przemysław WesołekMotywacje raz jeszcze...
● Zagospodarowanie “wolnych” mocy
obliczeniowych w lab. 45 (15 x 3.2Ghz)
● Zbadanie istniejących rozwiązań do budowy
klastrów obliczeniowych
● Zbudowanie dostępnego, łatwego w obsłudze i
nieinwazyjnego systemu obliczeniowego
● Analiza metaheurystyk pod kątem
zrównoleglenia
– w szczególności PMA - Pareto Memetic Algorithm
Początki...
● Parallel Knoppix
● system Linux startujący z CD (lub pobierający dane z
innego komputera już wystartowanego - PXE)
● łatwy w obsłudze i dobrze radzący sobie ze sprzętem
● w stosunku do Knoppix rozszerzony o skrypty do budowy
klastra, odpowiednie API i przykłady
● Wady
● statyczny klaster
● kłopotliwe inicjowanie
Infrastruktura Alchemi
● Dostępna
● możliwość inicjowania obliczeń z dowolnej maszyny
(nawet z zewnątrz PP - tunel)
● monitorowanie z zewnątrz
● Nieinwazyjna
● pracująca w tle na komputerach lab. usługa
● mały narzut i możliwość normalnego wykorzystywania
maszyn nawet w trakcie obliczeń
● Łatwa w obsłudze
● możliwość stosowania Job API (dowolne binaria) ● aplikacje natywne .NET (naśladujące wątki)
Wyzwania technologiczne
● Integracja biblioteki MOMHlib z platformą .NET
– oryginalnie napisana w Visual C++
– przeniesiona na Linux/C++
– ponowna integracja w Managed C++ (CLR)
● “Oswojenie” składni Managed C++ i mieszanie
kodu managed i unmanaged
Adaptacja MOMHlib
● kompilacja się powiodła po usunięciu kilku
drobnych problemów
● domyślnie aplikacja C++/CLR działa jako
unmanaged)
● próba konwersji na managed nie powiodła się
● class -> ref class ● new -> gcnew
● biblioteka std ++ -> kolekcje .NET ● wskaźniki & i * -> referencje ^
Managed C++
● rozszerzenia języka C++ do pisania aplikacji
działających na maszynie wirt. CLR (.NET)
● umożliwia mieszanie kodu/klas zarządzanych
(wykorzystujących GC) i niezarządzanych (tradycyjne wskaźniki/referencje)
● skomplikowana składnia w porównaniu do C#,
ale większa kontrola i możliwość mieszania z kodem unmanaged
● trudności mieszania kodu m/um w obrębie
jednej klasy
API Alchemi
● Naśladuje API wątków
● Należy “opakować” jednostkę uruchomienia w
potomka klasy GThread i zaimplementować metodę Start()
● Alchemi sam przenosi binaria (i wskazane pliki)
na maszynę docelową
● Batch vs On-the-fly
● utworzenie wszystkich wątków na początku ● dodawanie nowych wątków w razie potrzeby
Obliczenia równoległe
● Podejście trywialne
● równoległe uruchamianie algorytmu z różnym
wartościami parametrów i różnymi instancjami
● Podejście ambitniejsze
● analiza strukturalna algorytmu
● analiza czasów i krotności uruchomienia poszczególnych
faz algorytmu (profiling)
● analiza możliwości rozdziału pętli ● analiza możliwości rozdziału danych
● Dobry kandydat
● dobrze separowalne dane lub pętle
PMA - Pareto Memetic Algorithm
● hybryda algorytmu genetycznego
(rekombinacja) z przeszukiwaniem lokalnym (heurystyka lokalna)
● ogólny schemat:
wygeneruj początkowy zbiór rozwiązań
powtarzaj
wylosuj wektor wag dla funkcji skalaryzującej
wybierz dwa rozwiązania dobre wg funkcji skalaryzującej dokonaj rekombinacji rozwiązań
zastosuj lokalną heurystykę do potomka
Równoległe PMA - intuicja
● równoległe lokalne wyszukiwanie
– równoległa analiza w wielu kierunkach?
– wybór najlepszego?
● równoległe iteracje pętli
– z różnymi czy tymi samymi wektorami wag?
– jak łączyć dane wyjściowe?
● równoległa rekombinacja
– różne metody?
Analiza uruchomieniowa PMA
MOKP MOTSP
generowanie początkowego zbioru rozw. 52% 4%
główna pętla 48% 96%
inicjalizacja wag <1% <1%
turniej 17% 2%
rekombinacja + local search 67% 95%
aktualizacja zbioru rozw. 15% 2%
ilość iteracji (tyś.) 7,5-17,5 2,5-22,5
Problemy z PMA...
● Zbyt krótkotrwałe powtórzenia pętli i local
search aby zrównoleglać pojedyńcze iteracje
● Zrównoleglenie stwarza problem ze względu
na słabą separowalność danych i problemy z łączeniem rezultatów z różnych uruchomień
● Duża ilość czynników losowych (wektor wag,
turniej, rekombinacja)
● Implementacja MOKP wykorzystuje
uproszczony local search - iteracja jeszcze krótsza
...zatem podejście trywialne
MOKP ● 9 instancji ● TempPopulationSize ● 20 ● InitPopulationSize ● 150,200,250,300,350 ● Iterations ● 50 = 45 wątków MOTSP ● 49 instancji ● TempPopulationSize ● 20, 40, 60 ● InitPopulationSize ● 100, 200, 300 ● Iterations ● 25, 50, 75 = 1323 wątkówMOKP (45 wątków)
● Implementacja
● uproszczone lokalne przeszukiwanie
(przywrócenie dopuszczalności po rekombinacji)
● Czas eksperymentu: ~7min.
MOTSP (1323 wątki)
● Implementacja
● pełne lokalne przeszukiwanie
(DPXRecombine + Steepest LS)
● Czas eksperymentu: ~5h
Podsumowanie
● Infrastruktura Alchemi dostępna w lab. 45
(serwer na minos)
● Prosta integracja (bezpośrednio z .NET lub
batch job przez XML)
● Perspektywy
● bardziej dogłębna analiza PMA i zastosowanych
heurystyk pod kątem zrównoleglania
● analiza metod łączenia rezultatów z różnych
