Napisać aplikację chociażby na dwa rdzenie to sztuka, jeszcze długo multiprocessing będzie niestety nie wykorzystywany tak jak powinien być



---
Wydzielone z http://forum.php.pl/index.php?showtopic=70637

Jądro linuxa to już potrafi. Podejrzewam, że jądro Windowsa też, bo inaczej to by była straszna tępota! A to już wystarczy, żeby oba rdzenie się zgrzały! (bo jedenemu rdzeniowi przydzieli się proce X, drugiemu Y i będzie dobrze)

@Jabol: To nie tak działa. Ostatnio o tym dużo czytałem i nie jest niestety tak, że system operacyjny przydziela jeden proces do jednego rdzenia a drugi do innego. Póki co jest po staremu, czyli OS przydziela czas pracy procka, nieważne ile jest rdzeni. I tu mamy pewien problem, bo napisanie aplikacji na np. dwa rdzenie wymaga często ogromnej ilości dodatkowego kodu, rozbijania nawet prostych funkcji na kilka jeszcze mniejszych, ale dających się wykonać symultanicznie. Do tego dochodzi problem ze skalowalnością, napisanie aplikacji skalowanej na X rdzeni to już naprawdę kombinacja norweska. Nie twierdzę że się nie da, ale po prościej napisać coś wydajnego na jeden rdzeń.

Ale jeśli masz informację o tym że Kernel Linux przydziela procesy do rdzeni, to będę bardzo wdzięczny za jakiegoś linka. Bo skupiałem się na Windowsie, mogłem więc sporo przeoczyć.

---
Wypad mi z tym offtopikiem - tiraeth

To a potem tekst o programowaniu... wychodzi na to że jest to o czym wcześniej pisałem. Drugi tekst też przejrzałam.

To jest tak: Mamy X procesorów/rdzeni i każdy z nich ma dostęp do wspólnego ramu i cache L2. I teraz kernel ma ileś tam wątków (thread) i rozdziela je na poszczególne rdzenie, normalka nic nowego. Ale potem dochodzą aplikacje które nie są jądrem(ale są dzielone tak jak wątki jądra). Ogromny wzrost wydajności dawał by OS który rozdziela tak:
CORE1 -> Process1, Process2
CORE2 -> Process3, Process4, Process5

Ale niestety(?) wygląda to tak:
CORE1 -> Process1-Thread1, Process2-Thread1, Process2-Thread2, Process3-Thread1
CORE2 -> Process1-Thread2, Process3-Thread2

A to jaki wątek zostanie przydzielony do którego rdzenia to zależy od programistów danej aplikacji. Czemu pierwszy wariant nie został wprowadzony? Chyba było by przepisać wtedy całe jadro od nowa (czy to linuxa, czy windowsa). Ale drugi wariant, ten używany nie zmuszał do radykalnych zmian w jądrze. Do tego przy dobrze napisanej aplikacji i stosunku potrzebnej mocy dla samego OS'a a mocy rzeczywistej pojedynczego rdzenia, jest o wiele bardziej wydajny. Oczywiście to zależy też wszystko od aplikacji. Dla PHP jako CGI na serwerze na pewno pierwszy wariant jest lepszy, ale dla aplikacji typu Soundbooth, czy VirtualDub drógi sposób jest jednak lepszy (chodzi mi to o zastosowania, nie o same rzeczywiste aplikacje).

I teraz dojdę do pointy. Program na wiele rdzeni napisać jest bardzo trudno. Jest nie wiele takich porządnie napisanych aplikacji dostepnych na rynku. Tak więc kupowanie wielordzeniowego procka z punktu widzenia wydajności jest prawie bez sensu. ALE!!! na rynku pozostało niewiele procków jednordzeniowych i do tego są to bardzo słabe modele. A stosunek wydajność/cena C2D na razie bije konkurencję na głowę. Tak samo jak swego czasu P4 zostawał daleko w tyle za konkurencyjnym AMD jeszcze jakiś czas temu.

Jak chcesz to wydziel do osobnego wątku nasz wypociny drogi ~tiraeth'cie

@sztosz: nie zgodzę się zupełnie! Jeżeli masz aplikacje wielowątkową to dobrze, że jej poszczególne wątki są rozprowadzane, na różne procesory/rdzenie! Przecież po tą są wątkami, żeby działać niezależnie. Jedyny problem to dostęp do pamięci dzielonej (synchronizacja L1). Ale to nie problem programistów jądra, tylko twórców procesora. A z tym multiprocessoringiem to jak grasz w coś to niewiele Ci to daje (bo gra to jeden proces). Ale jak masz właśnie aplikacje w PHP jako CGI to wzrost wydajności jest 2X! Pomyśl - 2 skrypty mogą się wykonywać równocześnie, bo to przeciesz różne procesy! Z tymi wątkami to nie jestem pewien jak jest bo to FAQ jest niejasne (punkty 3.1.1 i 3.1.3 sobie przeczą). Może chodzi o dwie biblioteki do wątków. Inna sprawa, że to FAQ jest dość stare. W każdym razie multiprocessing daje spory wzrost wydajności jeżeli działa wiele aplikacji (procesów) od siebie niezależnych, inaczej sprawa wygląda, gdy np. korzysta się z nieodpowiedniej biblioteki do wątków albo potrzeba je cały czas synhronizować...

Właśnie że zgadzasz się ze mną zupełnie.

Oddzielmy dwie sprawy:
Proces - aplikacja uruchomiona która może zawierać wiele wątków.
Wątki - to z czego składa się proces.

W procesie np. winamp, jeden wątek odpowiada za odtwarzanie muzyki i updateowanie informacji o pozycji w pliku (minuty, sekundy), drugi odpowiada za obsługę np. biblioteki mediów. Ale to są dwa wątki, a nie dwa procesy.

Tak więc kilka wątków rozdzielonych na kilka rdzeni to wzrost!
Ale kilka procesów już nie jest rozdzielanych na kilka rdzeni (PHP jako CGI) i brak wzrostu!

A co do bibliotek, to potrzebne są nowe konstrukcje w języku, albo odpowiednie biblioteki, wrappery, które pozwolą na multiprocessing.

2 CPU, dwie aplikacje, i zajmuja 100% mocy cpów (w windzie 100% to dwa cpu zajete na maxa) i jak widac zostaly rozdzielone na osobne cpu (nie rdzenie, bo niemam dwurdzeniowca)

sztosz: nie rozumiesz. jak jest jedno wywołanie serwera, to oczywiście nie będzie się wykonywało na dwóch procesorach. Ale jak masz dwie aplikacje to będą. I jak masz dwa jedoczesne wywołania do serwera to oba się wykonają na oddzielnych procesorach. O to właśnie dba sheduler.
Dlatego jest duży przyrost, gdy działa wiele aplikacji albo jedna (albo i więcej) wielowątkowych. Mały wzrost by był jakby działał jakiś alorytm potrzebujący dużo mocy a nie napisany wielowątkowo. Wtedy nie można mu dać obu procesorów. Ale mało jest takich aplikacji, a dla większości dzisiejsze procesory w takiej mocy jaką posiadają pojedyńczo i tak są wystarczające.

Hmm... coś mi nie pasuje. Muszę jeszcze więcej poczytać Tymczasem milknę, bo myślałem, że więcej wiem.