Forum PHP.pl

Witam szanowne grono,

Przyszłość idzie OSTRO w procesory Mulit-Core i wątki, specjaliści od Hardware doszli do swoich granic, już wiemy, że granica prędkości procesorów zatrzymała się w obrębie 3-4 GHz, od kilku ładnych lat sprzęt idzie w procesory z kilkoma rdzeniami, początkowo były to dwa, obecnie dla nikogo nie jest już niczym nadzwyczajnym posiadanie procesora 4-ro rdzeniowego i 8-mio wątkowego.

Za 5-10 lat płyty z kilkoma procesorami, które posiadają po x-dziesiąt rdzeni i x-dziesiąt wątków nie będą niczym nadzwyczajnym. Świat zmierza w tym kierunku. To jedyna droga. A pociąg PHP jakby zatrzymał się na torach jednowątkowych.

Proszę o informację, czy słyszeliście coś na temat rozwoju PHP w tym kierunku? Czy "Internalsi" coś o tym wspominali? Wiem, że jest rozszerzenie do PHP, ale sam core języka nie wspiera żadnej wielowątkowości.

Ja się zaczynam martwić, nie chciałbym, aby za kilka lat ten język okazał się "Toyem" do wizytówek, który wykorzystuje 1/50 mocy sprzętu.

Ten post edytował Dejmien_85 18.04.2015, 19:27:00

Nie widzę potrzeby aby w PHP mieli wprowadzić wielowątkowość (dostępną z poziomu języka). Moim zdaniem lepiej aby klient korzystał z jednego wątku i na każdy wątek wrzucić innego klienta do obsługi, niż aby jeden klient korzystał z wielu wątków i wstrzymywał innych. Pewnie aktualnie już tak demon po stronie serwera działa, nie wnikałem w implementacje.

Obecnie na rynku dla zwykłego śmiertelnika występują procesory 4-8 rdzeniowe. Tak zwane super-komputery mają od 60 do 1024 rdzeni. 2 rdzenie i 4 watki to norma.

Wiemy jak technika idzie do przodu, za 10 lat posiadanie procesora z 60 rdzeniami będzie normą - czy nadal uważasz, że nie widzisz potrzeby, aby w PHP wprowadzać obsługę procesorów wielordzeniowych/wątkowych?

Biorąc przykład z innych języków, weźmy Javę (oprócz PHP piszę także w tym języku), tutaj wielowątkowość to norma, a przykładowo w pisaniu aplikacji pod Androida wymuszane jest w pewnych miejscach używanie wątków (program nie zadziała, OS wywali błąd o tym, że używasz głównego wątku).

Wydaje mi się, że jeśli ten temat nie zostanie poruszany, to PHP w przyszłości umrze śmiercią naturalną (niedostosowanie się do warunków) - to chyba jedyny z popularnych języków (koledzy PHP, tj.Python i Ruby wspierają wielowątkowość z poziomu core języka), który nie wspiera wielowątkowości (jedynie przez rozszerzenie).

PHP w odróżnieniu od Ruby i Pythona także nie wspomina słowem o wielowątkowości - ani w tutorialach, ani w książkach, czy kursach. Jesteśmy z tym tematem z tyłu. To będzie bolało, jeśli nic się nie zmieni.

Super, zdales sobie z tego sprawę. To pierwszy krok. Prościej niż zmienić język będzie nauka nowego... Py jest prosty. Django wchodzi bajecznie szybko w odróżnieniu od zenda. Ja bym php nie ruszal ponad pisanie wizytówek / sklepów.

Nie do końca rozumiem czego Ci brakuje - wielowątkowości w samym PHP, czy obsługi wielu rdzeni na poziomie serwera.

Wykorzystanie rdzeni
Tym generalnie zajmuje się system i core języka (serwer www, interpreter PHP). Programista aplikacji www generalnie się do tego nie dotyka.

