Liczenie na klastrze

[SGCNET]

Już kilka razy przeczytałem, że liczenie na klastrze nie jest opłacalne, nie rozumiem tego.

Klaster typu "Beowulf" złożony np. z 15 komputerów (C2D 2,2GHz, 2GB RAM), toretycznie powinien osiągnąć lepszą wydajność niż 15 pojedynczych komputerów.
Może mi ktoś to wytłumaczyć ? czemu lepiej przetwarzać na 15-stu pojedynczych komputerach, niż na jednym klastrze, który jest złożony z  15-stu komputerów ?

[stiven]

Zależy co liczyć. Zauważ, że BOINCOWE aplikacje są tak napisane aby duży kawał roboty porozdzielać na mniejsze, które nie wymagają komunikacji między sobą. Zysk w przypadku klastra obliczeniowego nad pojedynczymi komputerami polega przede wszystkim na tym, że poszczególne nody mają możliwość szybkiej komunikacji między sobą. BOINC, jak na razie, tego nie wykorzystuje i dlatego często pojawiają się głosy, że nie jest opłacalne zaprzęganie do roboty klastrów.

Problem jest jednak bardziej złożony. Należy się zastanowić nad samym pojęciem opłacalności. Najczęściej jest synonimem opłacalności ekonomicznej ale różnie przez różne osoby jest pojmowana. Np często brana jest pod uwagę tylko cena podzespołów bez uwzględniania prądu itp. Przy rozwiązaniach bardziej serwerowych/klastrowych nieco inaczej należy patrzeć na zasilanie i ilość potrzebnych monitorów. Temat na dłuższą dyskusję ale w największym skrócie przy tak jak obecnie napisanych aplikacjach nie poczujesz wielu zalet liczenia boinc ma klastrach. Jakieś doświadczenie w tej materii w drużynie jest więc pewnie ktoś niebawem poda przykłady mniej teoretyczne a bardziej praktyczne.

[Troll81]

Przede wszystkim BOINC powstał z innym zamysłem konstrukcyjnym. Założenie jest taki że dane zagadnienie miało być podzielone na wiele małych kroków. Wysłane do dużej ilości różnych komputerów. Te komputery co do zasady miały być PCtami. Mogły być niestabilne, dawać błędy, mieć wolne łącze. I pod te wymagania został skonstruowany cały BOINC. Oczywiście możesz zbudować klaster. Ale koszt takiego rozwiązania przekracza koszt PCta.

Załóżmy wiec że zbudujesz sobie w domu klaster z 15 komputerów PC. Jednakże ile będziesz musiał poświęcić czasu na ustawienie tego? Ile wiedzy potrzeba? Oczywiście korzystając z tego ze system operacyjny jest szczątkowy i kompy zajmą się tylko BOINCem na pewno zyskasz na wydajności. Pytanie ile? 5%? Różnica zaczyna być duża dopiero przy odpowiednim rozmiarze klastra. A dołóż do tego switche routery i inny osprzęt użyty. Oraz samo strojenie (każdy klaster jest tak szybki jak najwolniejszy element infrastruktury). Ale oczywiście zachęcamy do eksperymentowania i dzielenia się swoimi wrażeniami :D

[SGCNET]

Dziękuje za odpowiedzi.

Pytałem z ciekawości, ale kto wie... :)

[Troll81]

Ciekawość pierwszym krokiem do odkrycia :D

[krzyszp]

Sprawa "oplacalnosci" jest IMHO bardziej skomplikowana.
klaster mozna uruchomic z komputerow mocno okrojonych, gdzie dyski sa malutkie, bez monitorow, cd, itd... Faktycznie mozna tez tak zrobic z 15 osobnymi kompami i bedzie to prostsze rozwiazanie (technicznie dla skladajacego), jednak przy odpowiednim rozmiarze klastra, wraz z korzysciami plynacymi z okrojonego systemu moze to dac (np.) 15% wydajnosci (dokladajac zaoszczedzone na podzespolach pieniadze do np. lepszych prockow).
Sprawa jest warta glebszej analizy, rowniez poprzez rozne eksperymenty oszczednosciowe - np. skladanie klastra kilku kompow na jednym zasilaczu... Mozliwosci jest mnostwo, niestety sam nie posiadam wystarczajacej wiedzy, jak taki klaster skonfigurowac (po stronie systemu).

