Witam wszystkich forumowiczów,
mam nadzieję, że ktoś z Was mi pomoże.
Czy istnieje w JAVIe możliwość, czy ktoś spotkał się z biblioteką umożliwiającą pisanie programu, który mógłby być odtwarzany na kilku procesorach?
Chodzi mi o taką bibliotekę, jak np. biblioteka MPI w języku C.
Proszę o jakiekolwiek podpowiedzi i sugestie. Dziękuje z góry.
Nie widze problemu - piszesz wielowątkowo a system rozdziela wykonanie wątków na wiele procesorów. Nie ma potrzeby używania jakiejś innej biblioteki.
Java wielowątkowość ma w ramach kilku pakietów i mechanizmów. Pierwszy to klasa Thread i interfejs Runnable. Dodatkowo metody wait i notify w klasie Object. Następnie jest pakiet java.lang.concurrency, w którym masz wszystko co potrzeba.
hmm...moja skromna wiedza inżynierska mi mówi że Koziołek i kolega powyżej zmylili przetwarzanie równoległe z wątkami programu...to że on będzie miał 45 wątków i system porozdziela na rdzenie to ale i tak jeden wątek pójdzie na jeden rdzeń-jeden wątek i cała jego "zawartość".
Pytającemu bardziej chodziło chyba o przetwarzanie zawartości wątku na wielu rdzeniach....i sam jestem ciekaw czy takie coś jest w javie-spotkałem się z tym ale w systemach dedykowanych dla automatyki. Taki prosty przykład:
(a+b) * (c + d) = e
Na jeden wątek z automatu leci a+b , na drugi c+d a za mnożenie jeszcze jest w ogóle inny dedykowany wątek co nic innego nie robi tylko mnoży. Oczywiscie to trywialny przykład ale widziałem konstrukcje myślowe...zacne.
Może przerost formy zrobiłem teraz i Wasze odpowiedzi pytającemu wystarczą...ale jeżeli bliżej było mojej myśli to dołącze się do dyskusji.
@lipkerson, w ten deseń. Hm... być może da się to osiągnąć na komercyjnych, dedykowanych JVMach. W standardzie tak się nie da.
Jest coś takiego, jak kompilator JavaR. Może to się autorowi przyda?
Znalazłem go na google, ale tematu nie rozpoznawałem.
lipkerson:
Cóż za zaawansowana technologia :P Myślę, że autorowi nie o to chodziło.
autor:
A wiesz do czego służy MPI? MPI to Message Passing Interface. Służy do komunikacji międzyprocesowej - nie międzywątkowej, bo ta jest banalna.
Różnica między procesami, a wątkami jest taka, że wątki muszą być na jednym spójnym CPU, a procesy mogą być na odległych krańcach globu na różnych procesorach, architekturach itp W przypadku procesów nie można współdzielić pamięci, najlepszym rozwiązaniem jest wysyłanie wiadomości z jakimiś informacjami.
Google: "ipc java"
Technologia ta to staroć - używasz jej na codzień. Masz wieżę i słuchasz muzy...a w tej wieży procek DSP (bynajmniej nie Digital sound procesor). DSP- procek z jednym rdzeniem przetwarzajacy jeden proces....a robi 4 rzeczy naraz full równolegle.. To czy to nazwiesz wątek, proces czy zajęty rdzeń to ma znaczenie w systemie ale tam na dole to wisi bo tam na dole masz przerośnięty tranzystor który kulawo dodaje i nic więcej nie umie robić. By było przetwarzanie równoległe musi być czas rzeczywisty i architektura np. kaskadowa a tego na pececie nie da się zrobić...ale można próbować-np. ifix. Napisany w C++, osobna powłoka windy...sam sobie rozdziela co robi a nie ze mu winda da 12 ms czasu. Dlatego jestem ciekaw czy w javie pokusił się ktoś o to....byłaby to nadbudówka nadbudówki na nadbudówce ale...przecież cała java tym własnie jest:)
To co się dzieje w DSP można nazwać superskalarnością, SIMDem, MIMDem etc
W x86 jest MMX, SSE, 3dNow! i tego typu rozszerzenia, też niby jeden wątek a 4 rzeczy równolegle. W Radeonach jest architektura shadera VLIW4, a same shadery pogrupowane są w SIMDach.
Wykonywanie jednego wątku na dwóch czy więcej rdzeniach (w necie widziałem określenie "reverse hyperthreading" na to) musi być cholernie nieefektywne, także pod względem zużycia powierzchni rdzenia. Zamiast tego stosuje się np parallel.for w C# czy równoległe kolekcje w nadchodzącej wersji Scali. Albo wspomniane wcześniej rozszerzenia wektorowe.
Procki o architekturze Nehalem mogą wykonywać naraz 4 różne instrukcje w jednym rdzeniu i taki bajer wymaga dużej kupy tranzystorów. Jeśli chciałbyś wykonywać naraz 50 różnych instrukcji z jednego strumienia kodu to sama logika zwiększyłaby rozmiar procka do wielkości porządnego kotleta.
Dwa procesy tym się różnią od dwóch wątków, że dwa procesy nie mogą sobie mieszać nawzajem w pamięci. Twój ulubiony sposób (tfu!) na wymianę danych między wątkami, czyli zmienne statyczne, nie ma szans bytu w przypadku wymiany danych między procesami.
MPI (albo pochodne) jest jedyną opcją (jak na razie, jeśli piszemy w C++), gdy piszemy programy na komputerki typu BlueGene, Roadrunner itp.
autor:
Polecam sprawdzić: http://akkasource.org/
Nie używałem, ale wygląda obiecująco. Udostępnia mechanizm Aktorów ze Scali w ulepszonej postaci z dobrym interfejsem do Javy.
No No...miło mieć naoczny dowód na to że ktoś czasami mojego posta przeczyta:) Zmienne statyczne...może nie tyle do wymiany danych, co do przekazywania sterowania (głównie to są flagi statyczne typu boolean, mniej inty). Zostało mi to z wykształcenia automatyki - w ten może i nieudolny sposób stosuje odpowienik "alertów" w programowaniu drabinkowych...nigdy nie mówiłem że to jest najlepsze rozwiazanie ale zdaje egzamin-a i jestem otwarty na sugestie.....
Co do esencji Twojej wypowiedzi - wspomniane rozszerzenia procka (mmx etc) to wg mnie nie to samo możliwośc wykonania równocześnie kilku operacji. mmx to dodatkowe instrukcje składające się z kilku mniejszych-takie combo potrzebujace mniej taktów procka niż gdyby tą instruckję rozbić na mniejsze. Zaoszczędzenie polega na samym rozłożeniu tranzystorów..ale dwie instrukcje mmx (czy każde inne)i tak muszę iśc sekwencyjnie a nie róznolegle.
Co do samej istoty tematu autora ...przyznam się że musze doczytać - ale jeszcze tu wrócę i coś mądręgo dodam (mam nadzieję).
Pozdrawiam
Większość współczesnych procków ma powielone jednostki wykonawcze i jest w stanie zdekodować naraz kilka instrukcji. Tak jak napisałem Nehalemy, Sandy Bridge od Intela, niedługo także Bulldozery od AMD dekodują max 4 instrukcje w jednym takcie i mogą je wykonać jeśli są od siebie niezależne. Aaaa, w sumie to dekodują trochę instrukcji naprzód i mogą je wykonywać poza kolejnością (out-of-order superscalar). Jeśli ktoś chce mieć możliwość wykonywania kilku różnych instrukcji naraz przez procesor, ale chce zaoszczędzić na logice to stosuje VLIW - czyli grupowanie niezależnych instrukcji w grupki o stałej szerokości; jeżeli ilość niezależnych instrukcji jest mniejsza od rozmiaru grupki to dopełnia się ją NOPami. Ma to tę wadę, że jeżeli instrukcje ciężko zrównoleglić (co zdarza się w większości przypadków w nieoptymalizowanym kodzie) to sporo w tym kodzie jest NOPów i tracimy niepotrzebnie pamięć i przepustowość na tak nadmiarowy kod. MMXy też mogą być wykonywane kilka naraz.
Jeśli chcesz się dowiedzieć co się dzieje w środku najpopularniejszych procków rozmiaru XXL, to zapraszam na stronę: http://www.agner.org/optimize/
W dokumencie instructions_tables.pdf masz rozpiskę czasów wykonywania, portów (potoków wykonawczych) do których lecą instrukcje itp Np Core i7 może wykonać dwie instrukcje typu PADD/SUB(U)(S)B/W/D/Q naraz.
Co do twojego przykładu:
(a+b) * (c + d) = e
Jeżeli wykonujemy go na listach wartości to np jeden wątek może zredukować (dodać do siebie) listy a i b, drugi wątek to samo z listami c i d, a trzeci zbierać wyniki z dwóch poprzednich i też redukować (mnożyć przez siebie). Wyniki pośrednie można wrzucać do jakiegoś cache, ale na tyle dużego, żeby koszty synchronizacji nie przewyższyły zysków ze zrównoleglania.
Co do ostatniego to zgoda- tylko esencją przetwarzania równoległego jest (w sumie pośrednio o tym napisaleś) jest autodetekcja sytuacji w której proces da się rozbić. Manualne ustawianie wątków które wykonywałyby częśc pracy strasznie związywałoby ręce i było mało "fleksyble".
Przeglądam ta bibliotekę JavaR co kolega powyżej dał namiar....ale ciężko mi wykminić z czego niby tam się bierze "zysk" i co ta biblioteka w ogóle umie ani jak to się wiąże z przetwarzaniem równoległym:/
Autodetekcję jak i samo zrównoleglanie masz prawie za darmo przy programowaniu funkcyjnym (o ile kompilator to wspiera) - brak mutowalnego stanu powoduje, że zrównoleglanie jest dość proste. Kolecje równoległe w Scali i konstrukcje parallel.for czy podobne w C# są tylko trochę gorsze pod tym względem od rozwiązań w językach czysto funkcyjnych, ponieważ musisz explicite zaznaczyć części kodu, które mają być rozbijane na wątki.
JavaR/ JavaB chyba rozbija pętle na wątki, oraz stosuje jakieś inne triki do detekcji niezależnych fragmentów kodu, które można wykonać w osobnych wątkach.
Napisz czym według ciebie jest to przetwarzanie równoległe, bo twoja definicja jest chyba bardzo egzotyczna i niezrozumiała.
Rozbijanie malutkich fragmentów kodu nienastawionego na wielowątkowość na wiele procesorów jest totalnie nieopłacalne, zwolni program wielokrotnie, ponieważ synchronizacja jest cholernie droga, no chyba że na jakichś mikroczymśtam jest tania, ale takie to można pominąć.