Wielowątkowość w PHP
Odrębną kwestią jest wielowątkowość w samym języku dostępna dla programisty.
W przypadku aplikacji desktop'owych, gdzie na jednym PC pracuje jedna instancja programu - rozbijanie na wątki może znacznie zwiększyć wydajność aplikacji.
Inaczej jest, jeśli przechodzimy do web (oczywiście w przypadku, gdy strona ma więcej użytkowników niż jest rdzeni w serwerze ;-) ). Tutaj mamy setki procesów, które są już obsługiwane przez system za pomocą dostępnych zasobów. Zatem jeśli żądań jest więcej niż rdzeni to serwer wykorzysta je wszystkie - nawet jeśli interpreter sam w sobie nie obsługuje wielowątkowości.

Przykładem mogą być bardzo wymagające aplikacje, które korzystają z wielu różnych serwisów na raz i wykonują wiele działań podczas jednego żądania HTTP. Wtedy owszem jest sens rozbijać zadania na wątki - głównie ze względu, że asynchroniczne obsłużenie wszystkich działań będzie szybsze niż wykonanie ich jeden po drugim. Tym bardziej jeśli nie ma między nimi bardzo dużych zależności (jeden proces nie czeka na dane z drugiego).

Co do możliwości samego PHP to przecież jest http://docs.php.net/manual/en/book.pthreads.php


Jeśli patrzymy na temat z punktu widzenia www, to największe znaczenie ma sposób powiązania serwera www z PHP: CGI, FastCGI, mod-php, PHP-FPM, SuPHP.

Zauważ, że domyślne implementacje Pythona i Rubiego mają GIL, czyli wielowątkowość jest teoretyczna.

Wszystko zależy od zastosowania. W rozwiązaniach serwerowych można skorzystać z wielu procesów czy Tornado, stąd w modelu klient-serwer GIL nie ma praktycznego znaczenia. Są również implementacje Pythona, które są pozbawione tego problemu.
http://www.jeffknupp.com/blog/2013/06/30/p...blem-revisited/

Tornado jest po prostu frameworkiem z nieblokującym i/o. Cokolwiek asynchronicznego musi być napisane specjalnie dla tego wzroca. PyPy sporo laguje za pełną wersją nie mówiąc o IronPythonie albo wersją na jvm. Zresztą wszystko do czego są zdolne python i ruby to uruchamianie os'wych wątków, w sumie to standard w językach skryptowych.

Jednak nadal zgadzam się z vokielem. W zastosowaniach PHP nie ma sensu jakaś wielowątkowość. Jedno co to odrobina asynchronicznego i/o (jak tornado czy node.js), ale sama wielowątkowość niech będzie osiągnięta przez izolowane instancje interpretera i komunikacja przez kopiowanie na jakimkolwiek brokerze, który asynchroniczne i/o implementuje (kolejka db, redis czy amq).

No, nie ruszałbyś pod pisanie sklepów i wizytówek, powiadasz. Tylko w Software House'ach obecnie TOP3 technologii wygląda następująco: .NET, Java, PHP.

Odkąd pracuję w większych corpo, to ciągle mamy duże i skomplikowane systemy, które rozwijamy średnio przez rok czasu (czasem dłużej) w zespołach od kilku do kilkudziesięciu osób - co prawda na początku swojej pracy byłem zdziwiony, że takie rzeczy powstają na PHP, ale teraz to już normalność.

PHP to nie tylko wizytówki i sklepy, ale także naprawdę ciężkie systemy. I teraz zastanawiam się co będzie za kilka lat - to, że wielowątkowość i procesory wielordzeniowe nie powinny być obce programistom jest już jasne, ten temat już wielokrotnie nagłaśniali znani nam guru programowania, ciągle w głowie mam ich słowa typu: "Widzę, że większość żyje jeszcze w świecie pisania programów jednowątkowych, bla, bla... czas się przebudzić i skorzystać z tych i7 itd".