Gdybym dorwal jakis poradnik, ktory prosto tlumaczy konfiguracje klastra, moglbym testowo zaprzac dwa kompy (Athlon x2 i Jakies p4 na pokladzie) do testow (obecnie sie nudza).

Ps. Przepraszam za brak pl znakow, siedze przy kompie bez polskiego ukladu, a nie moge nic w nim zmieniac...

[Troll81]

samo złożenie sprzętu to jedno. Konfiguracja komunikacji pomiędzy węzłami to drugie. O ile klaster jest malutki to problemu nie ma. Zaczyna się jazda przy dużej ilości węzłów. Proponuje zacząć od pelikan HPC. Jeden komp bootujemy z płytki i staje się on węzłem głównym. Pozostałe kompy bootują poprzez LAN i stają się węzłami liczącymi (head node nie liczy). De facto jest to linux więc co pójdzie na linuksie i będzie w stanie wykorzystać tę architekturę to powinno dać się policzyć....

[SGCNET]

Pod koniec kwietnia przetestuje na 15-25 maszynach :}
Ale... najpierw muszę poczytać dokładniej o BOINC, zainstalowałem na kompie, dołączyłem do Einstein-a i Enigmy, coś tam mieli, ale nie wiem co :) nawet dołączyłem do zespołu B@P :) i tu kończy się moja wiedza odnośnie BOINC.

[Troll81]

Zadawaj pytania. Chętnie odpowiemy. Zajrzyj tez na naszą wiki.

[krzyszp]

... Proponuje zacząć od pelikan HPC. Jeden komp bootujemy z płytki i staje się on węzłem głównym. Pozostałe kompy bootują poprzez LAN i stają się węzłami liczącymi (head node nie liczy)...

Wierz mi, że od odpalenia z płytki, do w pełni funkcjonalnego (skonfigurowanego) klastra droga daleeeeeka...

[Troll81]

