Mnożenie dużych macierzy PHP poprzez FFI

Tak jak w tytule. Interesowal sie ktos juz tym rozszerzeniem?

@malencki - juz na wstepie phpnet zaznacza: Introduction ze:

Tip Currently, accessing FFI data structures is significantly (about 2 times) slower than accessing native PHP arrays and objects. Therefore, it makes no sense to use the FFI extension for speed; however, it may make sense to use it to reduce memory consumption.

Czy biorac pod uwage Twoje doswiaczenia z FFI, dla wymagajacych obliczen numerycznych (rachunek macierzowy) bardziej racjonalnym byloby skupienie sie mimo wszystko np na PHP-CPP w odniesieniu do tworzenia i uzywania custom'owych rozwiazan? Mam na mysli przede wszystkim "wpiecie" sie w GPU (CUDA).

Jak wszystko będzie działo się w libie, a komunikacja będzie zdawkowa, to jak najbardziej FFI.

Podajesz bardzo mało informacji co chcesz zrobić.
Rozwiązanie dobiera się do konkretnych wymagań, a nie na odwrót.

malencki napisał(a):

...
Podajesz bardzo mało informacji co chcesz zrobić.
...

proximus-prime napisał(a):

...
... dla wymagajacych obliczen numerycznych (rachunek macierzowy) ...
...

@malencki: sorry, faktycznie powinienem byl wspomniec, ze chodzi o np mnozenie macierzy, ktorych rozmiary sa zasadniczo "ciut" wieksze niz 2x2 :D

Czyli, jeśli dobrze Cię rozumiem, chcesz wysyłać do libki z pozycji pehapa macierz 2x2 i potem ją odbierać?
Nie ma to najmniejszego sensu dla FFI.

Przy takich rozmiarach, może się okazać że czysty php (nawet bez natywnego cpp), będzie szybszy.
Najlepiej przetestować.

malencki napisał(a):

Czyli, jeśli dobrze Cię rozumiem, chcesz wysyłać do libki z pozycji pehapa macierz 2x2 i potem ją odbierać?
...

Nic nie rozumiesz, ale oszczedze Ci pisania duzymi literami :D .

Nie interesowałem się tym FFI, nie potrzebowałem nigdy w PHPie robić takich rzeczy. Może określ wielkość tych macierzy i ilość tych obliczeń może dzięki temu inni będą w stanie doradzić coś więcej. Bo tak nie do końca wiadomo czy masz probelm z ilością pamięć, czy czasem wykonania. Pamiętam jeden taki superdurszlak kiedyś robił porównanie mnożenia macierzy w różny sposób i pokazywał jak napisany kod wpływa na czas wykonania. Kluczowym aspektem był o ile pamiętam dobór działań matematycznych tak by nie wchodzić do RAM a działać w oparciu o cache Procka. Wiadomo tego pewnie nawet z JIT nie osiągniesz w PHP.
Tylko najważniejsze nie z armatą na muchę. Opowiedz coś więcej o tych macierzach, ile tych obliczeń, gdzie masz wąskie gardło itd. Bo jak masz robić żeby robić to YAGNI i KISS

@jurek1980: jesli chodzi o rozmiar macierzy to spore (sieci/predykcja) conajmniej jakies 10000 x 10000 czyli w sumie pamiec ale dla sieci odpalanej w automatycznie modyfikowanych ustawieniach - tutaj to juz "mnogosc ogromna" wiec i predkosc. Zarowno FFI jak i tradycyjnie napisane rozszerzenia (C) lub PHP-CPP (C++) daja mi mozliwosc wpiecia sie w GPU (CUDA), ale tak jak napisalem wczesniej w odniesieniu do FFI moj zapal ostudzila notka na temat tablic.

Natywnie php pojedyncza inwersje takiej macierzy bedzie mulic "tydzien czasu" - oczywiscie przesadzam, niemniej jednak troche czasu zejdzie, ale biorac pod uwage ze odpalenie pojedynczych ustawien to moze byc czasem jakies 1000 epok - masakra.

Jesli prawda jest to co pisza w sieci, spiecie php z GPU za pomoca odpowiednio napisanego rozszerzenia umozliwia nawet 1000 wieksza predkosc obliczen. Standardowe rozszerzenie (CPU) w C, pod warunkiem ze jest napisane poprawnie moze przyspieszyc obliczenia od 20 do 30 razy wiec jest powod zeby probowac.