I wydaje mi się, że świat PHP żyje w słodkim letargu - jakbyśmy ciągle żyli w 2000 roku. Python i Ruby mają przynajmniej wsparcie do wątków bez rozszerzeń. W PHP jest to realizowane za pomocą rozszerzeń - moim zdaniem to naprawdę mocne uchybienie i kolejny powód do tego, aby hejterzy PHP zrywali boki.

To w takim razie wypadałoby się go najpierw nauczyć Panie kolego (IMG:style_emoticons/default/wink.gif)



Rzeczywiście mogą się pojawić sytuacje, w których wątkowanie może okazać się przydatne. Nie mniej jeśli chcesz go używać, to istnieje wysokie prawdopodobieństwo, że wybrałeś złe rozwiązanie do danego problemu. Jeśli mimo wszystko jednak potrzebujesz użyć wątkowania, to jest do tego biblioteka pthreads, przy czym nie rozumiem zupełnie narzekania, że "trzeba ją zainstalować". Sama potrzeba użycia wątków w PHP jest dość rzadka. a instalacja z PECL jest prosta jak budowa cepa. To trochę jakbyś narzekał, że w C/C++ trzeba napisać #include<biblioteka.h>, żeby użyć jej funkcji.

Ale współbieżność nie jest używana w Javie w warstwie logiki biznesowej - w serwerze, sterownikach i tak dalej owszem - a tylko to pisze się w PHP. Tam gdzie używa się PHP nie ma potrzeby wielowątkowości, a ponieważ to jest trudny temat (i mam na myśli reczywiście trudny a nie "niedoczytałem-tutoriala-trudny") to nie ma sensu nawet próbować, skoro zysków zbytnio nie będzie. Logika biznesowa to drobnica, każde żądanie zmieści się w jednym wątku, a skoro mamy tak ładnie rozdrobniony problem to po co go zmieniać?

Nie tylko w PHP. Sa implementacje ruby i pythona ktore sobie radza z GIL. Takze serwery mozna pisac w innych technologiach niz te ktore znasz.. php to czasem jeszcze sie posilkuje przy serwowaniu widokow jesli strona potrzebuje mocnego seo, a tak to tylko django i angular.. nie widze sensu pisania calych aplikacji w php... nie te czasy.

Czyli większość tutaj nawet nie dopuszcza do myśli nowej rzeczywistości - smutne to!



w C i C++ wielkowątkowość to standard (jest zawarty w standardowych bibliotekach), więc powyższe porównanie jest kompletnie z pupy - delikatnie to ujmując.

To co mnie boli to fakt, że w każdej książce do Pythona, Rubyego, Javy, C, czy C++ natykasz się na temat wątków, zanim dobrniesz do połowy książki - w PHP ten temat nie istnieje. Nawet w książkach "SUPER POWER PRO PHP".

Po prostu... jakbyśmy byli w 2000 roku.

Zakładam, że za kilka lat ktoś będzie tego żałował - PHP zacznie staczać się na dół, unless... UNLESS...!

Ten post edytował Dejmien_85 22.04.2015, 16:47:34

Wielu z nas/was bolą po prostu... przyzwyczajenia.

Zawsze traktowałem php jako pomost i jest świetny.. na początek. Ale im bardziej wchodziłem tym bardziej szukałem alternatyw. Kompletnie nie rozumiem przywiązania do tego języka. Nie hejtuje was.. po prostu nie rozumiem.

Hehe, nie wrzucaj wszystkich do jednego worka, dla mnie (i pewnie dla wielu osób tutaj) PHP to jedna z X technologii, które używamy, przywiązanie jest standardowe - znasz coś, to korzystasz i chcesz, aby dana technologia się rozwijała, by można było z niej w razie możliwości korzystać.

Nie rób z tutejszych ludzi sierot, które widzą tylko PHP. ; }

Proszę Cię także o nie zbaczanie z tematu.

Ten post edytował Dejmien_85 22.04.2015, 17:53:22

