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.

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



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...!

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.

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 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.

Ech, Boże, Boże i Bożenko... Równie dobrze możesz mnie zapytać o to jakie scenariusze widzę dla użycia interfejsów - jeśli wiesz do czego służą ani kiedy ich używać to kup sobie książkę albo skorzystaj z Googli.

A i mała uwaga - w gronie ludzi z branży IT nie przyznawaj się do tego, bo się skompromitujesz.

A jeśli ktoś naprawdę nie wie jak wykorzystać wielowątkowość w skryptowych językach, to polecam analizę tego tematu w Pythonie lub Ruby'im - tam przynajmniej jest to wspierane w standardowych bibliotekach i używane (w przeciwieństwie do PHP).

PS Jeśli ktoś jest zielony z tego tematu, wtedy radzę także się tutaj nie odzywać - bo niestety wykazać można się tylko swoją ułomnością. ; )

Sorry, ale w takim razie po kiego w ogóle taki wątek na forum, skoro ktoś z mniejszą wiedzą nie może pytać kogoś z większą ?

Patrz - http://forum.php.pl/index.php?s=&showt...t&p=1155578 - dużo tekstu w temacie (w przeciwieństwie do Twoich postów), odnieś się rzeczowo skoro potrafisz. Nauczymy się czegoś wszyscy.

A teraz do wszystkich, może skoro wszyscy wspominają o rubym i railsach (mam większe doświadczenie niż z django/python), przejrzymy repo railsów, żeby zobaczyć gdzie wątki i z jakimi skutkami są używane? Będzie zabawa.

Ciężko dyskutować o wątkach jak pewnie wiekszość uczestników dyskusji niewiele miało z nimi styczności i nie zna ich potencjału oraz zagrożeń.

A więc po co wątki w pehapie?

Przykład A:
Połączenia do bazy danych, baza to zasób, możemy mieć np: limit na poziomie 20 transakcji na sekunde, albo np: 100 połączeń. W standardowych Pehapie, Janusz na klepie kod a później dupa sie pali bo produkcje wy*ebało jak użytkowników zbyt dużo... W aplikacji wielowątkowej np: w Javie czy nawet Pajtonie, można zrobic tzw: pule połączeń sterowaną osobnym wątkiem, która przyznaje dostep do zasoby bazy danych tak aby skolejkować transakcje i nie przeciążyć zasobu. Dzięki temu wprowadzamy asynchroniczność i część requestów czeka na dostęp do bazy czy innego zasobu. Ale przecież można użyć kolejki - powiedziałby bardziej ogarnięty Jasnusz, ano można ale wątki są dużo dużo szybsze.

Przykład B:
Mamy aplikacje z dziedziny e-marketingu, która obsługuje tysiące hitów np: z reklam czy z gier, itp. Im bliżej czasu rzeczywisteg otym lepiej. Przykładowo takie triwium jak licznik odwiedzin strony. Standardowy Janusz naklepałby to w gołym Pehapie z dodatkiem SQL. Spoko, można ale znow troche zbyt wzrosnie obciażenie i dupa blada, licznik wyjebało. Janusz stwierdzi, no ch*j użyje redisa, ok znowu można ale to zewnetrzna usługa więc mamy (spory) narzut na czas połączeń bo nie mamy puli (pacz wyżej), może wymysli cassandre ale znowu tu czas będzie jeszcze większy. Z wątkami, można zrobic listy, liczniki, drzewa, hashe sterowane z poziomu jednego wątka, gdzie informacje dodaje się za pomocą np: wewnętrznej kolejki lub synchroniizacji między wątkami, takie liczniki mogą działać z wydajnością setek tysięcy hitów na sekunde, dodatkowo wątek może zrzucać dane co np: 10s sekwencyjnie a nie randomowo, w pajtonie to doslownie kilka linijek kodu (multiprocessing + queue).

Przykład C:
Jest sobie apka, która ma jak najszybciej zwrócić wyniki np: wyszukiwania na stronie, np: limit 300ms. Teraz apka musi odpytać wiele mechanizmów o to czy wiedzą coś o danej kwerendzie. Pehapowy Janusz, jebnie pętelke i z uśmiechem na mordzie wrzuci to na proda. Znów ruch wzrośnie i dupa. Dodatkowo serwer będzie dymił bo pehap będzie robił "puste przebiegi" oczekiując na dane z zaalokowanymi zasobami (ram, itp). Z wątkami, można rozdzielić ruch na kilka wątków i o ile zasoby pozwalają (ram, sockety) zrównoleglić odpytywanie usług w obrębie jednego requestów.

Przykładów pewnie będzie sporo więcej, chociaż by programowanie eventowe doskonale działa na wątkach.

// Edit
Czy jest sens wrzucania wątków do Pehapa?
Imho nie, na rynku są dużo bardziej dojrzałe rozwiązania posiadające wsparcie dla wielowątkowości od samego początku.

W wypadku connection pooli i tak najlepiej je implementować na poziomie drivera gdzie masz większą kontrolę nad pamięcią. Dostęp do wątku (to się tyczy przykładu drugiego też) nie jest taki prosty. PHP jako taki nie definiuje w jakim środowisku jest uruchomione i nie jest proste ustalenie sposobu komunikacji z innym wątkiem, jeśli to nie my go stworzyliśmy w skrypcie. A tak przecież nie jest w pierwszym i drugim przykładzie (choć można poczynić dalsze założenia co do uruchamiania jako mod_php, używania tylko rozszerzeń, które są thread safe etc.). Takie rzeczy działają w Javie bez problemu bo częściowo się też pisze serwer tudzież frameworki mogą poczynić większe założenia co do serwera - i mamy te wszystkie beany, które żyją w kontenerze i trzymają dane dla wielu wątków i w obsłudze requestu mamy do nich dostęp. Można by tak samo zmienić PHP, ale ile to roboty i nieodwracalnych zmian. Dochodzą też problemy skalowania - każdy kto dotykał rozproszonych ejb wie, że siedzą tam problemy przy wielu serwerach.

Trzeci przykład moim zdaniem lepiej śmiga jak całe "programowanie eventowe" na zielonych a nie natywnych wątkach. Dopóki klientów jest więcej niż coreów na serwerze dopóty natywne wątki nie będą potrzebne, wystarczy nieblokujące i/o. Oczywiście via zielone wątki. Tak jak mówisz, procesor będzie mielił tylko to co jest do mielenia a nie tylko czekał na komunikację. W Erlangu, żeby było trudniej, taki greenthread bez współdzielonej pamięci to proces (nie to samo co systemowy proces). Tam w takiej sytuacji spawnuje się procesy komunikacji a główny proces czeka na powroty z nich. Scheduler przejdzie na inny proces dopóki nie dostanie czegoś na netslocie. Wszystko na jednym corze.