Ja tylko pokazałem początek drogi. Sam się bawiłem Pelicanem ale BOINC mi na nim nie chciał ruszyć :(

[Tomek_TB]

Liczenie na klastrach jest oplacalne, ale nie w BOINC, tak jak pisali koledzy, niestbilne lacza, rozne komputery, ect. to sa realia BOINC. Z innej strony, obliczenia inzynierskie, klasterek z 50-80 rdzeniami, potrafi zdzialac cuda w czasach obliczen i tu jest prawdziwy zysk z klastra, w porownaniu do BOINC. Bo koszta energii w porownaniu do kosztow ludzi, ect, nie sa takie wielkie.

Troche namotalem pewnie. |-?

[Ania]

BOINC to w zasadzie taki duży klaster.

[mariotti]

Klaster typu "Beowulf" złożony np. z 15 komputerów (C2D 2,2GHz, 2GB RAM), toretycznie powinien osiągnąć lepszą wydajność niż 15 pojedynczych komputerów.

Czym się różni klaster złożony z piętnastu komputerów od piętnastu komputerów? Myślałem że to jest to samo.
Pozdrawiam

[lolek]

W przypadku BOINC tworzenie klastrów jest bez sensu

[Dario666]

Jeśli chodzi o 15 komputerów, to każdy liczy swoje i są one od siebie niezależne.
Jeśli chodzi o klaster złożony z 15 komputerów, to działają one jak jeden "duży komputer". Przeważnie jeden komputer z nich jest wyznaczony jako zarządzający i on zajmuje się przygotowywaniem zadań dla pozostałych oraz odbiera i przechowuje wyniki. Pozostałe komputery to takie "woły robocze", które zwykle mają zainstalowany minimalistyczną wersję OSa bez GUI.

[gregre]

o proszę, znalazłem taką tanią wersję superkomputera ;D

Kod [Zaznacz] Rozwiń

http://www.youtube.com/watch?NR=1&v=hSVo4ejZ7rc&feature=fvwp

[Krzysiak]

Ciekawi mnie co to za test w 2,18 minucie filmu

[mariotti]

Jeśli chodzi o 15 komputerów, to każdy liczy swoje i są one od siebie niezależne.
Jeśli chodzi o klaster złożony z 15 komputerów, to działają one jak jeden "duży komputer". Przeważnie jeden komputer z nich jest wyznaczony jako zarządzający i on zajmuje się przygotowywaniem zadań dla pozostałych oraz odbiera i przechowuje wyniki. Pozostałe komputery to takie "woły robocze", które zwykle mają zainstalowany minimalistyczną wersję OSa bez GUI.

Jakie oprogramowanie ( wystarczą mi o nazwy pakietów na windows/linux, szczegóły sobie doczytam ) umożliwia
traktowanie 15tu komputerów jak jednego super-komputera?

Pozdrawiam

[krzyszp]

Kod [Zaznacz] Rozwiń

http://pl.wikipedia.org/wiki/Beowulf_%28informatyka%29

Kod [Zaznacz] Rozwiń

http://lumd.linux.pl/lecture/08/%5BLinux%20--%20u%20mnie%20dziala%5D%5B08%5DDomowy%20klaster.pdf

pelikan HPC

Pelikan jest chyba najlepszą odpowiedzią dla Ciebie...

Problemem jest to, że zysk wydajności z klastra jest w przypadku BOINC minimalny i nie warty wysiłku, pomijając oczywiście wartość dydaktyczną...
Nie chcę oczywiście umniejszać zalet tej techniki w innych zastosowaniach.

[goofyx]

ja ze swojego doświadczenia powiem tak, że jeśli chcesz liczyć boinc na klastrze to się nie opłaca.
Nie zależnie od konfiguracji dla zwykłych aplikacji w klastrze zawsze masz stratę wydajności np.: wydajność klastra typu BeoWolf to ok.75-80% osobnych sprzętów. Więc tak naprawdę tracisz 1-2 maszyny.
Klaster się opłaca jeśli aplikacja jest napisana strikte pod klaster wtedy wydajność masz na poziomie 90-95% bo zawsze są straty na synchronizacji i komunikacji.
Sporo o tym czytałem i a jeden taki próbowałem zbudować z 2 kumplami serwisantami na 6 komputerach  <- a tak naprawdę skończyło się na tym że 2 tygodniach 6 oddzielnych kompów liczyło boinca bez klastra.

[mariotti]

ja ze swojego doświadczenia powiem tak, że jeśli chcesz liczyć boinc na klastrze to się nie opłaca.
Nie zależnie od konfiguracji dla zwykłych aplikacji w klastrze zawsze masz stratę wydajności np.: wydajność klastra typu BeoWolf to ok.75-80% osobnych sprzętów. Więc tak naprawdę tracisz 1-2 maszyny.
Klaster się opłaca jeśli aplikacja jest napisana strikte pod klaster wtedy wydajność masz na poziomie 90-95% bo zawsze są straty na synchronizacji i komunikacji.
Sporo o tym czytałem i a jeden taki próbowałem zbudować z 2 kumplami serwisantami na 6 komputerach  <- a tak naprawdę skończyło się na tym że 2 tygodniach 6 oddzielnych kompów liczyło boinca bez klastra.

Wszystko się zgadza :)

[mariotti]

Sporo o tym czytałem i a jeden taki próbowałem zbudować z 2 kumplami serwisantami na 6 komputerach  <- a tak naprawdę skończyło się na tym że 2 tygodniach 6 oddzielnych kompów liczyło boinca bez klastra.

Jak to jest z rozwiązywaniem konfliktów w dostępie do pamięci na takich klastrach?

Normalnie gdy piszę aplikację wielowątkową, to dostęp do pamięci jest konkurencyjny.
Wątki zapisują jak leci, a platforma sprzętowa niewiele się martwi. Jeśli chcę zapobiec
temu żeby jeden wątek "psuł" dane drugiemu, to muszę posłużyć się sekcjami krytycznymi,
semaforami, albo tak napisać aplikację, żeby z konkurencyjnego zapisu do pamięci nie wynikały
powyższe problemy. Mechanizmy synchronizacji są bardzo kosztowne obliczeniowo, jeśli
aplikacja wielowątkowa źle się nimi posługuje, to działa (dużo) wolniej niż aplikacja jednowątkowa.

