Biblioteka PCJ w wybranych zastosowaniach matematycznych - FFT i grafy Kroneckera Toruńska Studencka Konferencja Matematyki Stosowanej M. Ryczkowska, Ł. Górski, M. Nowicki, P. Bała Uniwersytet Mikołaja Kopernika w Toruniu, Uniwersytet Warszawski gdama@mat.umk.pl, lgorski@mat.umk.pl, faramir@mat.umk.pl, bala@icm.edu.pl 4-6 kwietnia 2014 Streszczenie U podstaw bardziej zaawansowanych problemów obliczeniowych - takich jak wyrafinowana analiza danych obrazowych czy rekonstrukcja modelu sieci społecznościowych - leżą bardziej fundamentalne zagadnienia. Związane są chociażby z wydajnym obliczaniem dyskretnej transformaty Fouriera oraz zwartej reprezentacji grafów. Opracowywane przez nas rozwiązania wykorzystujące bibliotekę PCJ bardzo dobrze realizują te zadania. W niniejszej pracy przedstawiamy najważniejsze własności i założenia biblioteki PCJ, a także zaprezentujemy wyniki testów wydajnościowych dla FFT oraz obliczania zwartej reprezentacji grafu - CSR. 1 Wstęp Zaobserwować można obecnie rewolucyjną zmianę w metodyce tworzenia oprogramowania wywołaną przez pojawienie się sprzętu komputerowego intensywnie korzystającego z wielowątkowego modelu przetwarzania. Z tego też względu tradycyjne rozwiązania, jak OpenMP czy MPI są niewystarczające i konieczne jest opracowanie nowych paradygmatów i narzędzi software owych umożliwiających wykorzystanie możliwości przetwarzania wielowątkowego i rozproszonego. Wielokrotnie zauważono więc, że cały czas brakuje odpowiednio wysokopoziomowych abstrackji i konstrukcji, które ułatwiłyby programowanie[1]. Tego rodzaju braki dotyczą zarówno systemów równoległych, jak i przede wszystkim rozproszonych. Języki PGAS (Partitioned Global Address Space) mogłyby znakomicie zmitygować wskazane braki, zapewniając zarówno wygodne tworzenie aplikacji tak w środowisku równoległym, jak i rozproszonym, oferując za każdym razem uniwersalne abstrakcje programistyczne. Języki należące do tej kategorii zakładają bowiem, że pamięć zostanie podzielona pomiędzy wszystkie wątki wykonania. Domyślnie wszystkie zmienne w określonym obszarze pamięci są prywatne dla danego wątku. Programista może je jednak oznaczyć jako dzielone, a tym samym udostępnić innym wątkom do odczytu albo modyfikacji. Niektóre z nowoopracowanych języków, które implementują ten zyskujący na popularności paradygmat to X10 [2] i Chapel [3]. Elementy modelu PGAS zostały wprowadzone w nowej wersji standardu Fortranu, jako coarrays [4]. Dodatkowo, prowadzone są prace na językiem CoArray Fortran 2.0, w celu dalszego ulepszenia jego możliwości w ramach modelu SPMD [5]. Dialekt C implementujący model PGAS nosi nazwę UPC [6].
Celem niniejszego opracowania jest zademonstrowanie użyteczności rozszerzenia PGAS dla języka Java, które jest obecnie opracowywane przez autorów niniejszego opracowania: biblioteki PCJ [27]. Java jest językiem przenośnym, zapewniającym warstwę abstrakcji nad sprzętem komputerowym i posiadającym dużą grupę użytkowników. Wybraliśmy Javę ze względu na jej przenośność i rozległą grupę użytkowników. Programy napisane w Javie mają potencjalnie dłuższy cykl życia w porównaniu do sprzętu, na którym są wykonywane, a ich wydajność może być zwiększona po prostu poprzez przeniesienie na bardziej zaawansowany system komputerowy [7]. Język jest łatwy w użyciu dzięki odśmiecaniu, statycznej typizacji czy brakowi wskaźników. Podobnie, jak w wypadku innych języków, również dla Javy zaprojektowano rozwiązania wzmacniające jej równoległość. Wskazać należy na projekty takie, jak Parallel Java [8] i projekt Java Grande [9] [10] (które jednak nie zyskały szerszej popularności), Titanium [11] czy ProActive [12] (niestety ten ostatni miewa problemy z wydajnością ze względu na nieefektywne mechanizmy serializacji). Należy także wspomnieć równoległe strumienie wprowadzone w nowej wersji Javy [13]. Nasze rozwiązanie biblioteka PGAS dla Javy - charakteryzuje się dużą przenośnością, pozostaje więc w duchu Javy. W odróżnieniu od innych rozwiązań nie modyfikuje składni języka ani nie implementauje własnej wersji maszyny wirtualnej, nie opiera się też na specjalnych preprocesorach. Biblioteka PCJ jest oparta na czystej Javie 7 i nie wymaga żadnych zewnętrznych bibliotek do działania. Pozwala to też na łatwą migrację do następnych wersji języka. Zapewnienie przenośności naszego rozwiązania nie zostało okupione koncesjami co do wydajności[14] [15]. W następnej części opracowania opisujemy bibliotekę PCJ i podajemy przykłady jej wykorzystania. Zainteresowany dalszymi szczegółami użytkownik powinien sięgnąć do podręcznika użytkownika [16]. Końcowe rozdziały prezentują informacje o przykładowych zastosowaniach biblioteki: do obliczania FFT i postaci CSR (Compressed Sparse Row) grafu. 2 Biblioteka PCJ W bibliotece PCJ wątki reprezentowane są przez klasy implementujące interfejs StartPoint (listing 1). Metoda main() odpowiada metodzie run() standardowej klasy Thread. public interface StartPoint { public void main(); Listing 1. Interfejs StartPoint Domyślnie, zgodnie z założeniami modelu PGAS, wszystkie pola są lokalne dla wątku. Ich uwspólnienie następuje poprzez użycie adnotacji @Shared. Klasa, które korzysta ze zmiennych współdzielonych musi też dziedziczyć z abstrakcyjnej klasy Storage (por. listing 2; przykładowe kod używa też metod myid() oraz numthreads() w celu pobrania liczby identyfikującej wątek oraz liczby wszystkich wątków). class Example extends Storage implements StartPoint { private double local; @Shared private int[] table; public void main () { System.out.println("Thread #" + PCJ.myNode() + " of" + PCJ.numNodes() + " threads."); Listing 2. Aplikacja wyświetlająca liczę wątków PCJ
Rozpoczęcie obliczeń jest bardzo proste i sprowadza się do wywołania metody deploy(), której można przekazać identyfikatory maszyn, na których mają zostać uruchomione obliczenia. Mechanizm ten pozwala na uruchomienie programu w różnych scenariuszach użycia, jak wiele wątków w pojedynczej maszynie wirtualnej albo wiele maszyn wirtualnych na pojedynczym węźle fizycznym. Przykładowo, w listingu 3. uruchomiono trzy wątki lokalne oraz dodatkowy - zdalny (w domenie example.com). Dwa wątki lokalne korzystające z tego samego domyślnego numeru portu dla komunikacji zostaną uruchomione na tej samej maszynie wirtualnej; w wypadku pozostałych dwóch uruchomione zostaną dodatkowe. PCJ.deploy( Example.class, // StartPoint Example.class, // Storage new String[] { // Lista maszyn "localhost", "localhost", "example.com", "127.0.0.1:3003" ); Listing 3. Przykład wykorzystania metody deploy() Podstawowe operacje - odczyt i modyfikacje zmiennej dzielonej - zaimplementowano jako operacje get() i put(). Ich argumenty to: identyfikator wątku docelowego, etykieta zmiennej dzielonej (domyślnie określona przez jej nazwę), a w wypadku operacji put() - nowa wartość zmiennej. Składnia przedstawiona jest w listingu 4. Tamże taskid oznacza identyfikator zdalnego wątku (którego zmienna dzielona jest odczytywana bądź modyfikowana), variablename to nazwa zmiennej w klasie Storage, variabledata to przesyłane dane. Parametr indexes... jest opcjonalny i stosowany wyłącznie do tablic: wskazuje indeksy elementów, które mają być przesłane. PCJ.put(int taskid, String variablename, Object variabledata, int indexes...) PCJ.get(int taskid, String variablename, int indexes...) Listing 4. Składnia metod get() i put() W przykładowym listingu 5. wartość całkowita 42 zapisywana jest do zmiennej table w wątku o nr 4. W następnej linii cała tablica pobrana jest z wątku nr 6 (komunikacja synchroniczna). W dalszej części listingu 6. wykorzystana jest komunikacja asynchroniczna. PCJ.put(4, "table", 42, 10); int[] t = PCJ.get(6, "table"); FutureObject resp; resp = PCJ.getFutureObject(7, "table"); // nieblokujące /*... */ if (resp.isdone()) { int[] t = resp.get(); // blokujące Listing 5. Podstawy komunikacji Metoda barrier() stanowi implementację operacji synchronizacji wątków. Możliwe jest synchronizowanie tylko podzbioru wszystkich wątków. Jest to przydatne przy takich operacjach, jak wykonanie synchronicznego put/get (por. listing 6). if (PCJ.myId() == 3) { PCJ.putLocal("value", 42); PCJ.barrier(2); else if (PCJ.myId() == 2) {
PCJ.barrier(3); int answer = PCJ.get(3, "value"); Listing 6. Przykład wykorzystania bariery i synchronicznych operacji put/get Listing 7 przedstawia przykład wykorzystania operacji rozgłoszenia. W celu rozpoczęcia rozgłoszenia wątek wywołujący wykorzystuje metodę broadcast() i przesyła identyfikator rozgłaszanej zmiennej dzielonej, a także jej nową wartość. Wątek-odbiorca może poczekać na odebranie nowej wartości wykorzystując metodę waitfor(), która blokuje wątek aż monitorowana zmienna zostanie zmodyfikowana przez inny wątek. Monitorowanie zmiennych wprowadzone zostało ze względu na fakt, że biblioteka PCJ oparta jest na komunikacji jednostronnej. W wypadku listingu 7 należy także zauważyć, że również wątek nr 4 (inicjujący rozgłoszenie) korzysta z metody waitfor(). Komunikacja jest asynchroniczna, toteż bezpośrednio po wywołaniu metody broadcast() wątek 4 kontynuuje wykonanie. Wykorzystanie w tym wypadku metody waitfor() jest konieczne w celu upewnienia się, że zakończono zapis lokalnych danych. Co więcej, rozgłoszenie wykorzystuje topologię drzewa ukorzenionego w wątku o nr. 0, toteż zapis do zmiennej należącej do wątku nr 4 jest w istocie inicjowany przez jego rodzica. @Shared int a; /*... */ if (PCJ.myNode() == 4) { PCJ.broadcast("a", 42); PCJ.waitFor("a"); //wait for a message from thread #4 Listing 7. Rozgłoszenie wartość 42 przez wątek nr 4. Każdy wątek przechowuje rozgłoszoną wartość w zmiennej a Przedstawione do tej pory operacje mogą być wykonywane globalnie dla wszystkich wątków, ale możliwe jest też ograniczenie ich jedynie do grupy wątków. Tworzenie grup jest proste i przedstawione w listingu 8., gdzie utworzono dwie grupy w oparciu o parzystość identyfikatora odpowiednich wątków. Group g = PCJ.join("group:" + (PCJ.myNode() % 2)); Listing 8. Tworzenie grupy wątków 3 Przykładowa implementacja - szybka transformata Fouriera Zaimplementowana jednowymiarowa zespolona szybka transformata Fouriera wykonuje nakładające się na siebie obliczenia i komunikację, nadaje się więc szczególnie do testowania wydajności systemu komputerowego w warunkach zbliżonych do rzeczywistych scenariuszy użycia. Została też wykorzystana przez autorów zestawu testów HPC Benchmark jako element pakietu umożliwiającego ocenę szybkości przyszłych petaskalowych systemów komputerowych [17]. Z tych też względów wykorzystaliśmy kod obliczający FFT do przedstawienia wydajności naszego rozwiązania, przyjmując test HPC Challenge za punkt odniesienia. Zainteresowani byliśmy przede wszystkim skalowalnością biblioteki, toteż odstąpiliśmy od przyjętej w ramach testu HPC Challenge metodologii polegającej na wykorzystaniu rozmiarów danych wypełniających prawie całą dostępną pamięć. Testy zostały zmodyfikowane tak, aby działały na danych tego samego rozmiaru, niezależnie od liczby węzłów obliczeniowych i dostępnej pamięci. Dodatkowo sprawdziliśmy też wydajność znanej i powszechnie wykorzystywanej biblioteki FFTW [18], skompilowanej ze wsparciem dla MPI. Testy przeprowadzono na klastrze 64 węzłów obliczeniowych opartych o procesory Intel Xeon X5660 (dwunastordzeniowe) z połączeniem Infiniband, taktowane zegarem 2,8 GHz. Każdy węzeł posiada 24 GB
pamięci RAM. Jako implementację MPI wykorzystano OpenMPI 1.6.5 (kompatybilne z gcc 4.4.7). Biblioteka PCJ została uruchomiona z wykorzystaniem maszyny wirtualnej Oracle v. 1.7.0_40 oraz IBM v. 1.7.0_SR6. Praca została wykonana z wykorzystaniem infrastruktury PL-Grid [19]. Implementacja w wypadku HPC Challenge oparta jest o algorytmy opublikowane przez Takahashiego i Kanadę [20]. W wypadku biblioteki PCJ zdecydowano się zaadaptować wcześniejszą implementację wykorzystującą Coarray Fortran 2.0 opartą o radix-2, wykorzystującą do komunikacji wzorzec mechanizm all-to-all (tj. w trakcie komunikacji każdy wątek wysyła komunikat do wszystkich pozostałych) [21]. W naszej implementacji przetestowano dwa rozwiązania all-to-all. Oba opierają się na tym samym schemacie: każdy wątek przechowuje tablicę dzieloną blocks. Jej i-ta komórka jest wypełniania przez wątek, do którego ta przynależy danymi komunikowanymi dla i-tego wątku. Po zainicjowaniu tablicy blocks każdy wątek zaczyna odbierać odpowiednie dane od pozostałych. W tym miejscu obie implementacje się różnią. Przetestowaliśmy, po pierwsze, implementację wykorzystaną przez Manninena i Richardsona dla Fortranu [22]. Ta wykorzystuje prostą pętlę iterującą od myid() + 1 do numthreads() - 1, a następnie od 0 do myid() - 1. W trakcie każdej iteracji wykorzystywana jest komunikacja blokująca i odpowiednia wartość jest odbierana od odpowiedniego wątku (listing 9). Przetestowana została też implementacje nieblokująca (listing 10). block_size = local_n / PCJ.numThreads(); for (int image = (PCJ.myId() + 1) % PCJ.threadCount(), num = 0; num!= PCJ.threadCount() - 1; image = (image + 1) % PCJ. threadcount()) { double[] recv = (double[]) PCJ.get(image, "blocks", PCJ.myId()); System.arraycopy(recv, 0, dest, (int) (image * 2 * blocksize), (int) (2 * blocksize)); num++; Listing 9. Blokujące all-to-all //prepare the futures array FutureObject<double[]>[] futures =new FutureObject[PCJ.threadCount()]; //get the data (asynchronous) for (int i = 0; i < PCJ.threadCount(); i++) { if (i!= PCJ.myId()) { futures[i] = PCJ.getFutureObject(i, "blocks", PCJ.myId()); int numreceived = 0; while (numreceived!= PCJ.threadCount() - 1) { for (int i = 0; i < futures.length; i ++) { if (futures[i]!= null && futures[i].isdone()) { double[] recv = futures[i].getobject(); System.arraycopy(recv, 0, dest, 20 (int) (i * 2 * blocksize), (int) (2 * blocksize)); numreceived++; futures[i] = null; Listing 10. Nieblokujące all-to-all Wykres 1 przedstawia wyniki przyspieszenia dla danych złożonych z 2 25 liczb zespolonych. Dla testów wykorzystano hybrydową implementację z biblioteki FFTW (tzn. wykorzystującą MPI dla obliczeń rozproszonych i OpenMP dla zrównoleglenia na pojedynczym węźle). Biblioteka PCJ wypadała poprawnie, osiągając przyspieszenie porównywalne z FFTW (należy jednak zauważyć, że referencyjny czas działania na pojedynczym wątku jednak się różnił i wynosił ok. 3,3 s dla FFTW i ok. 10 s. dla PCJ). W wypadku
mniejszej liczby wątków (tj. obliczeń wykonywanych na pojedynczym węźle) znakomicie wypadło rozwiązanie z HPC Benchmark. Należy więc rozważyć w przyszłości implementację zastosowanego w nim algorytmu i ponowne wykonanie testów. Wykres 1. FFT - przyspieszenie 4 Przykładowa implementacja postać CSR dla grafu Kroneckera Grafy są jednym z najbardziej powszechnych modeli używanych do analizy. Są wykorzystywane do reprezentacji relacji i dlatego są obecne w wielu dziedzinach nauki między innymi w biologii (badanie łańcuchów pokarmowych w różnych ekosystemach, badanie interakcji między białkami HCV - ludzkim wirusem typu C zapalenia wątroby - oraz białkami człowieka), w analizie sieci dróg (oprogramowanie oparte na algorytmach analizujących grafy znalazło zastosowanie w przenośnych urządzeniach PDA wyposażonych w GPS ) oraz w analizie sieci społecznościowych takich jak Facebook czy Twitter. Podstawowe problemy grafowe znajdują zastosowania w wielu dziedzinach życia, dlatego analiza grafów i otrzymywanie szybkich rozwiązań stają się coraz ważniejsze. Wielkość i złożoność grafów stanowi jednak wyzwanie do ich efektywnego przetwarzania. Coraz bardziej na znaczeniu zyskują projekty które pomagają badać moc obliczeniową klastrów w kontekście algorytmów grafowych. Jednym z takich projektów jest projekt Graph500 przedstawiony na międzynarodowej konferencji ISC2010 [26]. Graph500 dostarcza testów do oceny superkomputerów na całym świecie [26]. Testy te wymuszają dużą ilość komunikacji i synchronizacji co pozwala na analizę bardziej realistycznych obciążeń obliczeniowych [24]. W benchmarku Graph500 można wyróżnić trzy główne części [25]: generator Grafu Kroneckera: tworzenie losowego Grafu Kroneckera w postaci listy krawędzi (każda krawędź jest nieskierowana)
kernel 1: utworzenie reprezentacji grafu z listy krawędzi otrzymanej z generatora Grafu Kroneckera kernel 2: BFS dla 64 losowo wybranych wierzchołków Grafy Kroneckera otrzymane z generatora benchmarku Graph500 dobrze symulują grafy społecznościowe [23], ponieważ posiadają wiele cech zgodnych z cechami sieci ze świata rzeczywistego np. występowanie podsieci, złożonych z grup dobrych znajomych, w których wszyscy się znają. Grafy Kroneckera tworzone są według rekurencyjnej konstrukcji opartej o produkt Kroneckara na macierzach sąsiedztwa. Sprawdziliśmy wydajność biblioteki PCJ w kontekście obliczeń grafowych. Zaimplementowaliśmy tworzenie reprezentacji grafu w postaci CSR z listy krawędzi otrzymanej z generatora Grafu Kroneckara benchmarku Graph500. Testy przeprowadziliśmy na losowym Grafie Kroneckara rozmiaru SCALE 21 (logarytm o podstawie dwa z liczby wierzchołków grafu). Wykres 2 przedstawia czas obliczeń (wraz z czasem zbierania danych) potrzebny do utworzenia reprezentacji CSR z listy krawędzi. Skalowalność PCJ dla wątków od 1 do 4 jest obiecująca. Przy ośmiu wątkach czas wykonania rośnie. Należałoby, więc powtórzyć badania dla większego grafu, a także porównać wydajność biblioteki PCJ z implementacjami w OpenMP oraz MPI. Wykres 2. CSR - czas obliczeń i zbierania danych dla Grafu Kroneckera SCALE 21. 5 Uwagi końcowe i dalsze prace Wykonane testy wskazują, że nasze rozwiązanie jest obiecujące pod względem wydajności, pod niektórymi względami dorównując uznanym i długo rozwijanym rozwiązaniom (por. FFTW). Więcej informacji o wydajności dostępnych będzie też w pracy [28]. Oprócz wskazanych w toku testów planów na przyszłość, aktualnie prowadzone są też prace związane z implementacją pozostałych testów HPC Benchmark i kerneli obliczeniowych Graph 500.
Bibliografia [1] T. Rauber, G. Rünger, Parallel Programming: for Multicore and Cluster Systems, Berlin Londyn 2010 [2] X10 - strona główna, [Online]. Available: http://x10-lang.org. [Data uzyskania dostępu: 18 01 2014]. [3] Chapel - strona główna, [Online]. Available: http://chapel.cray.com. [Data uzyskania dostępu: 18 01 014]. [4] J. Reid, Coarrays in the next Fortran Standard, [Online]. Available: ftp://ftp.nag.co.uk/sc22wg5/n1801-n1850. [Data uzyskania dostępu: 09 03 2014]. [5] Coarray Fortran 2.0 - strona główna, Rice university, [Online]. Available: http://caf.rice.edu. [Data uzyskania dostępu: 18 01 2014]. [6] UPC - strona główna, [Online]. Available: http://upc-lang.org/. [Data uzyskania dostępu: 10 04 2014]. [7] J. M. Bull, I. A. Smith, I. Pottage i R. Freeman, Benchmarking Java against C and Fortran for scientific apllications, w Proceedings of the 2001 joint ACM-ISOPE conference on Java Grande, 2001. [8] A. Kaminsky, Parallel Java: A unified api for shared memory and cluster parallel programming in 100% java, w Parallel and Distributed Processing Symposium, Long Beach, 2007. [9] J. M. Bull, L. A. Smith, M. D. Westhead, D. S. Henty i R. A. Davey, A Benchmark Suite for High Performance Java, Concurrency: Practice and Experience, tom 12, pp. 375-388, 2000. [10] Java Grande - strona główna, [Online]. Available: https://www.epcc.ed.ac.uk/research/computing/performance-characterisation-andbenchmarking/java-grande-benchmark-suite. [Data uzyskania dostępu: 19 01 2014]. [11] P. Hilfinger, D. Bonachea, K. Datta, D. Gay, S. Graham, B. Liblit, G. Pike, J. Su i K. Yelick, Titanium Language Reference Manual, [Online]. Available: http://titanium.cs.berkeley.edu/papers/eecs- 2005-15.pdf. [Data uzyskania dostępu: 03 03 2014]. [12] D. Caromel, C. Delbe, A. D. Costanzo i M. Leyton, Proactive: an integrated platform for programming and running applications on grids and p2p systems, Computational Methods in Science and Technology, tom 12, 2006. [13] [Online]. Available: http://docs.oracle.com/javase/tutorial/collections/streams/parallelism.html. [Data uzyskania dostępu: 02 03 2014]. [14] M. Nowicki i P. Bała, New Approach for Parallel Computation in Java, Lecture Notes in Computer Science, tom 7782, pp. 115-125, 2013. [15] M. Nowicki i P. Bała, Parallel computations in Java with PCJ library, w High Performance Computing and Simulation (HPCS), Madryt, 2012. [16] M. Nowicki i P. Bała, PCJ manual, [Online]. Available: http://pcj.icm.edu.pl. [Data uzyskania dostępu: 02 03 2013].
[17] HPC Challenge - strona główna, [Online]. Available: http://icl.cs.utk.edu/hpcc/. [Data uzyskania dostępu: 19 01 2014]. [18] FFTW - strona główna, [Online]. Available: http://www.fftw.org. [Data uzyskania dostępu: 20 01 2014]. [19] PL-Grid - strona główna, [Online]. Available: http://plgrid.pl. [Data uzyskania dostępu: 29 05 2014]. [20] D. Takahashi i Y. Kanada, High-performance radix-2, 3 and 5 parallel 1-d complex FFT algorithm for distributed-memory parallel computers, The Journal of Supercomputing, tom 15, nr 2, pp. 207-228, 2000. [21] J. Mellor-Crummey, L. Adhianto, G. Jin, M. Krentel, K. Murthy, W. Scherer i C. Yang, Class II Submission to the HPC Challenge Award Competition. Coarray Fortran 2.0, [Online]. Available: http://www.hpcchallenge.org/presentations/sc2011/hpcc11_report_caf2_0.pdf. [Data uzyskania dostępu: 29 05 2014]. [22] P. Manninem i H. Richardson, First experiences on collective operations with Fortran coarrays on the Cray XC30, w 7th International Conference on Pgas Programming Models, Edinburgh, 2013. [23] J. Leskovec, D. Chakrabarti, J. Kleinberg, Ch. Faloutsos, Z. Ghahramani Kronecker Graphs: An Approach to Modeling Networks, The Journal of Machine Learning Research archive, Volume 11, 3/1/2010, Pages 985-1042 [24] A.Yoo and I.Kaplan, Evaluating Use of Data Flow Systems for Large Graph Analysis, Proceedings of the 2nd Workshop on Many-Task Computing on Grids and Supercomputers, Article No. 5, ACM New York, USA, 2009 [25] The Graph500 Specification, [Online] http://www.graph500.org/specifications. [26] The Graph500 List, [Online] http://www.graph500.org/. [27] PCJ - strona główna, [Online] http://pcj.icm.edu.pl/. [28] M.Nowicki,Ł.Górski, P. Grabarczyk, P. Bała. PCJ Java library for high performance computing in PGAS model. HPCS 2014 (w druku) [29] M.Ryczkowska. Evaluating PCJ Library for Graph Problems Graph500 in PCJ (w druku)