Zamiast siać defetyzm możesz w końcu napisać o konkretach? W jakim scenariuszu wątki w php mogą według Ciebie być przydatne? Masz w ogóle jakiekolwiek doświadczenie z programowaniem wielowątkowym, żeby zająć jakieś stanowisko w tej sprawie?

+1

Panowie o co tyle tej spiny? Używam wątków w php i jakoś nie robiło mi problemu dodanie dodatkowego modułu to tego, tak samo jak nie robi mi problemu dodanie modułu pdo który chyba powinien być obowiązkowy a jakoś nikt nie jaszczy z tego powodu, że trzeba go dodawać oddzielnie.

Mi się wydaje, że wątki mogą przydać się np. przy dużej ilości uruchamianych cronów (IMG:style_emoticons/default/smile.gif) Oczywiście niezwiązanych ze sobą. Takie skrypty zawsze coś mielą, wątki mogłyby to przyśpieszyć.

Żeby przyśpieszyć wątkami zadanie w tle musi ono spełniać jeden z dwóch warunków: czekać długo na swoje kolejne wyniki albo dać się łatwo zrównoleglić.
Rozpatrzy oba przypadki:

1. Na przykład tworzysz serię obrazków. Teoretycznie mógłbyś oddelegować do osobnych wątków kolejne wywołania graficznej biblioteki. Trzeba jednak zauważyć, że łatwiej jest dodać każdy obrazek jako osobne zadanie do kolejki. Na 99% OS lepiej podzieli wtedy pracę. Ten 1% wymaga dobrej znajomości programowania systemowego i w ogóle zakłada, że w tej części programu leży jakiś bottleneck. Drugi przykład to na przykład kolejne operacje pobierają dane z bazy, prowadzą proste obliczenia i pobierają kolejne. Coś jak podczas ajaxa na przeglądarce, albo i/o w node.js czy tornado. I tutaj zgadzam się, takie abstrakcje byłyby przydatne w PHP. Ale nie schodźmy do poziomu wątków. Po prostu zaimplementować interface w stylu Futures z Javy i dodać instrukcje synchronizacji (jak await w C#). Niech wątkami zajmie się interpreter oraz sterowniki tego i/o, bo i tak są pisane w niższych językach. Razem z odpowednim brokerem wiadomości (kolejki w db jak u Oraclea, pub/sub na Redisie, broker wiadomości w stylu RabbitMQ) rozwiązuje większość problemów ze współbieżnością, nie martwimy się o wątki, bo wystarczą lekkie greenthready w interpreterze. Tak robi Erlang i robi to cudownie.

2. Nawet jeśli mielibyśmy problem do zrównoleglenia (jakaś grafika, bo macierze się łatwo mnoży równolegle) to PHP ani inne języki skryptowe nie dają narzędzi do efektywnego zarządzania stosem i stertą. W językach skryptowych (prawie)wszystko jest przekazywane przez referencję i jest bardzo ciężkie, bez typu. Żadne współdzielenie pamięci nie wchodzi w grę a kopiowanie pamięci w każdą stronę zwolni tak naprawdę nasz skrypt. Czy można by dodać wsparcie dla współdzielenia pamięci do PHP? Można, ale będzie to niewyobrażalnie kosztowne. Każdy kto pisał coś z mpi wie jaka jest różnica między pisaniem w czystym C tam a używaniem czegokolwiek z nowych bibliotek standardowych (raii, smart pointery etc). Wystarczy sobie wyobrazić czego wymagałoby udostępnienie takich rzeczy z PHP jak dynamiczne typowanie i ciągłe przekładanie bloku pamięci, którego wymaga dynamiczne oop. A to jest message passing dopiero. Udostępnianie pamięci pomiędzy wątkami by wymagało jeszcze więcej. Wskaźniki w PHP nie są proste, są tagowane w specyficzny sposób, trzeba by to obejść, normalne PHP znowu by puchło.