Skoro to sieci, AI i predykcja to korzystasz już z jakichś bibliotek od tego czy piszesz od zera? Skądś te dane bierzesz, odczytujesz z jakiejś bazy nie wiem. Bo to co opisujesz to raczej powinno być napisane w jakimś innym języku a PHPa to bym użył do wyświetlania ładnej tabelki w HTMLu z wynikiem.

@jurek1980 pisze od zera i zrobilem to juz w php, python'ie i java'ie. I wiesz co? W zadnym innym jezyku nie pisze sie tak fajnie jak w php. Poza tym rozszerzenie (C++) jest mi wlasciwie potrzebne jedynie od do rachunku macierzowego, a cala reszta (automatyzacja ustawien przygotowywana na biezaco, trigger sieci) moze byc robiona w czystym php.
Idea jest taka zeby przygotowac aplikacje sieciowa z przyjemnym interfejsem, ktora bedzie mogl odpalic sobie srednio ogarniety inzynier/trader/etc bez calej tej pythonowej otoczki dostepnej dla fanow jupiter'a. Jesli cala magie moge zrealizowac za pomoca php-owego rozszerzenia w C++ i osiagac nieosiagalne np dla bibliotek pythonowych rezultaty to taki powod mi w zupelnosci wystarcza.

Jesteś zdecydowany na PHP OK !
to pozostaje "przepchnąć" dane bliżej GPU/CPU policzyć a potem "powrót" danych do PHP.
Zrobisz parę prostych testów i będziesz wiedział na czym stoisz.

Ponieważ ciekawy temat a ja nie robiłem takich cudów, na szybko zerknąłem w gugiel i widzę, że tam nawet Rusta można podpiąć.
https://spiralscout.com/blog/how-to-use-php-ffi-in-programming
Może nie musisz przekazywać tych danych przez natywne tablice PHPowe. Może jakieś JSONy bezpośrednio pobrane z tego API, czy inne tego typu rzeczy, Nie pozostaje nic innego jak spróbować.