Jak się pisze aplikację na taki klaster? Też używa się sekcji krytycznych i semaforów?
Jest jakieś specjalne API do tego celu? Czy może dobrze napisaną aplikację wielowątkową
da się uruchomić na klastrze bez żadnych modyfikacji, a oprogramowanie klastrowe
samo wszystko zrobi?

Pozdrawiam

[Sebastian M. Bobrecki]

Używasz np. MPI/MPICH/2 lub czegoś podobnego.

[Rysiu]

Jak to jest z rozwiązywaniem konfliktów w dostępie do pamięci na takich klastrach?

Wykorzystujesz API pozwalające na przesyłanie danych między węzłami obliczeniowymi. Jeżeli dany węzeł nie posiada jakiejś zmiennej we własnej pamięci to musi ją pobrać przez sieć od innego węzła. Masz tam dostępne także metody synchronizacji, redukcji itp.

Jest jakieś specjalne API do tego celu?

Najczęściej teraz jest to MPI.

Czy może dobrze napisaną aplikację wielowątkową
da się uruchomić na klastrze bez żadnych modyfikacji, a oprogramowanie klastrowe
samo wszystko zrobi?

Niestety nie jest tak pięknie. Trzeba program dostosować do MPI.

[mariotti]

[...]
Niestety nie jest tak pięknie. Trzeba program dostosować do MPI.

Dzięki za wszystkie odpowiedzi.  Tak właśnie mi się wydawało, że nie ma szans
aby automatycznie aplikację wielowątkową przenieść na środowisko rozproszone, a
ktoś mnie próbował przekonać że to jest możliwe :)

Swoją drogą fajne to MPI, chyba pora się nauczyć. Gdy kilka lat temu pisałem
swój klaster, to wszystko zrobiłem zwyczajnie na socketach :)

Pozdrawiam

[goofyx]

[...]
Niestety nie jest tak pięknie. Trzeba program dostosować do MPI.

Dzięki za wszystkie odpowiedzi.  Tak właśnie mi się wydawało, że nie ma szans
aby automatycznie aplikację wielowątkową przenieść na środowisko rozproszone, a
ktoś mnie próbował przekonać że to jest możliwe :)

ja myślałem dokładnie to samo.
dlatego namówiłem kumpli na ten eksperyment, który sporo nas nauczył.

Swoją drogą fajne to MPI, chyba pora się nauczyć. Gdy kilka lat temu pisałem
swój klaster, to wszystko zrobiłem zwyczajnie na socketach :)

Jeśli chcesz pracować z klastrami to MPI itp jest wiedzą wymaganą jeśli nie to po prostu poczytaj o tym tak jak ja i potraktuj to jako ciekawostkę.

[mariotti]

Jeśli chcesz pracować z klastrami to MPI itp jest wiedzą wymaganą jeśli nie to po prostu poczytaj o tym tak jak ja i potraktuj to jako ciekawostkę.

Pora się nauczyć gotowca, zamiast ciągle wymyślać koło na nowo :)
Nie wiem jak wygląda całość, ale ta część na wiki wydaje się prosta:
http://pl.wikipedia.org/wiki/MPICH

Pozdrawiam

[Sebastian M. Bobrecki]

Dzięki za wszystkie odpowiedzi.  Tak właśnie mi się wydawało, że nie ma szans
aby automatycznie aplikację wielowątkową przenieść na środowisko rozproszone, a
ktoś mnie próbował przekonać że to jest możliwe :)
...

Zasadniczo możliwe jest. Widziałem takie rozwiązanie gdzie system zapewniał takie środowisko w którym cała pamięć wszystkich węzłów jest przez nie widoczna jak ich własna. Wygląda to jaka tak wielopoziomowa NUMA. Węzły były spięte Infiniband-em a wymiana pamięci odbywała się za pomocą RDMA. Migracja procesów i wątków odbywała się podobnie jak ma to miejsce w klastrach MOSIX-owych. Użycie takiego środowiska ma sens jeśli z jakiegoś powodu nie można stworzyć/dostosować aplikacji (np. nie ma dostępnych źródeł) lub zagadnienie ma np. ogromne wymagania co do pamięci. Niestety wiąże się to ze znaczną utratą wydajności. Zależy jak aplikacja używa pamięci i czy jest "świadoma" różnych kosztów dostępu do pamięci (cache, ram lokalnego cpu, ram innego cpu w tym samym węźle, ram innego węzła i tu jeszcze zależy czy jest full mesh czy do różnych węzłów koszt jest inny).

