Jak szybki/wolny jest PHP

[Maximus Marius]

Taka ciekawostka ale zawsze lepiej wiedzieć niż nie wiedzieć

Porównanie tych samych algorytmów tylko w różnych językach programowania

https://shootout.alioth.debian.org/u32q/ben...ot〈=all

[Trotyl]

Niedawno gdzieś czytałem że różnica szybkości c++ i php to kilka rzędów, a tu tylko 10²,10³ :|

[perplexus]

pamiętajmy, że:

testowany c++ to już wynikowy(g++) kod maszynowy

php to skrypt, który jest parsowany i dopiero później wykonywany przez apache

[Maximus Marius]

Wszystko sie zgadza tylko że to co obrabia w obu przypadkach procesor zawsze jest kodem maszynowym czy to jest C++ czy to jest PHP

Zakładam że czas parsowania i czas tworzenia kodu binarnego odzwierciedlającego zadanie sa pomijalne.

coś co w C++ jest jedną instrukcją ASM w PHP jest paczką 200 instrukcji

hmmmmmmm w sumie to taka tam ciekawostka, nie żebym przestał używać PHP tylko nie sądziłem że narzuty PHP sa aż takie

[papieros]

Zakładam że czas parsowania i czas tworzenia kodu binarnego odzwierciedlającego zadanie sa pomijalne.

Oj, ryzykowne założenie - przy dobrych parserach, to wlasnie jest to co najbardziej spowalnia, bo co innego mogloby spowolnic - kod parsowany mozesz sobie wyobrazic jak kompilowany online, nieprawdaż? - po sparsowaniu nie powinno byc juz żadnych różnic (przy dobrych parserach, oczywiscie.

Ciekawe by było obejrzenie kodu tych programów, bo założe się, że można by było jeszcze nieżle zoptymalizować każdy kod (pod konkretny język)

[relons]

Dlatego warto używać eAcceleratora lub Xcache na własnym serwerze (żeby pominąć konieczność każdorazowego parsowania kodu).

[papieros]

relons, a masz jakies porównania/benchmarki/testy/inne dotyczące skuteczności eAcceleratorów?

[Inco]

Ciekawe by było obejrzenie kodu tych programów, bo założe się, że można by było jeszcze nieżle zoptymalizować każdy kod (pod konkretny język)

Na tej stronie możesz je obejrzeć.

Jeśli chodzi o eAcceleratora to on tu wiele nie pomoże bo zmienia skrypt do kodu pośredniego, czyli czegoś takiego jak kod bayt kod w javie. Jednak nadal jest to język skryptowy, który jest interpretowany na bieżąco, a wymusza to już samo założenie języka.

[relons]

Nie mam, ale wydajnościowo Xcahce i eAccelerator są podobne. Jeżeli chodzi o przyspieszenie w stosunku do samego PHP to czas generowania strony jest średnio od 5 do 10 razy krótszy. Jeżeli masz możliwość instalacji to naprawdę warto, bo można tylko zyskać.

E: @Inco racja, ale tego już nie przeskoczysz bez zmiany języka. A tak instalując eAccelerator zerowym kosztem (kilka MB na cache w pamięci RAM wypadałoby przeznaczyć, najczęściej 8MB dla kilku skryptów wystarczy) masz niezłego kopa wydajnościowego.

[slawek22]

Niedawno gdzieś czytałem że różnica szybkości c++ i php to kilka rzędów, a tu tylko 102,103 :|

Większość wiedzy dostępnej o PHP na popularnych portalach to bzdury i pobożne życzenia. Te kilka rzędów to takie same bzdury jak optymalizacja przez zmianę rodzaju komentarzy czy przeniesienie count(..) poza pętlę. Po prostu gdyby przeciętnemu użytkownikowi przeciętnego portalu napisać o przepisaniu części kodu w bardziej wydajnym języku czy optymalizacji algorytmu to nic by z tego nie zrozumiał. Takie optymalizacje w 5 minut są lekkie proste i przyjemne, mają tylko jedną wadę - że nic nie dają.

Jeśli chodzi o eAcceleratora to on tu wiele nie pomoże bo zmienia skrypt do kodu pośredniego, czyli czegoś takiego jak kod bayt kod w javie.

Przy fraktalu fakt nie pomoże bo to jedna duża pętla, mało kodu i jakieś 5 ms, które można zaoszczędzić na kompilacji. Jednak przy "normalnych" skryptach szybkość wykonywania może się zwiększyć nawet 10-20X. Co do xcache i eaccelerator to są kiepskie. Zmieniają działanie interpretera, tzn. musisz mieć wszystkie klasy i funkcje zadeklarowane przed użyciem. Dlatego skrypty się wysypują, z APC nie ma tego problemu.

[Inco]

Ja pisałem o tym konkretnym przypadku, a nie że nie opłaca się w ogóle instalować xcache i eaccelerator. Ten test pokazuje że do konkretnych zadań, trzeba używać odpowiednich narzędzi, liczenie fraktala w PHP to nie jest dobry pomysł.