@jurek1980 - prawda jest taka, ze im bardziej wchodzisz w temat, tymbardziej czujesz sie jak dzieciak w sklepie z zabawkami, z jedna jakowoz opcja na ktora musisz sie ostatecznie zdecydowac. Mnie po dlugim czasie zastanawiania sie ciagnie jednak do C++, ktory chwilowo (poza header'ami i masakrycznym podejsciem do dynamicznych tablic wielowymiarowych) bardzo mi podchodzi. Poza tym jest tu na forum bardzo zyczliwy @Adamek Adam ktory natychmiast mnie nie sponiewieral i wrecz przeciwnie pomogl mi niedawno.

@Adamek Adam: dzisiaj sobie wklepuje w C++ algebre macierzy i faktycznie mam nadzieje w najblizszym czasie przekonac sie jak te predkosci wygladaja.

Już trochę więcej wiadomo na temat tego co chcesz zrobić.

Może okaże się to dla Ciebie pomocne.
Gdybym to robił i musiał z jakiegoś powodu użyć PHP to:

1. Utworzyłbym daemona / service do obliczeń (algorytmy) - C++.
2. Do połączenia daemona z PHP zastosowałbym którąś z komunikacji miedzyprocesowej (IPC), w celu wysyłania i odbierania danych.

Czyli proces mógłby wyglądać mniej więcej tak (od strony PHP):

1. Pobieranie danych z serwisów.
2. Przetwarzanie przez PHP (potrzebne?)
3. Wysłanie do usługi przetworzonych danych
4. Pobranie z usługi obliczonych danych
5. Przetworzenie przez PHP (zapis w bazie?)

Od strony daemona w CUDA możesz utworzyć sobie strumień i pakować dane do pamięci karty graficznej - bezpośrednio.
(Może da się bezpośrednio z PHP ładować do pamięci karty graficznej? Tego nie wiem, możesz zawsze poszukać).

W przypadku strumienia na pewno wyjdzie mniej pamięciożerne.
Wyjdzie bardziej logiczne i bardziej prosto niż bawienie się w tworzenie i odpalanie modułów lub wywoływanie FFI (oraz pakowanie/wysyłanie/odbieranie danych do/z tych libów / modułów).
Wydaje się również, że będzie wydajniejsze (ale to zależy od tego jak dużo będzie robione w PHP).

Wtedy wychodzi Ci:

1. Apka w PHP do pobierania danych
2. Apka do prezentowania (?) danych z bazy lub pamięci (jakiegoś memcache)
3. Daemon do obliczeń.

@malencki: dziekuje Ci bardzo, zawziales sie (w jak najbardziej pozytwynym tego slowa znaczeniu) doceniam to.

Utworzyłbym daemona / service do obliczeń (algorytmy) - C++.

Dokladnie tak to sobie wyobrazalem, jednak myslalem o daemonie napisanym w php wykorzystujacym rozszerzenia ktore zamierzam napisac C++. Z prostej przyczyny, w ogole nie mialem do tej pory do czynienia z C++ i wystarczy mi ze rozszerzenia beda odpowiedzialny wylacznie za core'owa "mlucke" danych na gpu.

Do połączenia daemona z PHP zastosowałbym którąś z komunikacji miedzyprocesowej (IPC), w celu wysyłania i odbierania danych.

Tutaj zupelnie nie wiem "o czym Ty do mnie rozmawiasz", za cienki jestem chwilowo na ten poziom zagadnien, zatem na tym etapie kolejny powod do tego zeby sobie odpalac prosta php'owa konsole z custom'owymi rozszerzeniami.

Czyli proces mógłby wyglądać mniej więcej tak (od strony PHP):

1. Pobieranie danych z serwisów.

Jak najbardziej, natomiast bez koniecznosci ich przechowywania. Mozna dopuscic taka mozliwosc natomiast nie jest to specjalnie konieczne.

1. Przetwarzanie przez PHP (potrzebne?)

Oczywiscie jak najbardziej.

1. Wysłanie do usługi przetworzonych danych

Oczywiscie, wsad i aktualna konfiguracja sieci

1. Pobranie z usługi obliczonych danych

Wlasciwie wylacznie raportow o bledach dla poszczegolnych ustawien dla treningu | testu | prognozy

1. Przetworzenie przez PHP (zapis w bazie?)

wylacznie informacja o zrodle + zakresie danych + oraz jednej najlepszej lub zestawie najlepszych konfiguracji konfiguracji

Od strony daemona w CUDA możesz utworzyć sobie strumień i pakować dane do pamięci karty graficznej - bezpośrednio.
(Może da się bezpośrednio z PHP ładować do pamięci karty graficznej? Tego nie wiem, możesz zawsze poszukać).

W przypadku strumienia na pewno wyjdzie mniej pamięciożerne.

To jeszcze nie ten moment dla mnie, jak sie przez kilka lat klepie wylacznie endpointy do e-commersow to niestety takie braki wychodza.

Apka w PHP do pobierania danych
Apka do prezentowania (?) danych z bazy lub pamięci (jakiegoś memcache)
Daemon do obliczeń.

Dookladnie :D

proximus-prime napisał(a):

@malencki: dziekuje Ci bardzo, zawziales sie (w jak najbardziej pozytwynym tego slowa znaczeniu) doceniam to.

Zwyczajnie czekałem na dostateczną ilość informacji :D

W takim wypadku, bez znaczenia czego użyjesz. Prościej będzie "nativem".
Widzę to tak:

1. Tworzysz pętle w wątku, która odbiera dane i pakuje do karty(c++)
2. Przekazujesz strumień (poczytaj) (c++ -> PHP)
3. Pakujesz dane do strumienia (w PHP), które lecą do wątku.(PHP -> c++)

Z libem (FFI) dochodzi dodatkowy, niepotrzebny poziom.

malencki napisał(a):

Jak wszystko będzie działo się w libie, a komunikacja będzie zdawkowa, to jak najbardziej FFI.

Podajesz bardzo mało informacji co chcesz zrobić.
Rozwiązanie dobiera się do konkretnych wymagań, a nie na odwrót.

Dokładnie.

Ja sobie wyobrażam rzeczy intensywnie numeryczne jako pętle

Zbudowanie struktury danych
for(;;)
{
obliczenie (10000x10000)
malutkie uszczkniecie wiedzy o wyniku, np postawienie kropki na wykresie
dane pozostają w RAM /cache /GPU
}
free

tymczasem w webie
początek requestu
zbudowanie struktury danych 10000x10000 (strach mysleć)
obliczenie 10000x10000
koniec requestu

Na intuicję numeryka w tym zagadnieniu to tylko jakiś niewielki ułamek całości przepalonego prądu

Dodajmy że na realnym serwerze webowym GPU albo nie ma, albo są tryby chronione które blokują dostęp...

proximus-prime napisał(a):

... za pomoca php-owego rozszerzenia w C++ i osiagac nieosiagalne np dla bibliotek pythonowych rezultaty to taki powod mi w zupelnosci wystarcza.

A jakie rzeczy są nieosiagalnie za pomocą pythona + rozszerzenia ?
Integracja Pythona z C (a przez wrappery z C++) jest perfekcyjne udokumentowana, z góry przewidziana do rozszerzeń, debugowania, bez jakiejś hackerki *), wytestowana przez ogromny rynek zastosowań. Binarne API pythona przeszło (a i to ograniczoną) zmianę 2->3, jest stabilne do bólu.