Niemniej uważam że najlepszym rozwiązaniem jest mniej więcej takie podejście jak w boinc-u. Czyli każdy węzeł liczy niezależnie swój kawałek i nie ma żadnej utraty wydajności związanej z transferami czy synchronizacją. Natomiast istnieją problemy których w takim modelu z różnych względów rozwiązać się nie da (np. potrzeba wielkich pojemności pamięci, lub wymagało by to ogromnych transferów i/czy duplikacji danych).

[mariotti]

Zasadniczo możliwe jest. Widziałem takie rozwiązanie gdzie system zapewniał takie środowisko w którym cała pamięć wszystkich węzłów jest przez nie widoczna jak ich własna.

Technicznie mogę sobie wyobrazić że jest to możliwe, ale nie rozumiem jaki to ma sens.

Zawsze gdy program startuje, to mamy na początku jeden wątek. Tutaj nie ma żadnych
problemów. Potem program się rozwidla albo na procesy, albo na wątki.

Gdy rozwidla się na wątki, to każdy wątek ma dostęp do swojej pamięci na stosie. Wątek jest
uruchamiany w pewnym sensie podobnie jak wywołanie procedury, a procedura ma
zarezerwowany jakiś rozmiar stosu dla siebie. Poza tym wątek ma dostęp do pamięci procesu.

Gdy rozwidla się na procesy, to zwykle przed rozwidleniem jakaś część pamięci RAM jest
oznaczana jako współdzielona przez te procesy.

Więc w obu przypadkach mamy podobną sytuację: wątki/procesy mają jakiś obszar pamięci
wyłącznie dla siebie i obszar pamięci wspólnej. W momencie gdy wątek/proces pisze albo
czyta do swojej pamięci, to nie ma najmniejszego problemu aby uruchomić go na
oddzielnej maszynie. Ale gdy dochodzi do zapisu na pamięci wspólnej, to system musi
wygenerować jakieś przerwanie, następnie musi:
1) obliczenia na wszystkich węzłach zatrzymać
2) pamięć na wszystkich węzłach zaktualizować
3) obliczenia wznowić.

Może dochodzić do takiej sytuacji, gdy dwa procesy na różnych maszynach w podobnym
czasie będą próbowały dokonać zapisu do pamięci wspólnej. Wtedy system musiałby
jeszcze rozwiązywać konflikty, musiałby jakoś kolejkować żądania zapisu.
W praktyce co jedną instrukcję może być koniecznośćtransferowania danych i w
typowych programach wielowątkowych często tak jest.

Wygląda to jaka tak wielopoziomowa NUMA. Węzły były spięte Infiniband-em a wymiana pamięci odbywała się za pomocą RDMA. Migracja procesów i wątków odbywała się podobnie jak ma to miejsce w klastrach MOSIX-owych. Użycie takiego środowiska ma sens jeśli z jakiegoś powodu nie można stworzyć/dostosować aplikacji (np. nie ma dostępnych źródeł) lub zagadnienie ma np. ogromne wymagania co do pamięci. Niestety wiąże się to ze znaczną utratą wydajności.

Myślę że większość aplikacji zadziała w takim środowisku wolniej niż na jednym komputerze.

Zależy jak aplikacja używa pamięci i czy jest "świadoma" różnych kosztów dostępu do pamięci (cache, ram lokalnego cpu, ram innego cpu w tym
samym węźle, ram innego węzła i tu jeszcze zależy czy jest full mesh czy do różnych węzłów koszt jest inny).

Zwykle aplikacje pisane wielowątkowo nie są tego świadome, albo są świadome tylko kosztu lokalnego cache i całej pamięci.

Niemniej uważam że najlepszym rozwiązaniem jest mniej więcej takie podejście jak w boinc-u. Czyli każdy węzeł liczy niezależnie swój kawałek i nie ma żadnej utraty wydajności związanej z transferami czy synchronizacją. Natomiast istnieją problemy których w takim modelu z różnych względów rozwiązać się nie da (np. potrzeba wielkich pojemności pamięci, lub wymagało by to ogromnych transferów i/czy duplikacji danych).

