Néhány hónapja írtam egy nagyobb lélegzetű parancssori PHP programot, amely órákig fut. Nemrégiben rákerestem, át lehet-e konvertálni PHP programokat C/C++-ba. A php2cpp projekt halottnak tűnik, de van egy BinaryPHP is, aminek a csv változata egész használható. A program szerzője még mysql utasításokat is megfeleltetett C++ kódrészleteknek. Maga az ötlet zseniálisnak tűnik számomra, ahogy "mindenízű változó" típusaként létrehozza a php_var* típust. És tanulságos lehet pl. egy explode megvalósítás C++ban (lásd a functions alkönytárban; http://binaryphp.cvs.sourceforge.net/viewvc/binaryphp/?view=tar )
Pl egy tömb 4 elemének (1,2,3,4) a megszámlálásából (count) keletkezett ez:
http://pastebin.com/RkCptrLw
Ez már szépen lefordul. Bonyolultabb programok még elhasalnak.
A tuti megoldás, amivel a FaceBook PHP hátterét is optimalizálták, ez: https://github.com/facebook/hiphop-php/wiki/Running-HipHop - http://developers.facebook.com/blog/post/358 ; a hip-hop azonban csak 64 biten fut.
A 32 bitesről 64 bites oprendszerre való átállás már önmagában is tetemes előnnyel járt (a futásidő a kétharmadára csökkent; bár ebben néhány egyéb optimalizálás és adatcsökkenés is érvényesül).
- 4294 megtekintés
Hozzászólások
Biztos, hogy a php lassusaga miatt tart ilyen sokat, es nem pl. a db lekerdezesek miat..?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
Nem használok adatbázist - előre leválogatom szövegfájlokba az adatokat. String-illesztések serege zajlik ennyi ideig (az eredeti PHP programban; nem abban, amiből a fenti részlet lett).
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben inkabb az algoritmust nezd at! A stringkezeles PHP-ben viszonylag jol meg van oldva, C++-szal nem nyersz sokat, max. a modosithatosag csokken (scriptnyelvbol generalt C++ kodot lass at :) ).
--
Tudod te, mennyi lóvé fér egy Alstom-kocsi dobozába? :)) - laspalmas, VB
- A hozzászóláshoz be kell jelentkezni
+1
Szinte kizártnak tartom, hogy maga a PHP a hibás. Tervezésbeli vagy megvalósításbeli probléma lesz ott, esetleg külső tényező. Amennyiben high-end alkalmazásokat fejlesztesz és PHP guru vagy, természetesen a hozzászólásom nem érvényes :)
- A hozzászóláshoz be kell jelentkezni
Nem "hibás" a PHP, csak egyszerűen irdatlanul sok adat van. Gyorsabb lenne a C++ minden bizonnyal.
- A hozzászóláshoz be kell jelentkezni
Ha sok és nagy tömböt használsz, akkor ez lehet oka a lassúságnak. Nézd meg az SPL adatszerkezeteket, hátha segítenek. Mindenképpen futtass valami profilingot rá, mert ami PHP-ban lassú, az nem lesz nagyságrendekkel gyorsabb C-ben sem, max egész számú szorzóval. Ezzel szemben sokkal több meló karban tartani.
- A hozzászóláshoz be kell jelentkezni
Sokat tanultam az SPL adatszerkezetek tanulmányozásával, de sajnos nem gyorsított a használatuk. Köszi mindenesetre - legközelebbi programjaimban már ezekre is tudok építeni.
- A hozzászóláshoz be kell jelentkezni
Ez esetben lehet jobban jarnal, ha tarolt eljarast irnal, es hagynad hogy a DB futtassa, ne a webszerver. Szinte minden sql szerver termek tamogat meg regexpet is, es mar akar mysql-ben is vannak kurzorok :-)
A te szovegfajlod tuti nincs indexelve, se ugy bufferelve, hogy optimalisan kihasznald azt.
Bar jo lenne tobb info arrol, hogy mi a bemenet es mi a kivant eredmeny.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
> "String-illesztések serege zajlik"
Lehet, hogy valami holisztikusabb megoldás kellene egyesével illesztett stringek helyett.
- A hozzászóláshoz be kell jelentkezni
HipHop és kész? :)
https://github.com/facebook/hiphop-php/wiki/Running-HipHop
- A hozzászóláshoz be kell jelentkezni
Mégiscsak ez lett a jövő útja... pedig eleinte riasztónak tűnt. :-) Köszönet a linkért.
Ez is annyira szívhezszóló (s minden lépése működőképes): https://github.com/facebook/hiphop-php/wiki/Building-and-Installing-on-…
Igazából csak 64 bites rendszeren sikerült beüzemelni, 32 bitesen nem.
- A hozzászóláshoz be kell jelentkezni
a 459. sor utan van egy beagyazott for ciklus is, a key/2-es ciklusban.
Illetve azért, mert az asssociatív tömbnél is van int indexelés, tehát [0], [alma] és [1], [béla] páronként ugyanaz, remélem nem kell teljes kódot írnom példának. Ekkor ha végigpörögsz minden elemen, akkor 2x dolgoznál fel mindent.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Köszi! :-)
- A hozzászóláshoz be kell jelentkezni
Mielőtt bármit gépi kódra kezdesz konvertálni, szerintem vedd elő az xdebugot és generáltass vele cachegrind fájlt, majd elemezd ki. Olyan bakikra derülhet fény, amik miatt szükségtelen lesz az egész móka.
- A hozzászóláshoz be kell jelentkezni
Subscrible.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a tanácsaitokat, megfontolom őket, és visszajelzek pár héten belül (most szabadságon vagyok). A fenti példa fejlesztői változata lefordult gépi kódra. :-)
- A hozzászóláshoz be kell jelentkezni
Szinte biztos, hogy az algoritmusnak van 1-2 "központi" része, ami a sok al-al-al-cikluson belül fut. Ezt vagy ezeket érdemes lehet C-ben megírt PHP modulként használni. Nem nagy ördöngösség egyébként, simán lehet függvényneveket deklarálni a C kódban, amit aztán PHP-ben függvényként meg tudsz hívni.
- A hozzászóláshoz be kell jelentkezni
Köszi! Igen, erről már itt is kérdezősködtem, s Kübi sikerrel meg is oldotta a dolgot SWIG-gel: http://hup.hu/node/99598 - ebben a konkrét esetben azonban olyan sok nagy tömbhöz kell kinyúlkálni a belső ciklusmagból, hogy nem volt bátorságom modult írni hozzá.
- A hozzászóláshoz be kell jelentkezni