*) piję, aczkolwiek nie tylko, do kompilowania jakiś szemranych projektów HGW w jakiej wersji samej w sobie i do jakiego PHP, i błędów kompilacji

@ZrobieDobrze

Dodajmy że na realnym serwerze webowym GPU albo nie ma, albo są tryby chronione które blokują dostęp...

Nigdzie nie wspominalem ze mam zamiar korzystac z dostepnych Tobie realnych serwerow webowych

A jakie rzeczy są nieosiagalnie za pomocą pythona + rozszerzenia ?

Nie wiem i nie interesuje mnie to. Interesuje mnie fakt, ze nie mozna tego zrobic w php'ie, a raczej ze jeszcze nikt nie zrealizowal w php'ie interesujacych mnie rozwiazan.

ntegracja Pythona z C (a przez wrappery z C++) jest perfekcyjne udokumentowana, z góry przewidziana do rozszerzeń, debugowania, bez jakiejś hackerki *)

I co z tego? Nie umniejszajac wartosci/jakosc rozwiazaniom w innych jezykach i wbrew powszechnosci opini o bezsensownosci prob wymyslania kola od nowa ja chce to zrobic w sposob jak najbardziej jednorodny, w php. Dlatego ze to mozliwe, dlatego ze niewielu proboje, dlatego ze to jest dla mnie wyzwaniem, dlatego ze mam z tego powodu satysfakcje, dlatego ze robie to dla siebie, dlatego ze ewentualne bledy nie okaza sie dla mnie katastrofa, dlatego ze przy okazji duzo sie naucze - moglbym tak jeszcze bardzo dlugo.

*) piję, aczkolwiek nie tylko, do kompilowania jakiś szemranych projektów HGW w jakiej wersji samej w sobie i do jakiego PHP, i błędów kompilacji

Kazdy kawalek kodu, biblioteka, rozwiazanie, framework etc zawsze byl w pewnym momencie swojego life cycle'u jak to okresliles kompilowanym, szemranym HGW projektem (i to nie tylko PHP'owym) ktore spotykaly sie z negatywna ocena/krytyka podobnych do CIebie RobiacychDobrze recenzentow, Po jakims czasie Ci sami recenzenci nie wyobrazaja sobie bez nich zycia broniac/popularyzujac je zaciekle wylewajac pomyje na kolejne rozwiazania.

Tak na koniec. Ludzie siadaja do kodu z roznych powodow, nie wszystkich przymusza do tego wzieta pod kreske rata kredytu.

@proximus-prime:

Zalezy. czy chcesz być pionierem i wypinać klatę na ordery, czy bardziej prozaicznie ale sprawnie uzyskać działający wynik. Każdy w pewnych okolicznościach bywa wybierany jako cel.

Bo zmieniasz objaśnienia o motywacji jak chorągiewka

@ZrobieDobrze:

Zalezy. czy chcesz być pionierem i wypinać klatę na ordery, czy bardziej prozaicznie ale sprawnie uzyskać działający wynik.

Ani ordery ani wynik, czytaj czlowieku ze zrozumieniem - bo akurat o swojej motywacji napisalem calkiem sporo.

Bo zmieniasz objaśnienia o motywacji jak chorągiewka.

Moge tylko powtorzyc to co napisalem wczesniej - patrz wyzej.

Każdy w pewnych okolicznościach bywa wybierany jako cel.

Nie kazdy i nie z powodu okolicznosci. Problemem jest zawsze niska samoocena i wynikajaca z niej frustracja osoby ktora "celuje".
Dobra wola, chec wsparcia i zmotywowania interlokutora przejawia sie zasadniczo w inny sposob.