Tu się zgadzam w całości. Jeśli to tylko możliwe w danym zadaniu, to należy zrobić coś podobnego do BOINC.


Pozdrawiam

[Sebastian M. Bobrecki]

Technicznie mogę sobie wyobrazić że jest to możliwe, ale nie rozumiem jaki to ma sens.

Tak jak pisałem np. są zadania które wymagają tak dużej ilości pamięci że nie jest w stanie tego obsłużyć pojedyncza maszyna (tera czy petabajty). Dzięki takiemu rozwiązaniu można w miarę efektywnie wykorzystać kontrolery pamięci wielu procesorów.

Zawsze gdy program startuje, to mamy na początku jeden wątek. Tutaj nie ma żadnych
problemów. Potem program się rozwidla albo na procesy, albo na wątki.

Gdy rozwidla się na wątki, to każdy wątek ma dostęp do swojej pamięci na stosie. Wątek jest
uruchamiany w pewnym sensie podobnie jak wywołanie procedury, a procedura ma
zarezerwowany jakiś rozmiar stosu dla siebie. Poza tym wątek ma dostęp do pamięci procesu.

Gdy rozwidla się na procesy, to zwykle przed rozwidleniem jakaś część pamięci RAM jest
oznaczana jako współdzielona przez te procesy.

Więc w obu przypadkach mamy podobną sytuację: wątki/procesy mają jakiś obszar pamięci
wyłącznie dla siebie i obszar pamięci wspólnej. W momencie gdy wątek/proces pisze albo
czyta do swojej pamięci, to nie ma najmniejszego problemu aby uruchomić go na
oddzielnej maszynie. Ale gdy dochodzi do zapisu na pamięci wspólnej, to system musi
wygenerować jakieś przerwanie, następnie musi:

Problemy synchronizacji zawsze występują w każdym środowisku w którym współbieżnie działają programy. Ba nawet przeciętna maszyna x86 z tylko jednym procesorem logicznym ma konieczność wprowadzania pewnych mechanizmów synchronizacji choćby dla ochrony obszarów transmisji DMA, urządzeń działających w trybie BusMaster czy MMIO, itp., itd.

1) obliczenia na wszystkich węzłach zatrzymać
2) pamięć na wszystkich węzłach zaktualizować
3) obliczenia wznowić.

Jak wyżej, w środowisku współbieżnym zawsze może dojść rywalizacji o blokady. Natomiast pamięci nie musisz aktualizować na wszystkich węzłach a tylko na tym/ch który/e fizycznie ten fragment przechowuje/ą. Ewentualnie należy rozgłosić informacje o konieczności unieważnienia danej strony pamięci jeśli jest gdzieś cache-owana. Tak właśnie działa architektura ccNUMA. Która jest używana także w małych wieloprocesorowych systemach x86/x86-64 od czasów procesorów Opteron dla AMD i Xeonów bazujących na architekturze i7 u Intel-a. Tyle że tu poza załóżmy cache-m L1, L2, L3, RAM-em lokalnego kontrolera, RAM-em kontrolera w innym procesorze (+dystans do tego kontrolera, w systemach z 4 lub więcej podstawkami często nie wszystkie chip-y są ze sobą połączone bezpośredni i wtedy dostęp do pamięci może się odbywać z pośrednictwem interfejsów HT, PQI itp. innych chipów), mamy jeszcze dodatkowy poziom w postaci dostępu do pamięci znajdującej się fizycznie w innym węźle.

Może dochodzić do takiej sytuacji, gdy dwa procesy na różnych maszynach w podobnym
czasie będą próbowały dokonać zapisu do pamięci wspólnej. Wtedy system musiałby
jeszcze rozwiązywać konflikty, musiałby jakoś kolejkować żądania zapisu.
W praktyce co jedną instrukcję może być koniecznośćtransferowania danych i w
typowych programach wielowątkowych często tak jest.

Oczywiście i dlatego tak jak dla aplikacji wielowątkowych działających w jednym systemie tak i dla takich bardziej rozbudowanych architektur istnieją odpowiednie mechanizmy które o to dbają. Istnieją rozwiązania które dbają o to by odpowiednio obsłużyć standardowe mechanizmy takie jak np. futex w takim środowisku. W zasadzie nie różnią się bardzo od tych które są używane w normalnym pojedynczym systemie z architekturą ccNUMA. System operacyjny jest tak przystosowany by starać się migrować procesy/wątki na węzły/procesory/rdzenie bliżej obszaru roboczego pamięci i/lub migrują obszar pamięci na węzeł/kontroler bliższy rdzenia na którym działa proces/wątek w zależności co uważa za tańsze i czy w ogóle ma sens. Decyzje podejmuje na podstawie pewnych standardowych algorytmów które opierają się na różnych statystykach działania procesu/wątku (typu czas działania, wielkość obszaru pamięci, ilość dostępów do pamięci lokalnej i zdalnej, proporcja ilości dostępów do pamięci w stosunku do innych operacji, odległość między aktywną jednostką wykonawczą a obszarem danych, itp., itd.), lub aplikacja może być napisana tak by informować system o swoim zachowaniu (np. w Linux-ie mamy i automatyczne mechanizmy systemowe jak i możliwość skorzystania z biblioteki libnuma itp.)

Myślę że większość aplikacji zadziała w takim środowisku wolniej niż na jednym komputerze.

Zasadniczo masz rację. Są jednak takie zagadnienia których pojedyncza maszyn po prostu nie jest w stanie udźwignąć np. ze względu na wielkość pamięci czy jej szybkość. Czasami też utrata wydajności związana z potrzebą synchronizacji i lokalizacji w rozbudowanym systemie jest akceptowalna w stosunku do korzyści wynikających z możliwości relatywnie szybkiego (w stosunku do innych metod komunikacji) dostępu do pamięci o dużych pojemnościach. Wszytko zależy często nie tyle od samej aplikacji (w sensie jej kodu i możliwości jego modyfikacji) a od problemu jaki trzeba rozwiązać. Żeby daleko nie szukać np. w projekcie Einstein@home zanim dane są rozsyłane do ludzi są najpierw obrabiane przez klaster (bodajże nazywa się ATLAS). Wynika to z tego że danych które uzyskuje się z instrumentów typu LIGO są  ogromne ilości a trzeba je poddać najpierw wstępnej analizie przed podzieleniem żeby odnaleźć pewne ich właściwości które będą pomocne przy późniejszej analizie (którą robimy już my BOINC-iem). I potem używa się go żeby złożyć wszystkie wyniki cząstkowe (z BOINC-z) w jedną całość i poddać finalnej analizie. I właśnie dzięki takiej architekturze można załadować wszystkie te dane do pamięci klastra i mieć do nich szybki dostęp nawet w tych miejscach analizy które się słabo zrównoleglają lub wymagają całkowitej serializacji.

Zwykle aplikacje pisane wielowątkowo nie są tego świadome, albo są świadome tylko kosztu lokalnego cache i całej pamięci.

Jeszcze do niedawna tak było. Ale z racji tego że praktycznie wszystkie nowe popularne platformy serwerowe mają architekturę ccNUMA coraz więcej aplikacji jest do niej lepiej lub gorzej przystosowana. Np. taki popularny RDBMS jakim jest MySQL w systemie Linux działającym na architekturze ccNUMA (np. już nie taki nowy serwer z dwoma procesorami Xeon E5504 z których każdy ma lokalny kontroler obsadzony modułami pamięci) instruuje system by ten starał się alokować pamięć dla wątku realizującego zapytanie jak najbliżej rdzenia na którym się ten wątek wykonuje. Natomiast w przypadku częstego dostępu do części dużego wspólnego obszaru jakim jest np. "InnoDB buffer pool" (który zwykle ze względu na swoją wielkość znajduje się fizycznie częściowo w obszarze kontrolera pierwszego procesora a częściowo drugiego) instruuje system by przeniósł wątek na rdzeń najbliższy temu obszarowi.

Tu się zgadzam w całości. Jeśli to tylko możliwe w danym zadaniu, to należy zrobić coś podobnego do BOINC.

Dokładnie tak, niestety są zagadnienia których w ten sposób nie tyle że rozwiązać się nie da (bo zawsze się da), co byłoby to nie nieefektywne i/lub niepraktyczne.

Także pozdrawiam