Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Najszybszy w działaniu język programowania
Forum PHP.pl > Inne > Hydepark
Stron: 1, 2
S_Olewniczak
Czy może ktoś wie jaki jest najszybszy w działaniu język programowania po stronie serwera na potrzeby web? Bo zastanawiam się na naukę nowego języka po PHP i byłoby to mi bardzo przydatne.
dr_bonzo
Assembler/C
Jakie pytanie taka odpowiedz.
S_Olewniczak
A czy ktoś używa tych języków do programowania web?
Spawnm
raczej nie.
do www najszybszy jest php.
a jak chcesz się uczyć nowego języka to zainteresuj się c++ lub java , te języki mają spore możliwości.
.radex
Cytat(Spawnm @ 3.04.2009, 20:22:26 ) *
do www najszybszy jest php.


Z ciekawości: skąd taka informacja? Masz gdzieś jakieś wykresy, porównania?
kwiateusz
jak nie ostatnio gdzieś widziałem framework do pisania aplikacji www w c++ smile.gif

co do szybkości to sądze ze python lub perł by php przescignęły smile.gif zwłaszcza że python jest prekompilowany z tego co pamiętam
tiraeth
Szybkość działania aplikacji zależy od programisty a nie od języka. Jak napiszesz - tak zadziała. Czasem jedno rozwiązanie może być szybsze w PHP, inne w Pythonie.
Spawnm
Cytat(.radex @ 3.04.2009, 20:25:54 ) *
Z ciekawości: skąd taka informacja? Masz gdzieś jakieś wykresy, porównania?

z 2 lata temu na coś takiego natrafiłem , nie jestem w stanie ci teraz udowodnić/pokazać ...
Jednak jeśli znasz szybszy język do www to pisz winksmiley.jpg
Choć jak napisał tiraeth nie język a ten co w nim pisze decyduje o jego szybkości .
Jabol
Żaden język nie jest szybki. To dość głupio zadane pytanie. To tak jakby zapytać: najszybszy w jeżdżeniu producent samochodów? Język nie ma nic wspólnego z szybkością wykonywania napisanych w nim programów. Tyle.
S_Olewniczak
Jednak mi się zdaje że języki kompilowane są ogólnie szybsze. Może się mylę?
Speedy
Cytat(S_Olewniczak @ 3.04.2009, 20:37:33 ) *
Jednak mi się zdaje że języki kompilowane są ogólnie szybsze. Może się mylę?

To logiczne. Kompilujesz raz i masz. Nie musisz tego parsować za każdym razem.
AxZx
wczoraj m$ wypuścił info o powstaniu nowego frameworka wykorzystującego architekturę MVC (nie wiem jaki to dokładnie napisali;).
dlatego może zainteresujesz się ASP.NET ?
S_Olewniczak
Produkty m$ NIGDY
phpion
Cytat(S_Olewniczak @ 3.04.2009, 21:32:42 ) *
Produkty m$ NIGDY

Ponieważ? Kolejny młody gniewny... Ja bym na twoim miejscu rozważył jednak ASP.NET. Nigdy nie miałem z tym styczności, składnia do mnie nie przemawia jednak podobno jest to całkiem niezłe narzędzie.
mike
Cytat(S_Olewniczak @ 3.04.2009, 19:33:20 ) *
Bo zastanawiam się na naukę nowego języka po PHP (...)
Najpierw się PHP naucz.
AxZx
Cytat(phpion @ 3.04.2009, 21:34:41 ) *
Ponieważ? Kolejny młody gniewny... Ja bym na twoim miejscu rozważył jednak ASP.NET. Nigdy nie miałem z tym styczności, składnia do mnie nie przemawia jednak podobno jest to całkiem niezłe narzędzie.


tym bardziej, że możesz korzystać z C#.

jedna zaleta/przewaga nad PHP. nie korzystają z tego dzieci neo - nie psują rynku:) programiści całkiem dobrze zarabiają, może dlatego, że ich jest stosunkowo mało.
erix
Cytat
m$ NIGDY

Jak się ich nie zna, to się tak mówi. A taka prawda, że nieraz produkty MS-a są bardzo dobrze dopracowane, zwłaszcza dokumentacja. Wszystko można w niej znaleźć nawet, jak nie bardzo wiadomo, czego szukać. winksmiley.jpg

Najbardziej zaskakuje mnie jednak tempo rozwoju .net; w Polsce tego nie widać, bo mało popularne są u nas hostingi z Windows, ale na Zachodzie asp nikogo nie dziwi.

A wracając do tematu - teoretycznie można by było napisać jakiś PECL w C zawierający całą logikę strony i na tym śmigać. ;] Wtedy byłby i PHP, i na pewno szybciej.
pejott
No to musze Cię zmartwić, jeśli tak bardzo nie lubisz ich produktów, bo jeśli zdecydujesz się na CPP, to właśnie ich VS jest jednym z lepszych.
Każdy język ma swoje zastosowanie, jak i wydajność.
Crozin
Cytat
To logiczne. Kompilujesz raz i masz. Nie musisz tego parsować za każdym razem.
PHP też nie trzeba parsować/kompilować za każdym razem.
dr_bonzo
Cytat
PHP też nie trzeba parsować/kompilować za każdym razem.

O ILE uzyjesz DODATKOWEGO narzedzia ktorego NIE MA w STANDARDOWEJ dystrybucji - taki szczegol.
pyro
1. Sposób programowania (rola programisty)
2. Łatki na język (często z łatkami są poprawy szybkości)

Sam język raczej ciężko określić szybszym/wolniejszym.
230005
Cytat
O ILE uzyjesz DODATKOWEGO narzedzia ktorego NIE MA w STANDARDOWEJ dystrybucji - taki szczegol.


Jakie to narzędzie?
dr_bonzo
http://en.wikipedia.org/wiki/PHP_accelerator - tam masz liste "akceleratorow"
pyro
Tak odnośnie mojego poprzedniego posta, najszybszy jest assembler ze względu na to że podajesz bezpośrednio instrukcje maszynowe, ale nie wiem czy Ci się będzie chciało w nim pisać stronki www hihi ; >
Zyx
Szybkością języka nie ma się co przejmować - obecnie wydajność tworzonych aplikacji to rzecz drugorzędna, a bardziej liczy się czas, w jakim można produkt sprawnie wykonać. Co Ci da to, że PHP czy coś innego jest szybsze, kiedy ściągniesz pierwszego lepszego frameworka i jeśli nie wspomożesz się jakimiś systemami cache, to masz zajechany serwer. W ostatecznym rozrachunku liczy się to, który skrypt jest lepiej napisany i który lepiej korzysta z cache'u, bo ładowanie przy każdym żądaniu HTTP 2000 klas, z czego każda jest trzymana w osobnym pliku nawet, jeśli ma dwie linijki długości, nie jest najciekawszym pomysłem.

A później kończy się to tak, że trzeba mieć 2 GB RAM-u, by system w ogóle chciał wystartować i drugie tyle, by Notatnik zaczął działać... smile.gif
Crozin
To co @Zyx i jeszcze jedno: ważny jest też czas tworzenia aplikacji. Bo taniej jest dokupić i 16GB RAM niż opłacić miesiąc pracy jednego programisty.
Zyx
Jeśli ja zamówiłem projekt i mam do wyboru: kupuję więcej RAM-u, albo opłacam dodatkowe miesiące ekipie, to wybieram to, co tańsze. Ale jeśli zostaję postawiony przed faktem dokonanym: producent zmniejszył koszty, by mieć większy zysk na czysto, a ja nie dość, że nic z tego nie mam, to jeszcze muszę bulić dodatkowo na mocniejszy sprzęt...

Aby tworzyć wydajne aplikacje, trzeba orientować się także w funkcjonowaniu języka: które elementy są wydajniejsze, które mniej i umieć się w tym poruszać. Takie porównania można też robić między językami, ale bardziej bym to kwalifikował jako "ciekawostki". Duży program nie korzysta tylko i wyłącznie z ifów, ale z mnóstwa elementów składni i odwzorowanie tego w benchmarkach w realistyczny sposób jest bardzo trudne. O wiele łatwiej można coś powiedzieć o różnych typach języków: kompilowane do kodu maszynowego, kompilowane do bajtkodu, interpretowane...
sztosz
Cytat(Zyx @ 4.04.2009, 22:14:14 ) *
Szybkością języka nie ma się co przejmować - obecnie wydajność tworzonych aplikacji to rzecz drugorzędna, a bardziej liczy się czas, w jakim można produkt sprawnie wykonać.


To akurat jest prawda w całym świecie aplikacji. Prawda jest taka że, dla przykładowej gry z grafiką 3D oparta o DirectX i Shader Model 4.0, to gdyby pominąć DirectX i całe windowsowe API a napisać to (przepraszam że tak to nazywam) "pod DOS'a" to można by na sprzęcie o wiele słabszym wygenerować grafikę "szybciej" i "ładniejszą". Sęk w tym że postęp technologiczny jest szybszy niżby postępowała praca nad taką grą "pod DOS'a". Nie po to tworzymy sobie różne narzędzia żeby z używać krzemowych grotów strzał. Pisanie w "szybkim" (np. assembler) języku jest potrzebne na tak niskim poziomie jak programowanie najbardziej podstawowych układów scalonych. Żyjemy w XXI wieku. Piszmy w językach które są wygodne, po to je stworzyliśmy. A pisanie wydajnego kodu to umiejętność napisania wydajnego algorytmu, reszta to kwestia przetłumaczenia tego na wygodny, dowolny język.

Ja sobie dałem spokój z pisaniem aplikacji, bo jest milion ludzi którzy potrafią to zrobić lepiej, wydajniej ode mnie. Ale to nie znaczy że nie zauważam pewnych ogólnych problemów jak i schematycznie powielanych błędów, takich jak np. pytanie "Czy może ktoś wie jaki jest najszybszy w działaniu język programowania po stronie serwera na potrzeby web?". Bo odpowiedź, dajmy na to, jak napisał ~mike PHP, jest dobra (choć wcale nie twierdzę że PHP, ale to w mojej wypowiedzi nie ma znaczenia). Ta odpowiedź to tylko puste słowo. Jeśli już ktoś zadaje takie pytanie to znaczy że źle pyta, powinien zapytać "Co powinienem zrobić aby pisać wydajne aplikacje?". A jeśli w danej sytuacji rzeczywiście ma znaczenie wydajność samego języka, to pytający by nie pytał, bo i tak jest pewnie na tyle dobry że będzie znał odpowiedź.

Jeśli napisanie czegoś w PHP zajmuje mi 2 tygodnie. A w innym, teoretycznie wydajniejszym języku, 4 tygodnie. To i tak lepiej żebym to napisał w PHP, bo koszt dodatkowego ramu/procka będzie mniejszy niż te dodatkowe 2 tygodnie mojej pracy.

PS. Jestem pod wpływem alkoholu. Mamy wszak sobotę. Jeśli w pewnym momencie zacząłem bełkotać to przepraszam winksmiley.jpg
Zyx
Porównywanie wydajności programów/technik, które mają zupełnie inną funkcjonalność, specjalnie nie ma sensu. Masz czołg i masz pistolet, pistoletem uszkodzisz napastnika dużo szybciej, ale mimo to armie nie wysyłają czołgów na złom, ponieważ obie te rzeczy, choć pozornie robią to samo (zabijają wrogów), mają zupełnie inne cele i priorytety. API DirectX nie zostało wprowadzone tylko po to, aby można było sobie napisać "drawPixel" zamiast klepać 20-linijkowy kod w assemblerze i wywoływać odpowiednie przerwania, tylko aby uniezależnić program od sprzętu i w razie potrzeby emulować brakującą funkcjonalność. Porównywanie wydajności ma sens w przypadku aplikacji/bibliotek oferujących podobną funkcjonalność i zajmujących się mniej więcej tym samym, np. DirectX i OpenGL, Windows i Linux. Porównaj sobie pod względem wydajności CP/M i Linuksa i wiadomo, co wygra (CP/M), tylko co z tego, kiedy w CP/M mogę mieć odpalony tylko jeden program naraz? Porównaj sobie Linuksa i Windowsa i tu oba systemy mają taką samą szansę na zwycięstwo. Wygra ten, który faktycznie wywiązuje się z zadania lepiej.

Gdy produkt nie reprezentuje sobą nic, jest ślamazarny, bo napchano do niego syfu bez zastanowienia się, czemu to ma w ogóle służyć (co się często zdarza), to czemu ja mam nie dość, że napychać kasę producentowi, to jeszcze ponosić dodatkowy koszt zakupu w imię źle pojętej "optymalizacji wykorzystania czasu programisty"?
sztosz
Masz rację a propos DirectX, ale to jest nie ma znaczenia po co jest DirectX, OpenGL czy wcześniej Glide dla 3dfx'ów. Ale autor tematu pyta o wydajność języka. A tu chodzi o wydajność programisty. Jeżeli programista umie dobrać narzędzia tak aby szybko przy ich pomocy napisać aplikację, to zostaje wtedy więcej czasu na testowanie + debugowanie i optymalizację.
SHiP
W zasadzie zgadzam się z przedmówcami. Aplikacje każdego języka można cache'owac. Zawsze można zastosować pamięć współdzieloną etc. Rozwiązań optymalizacji jest sporo a rozwój komputerów tak szybki, że zamartwianie się ósmą cyfrą po przecinku bez sensu.

Cytat(phpion @ 3.04.2009, 19:34:41 ) *
Ponieważ? Kolejny młody gniewny... Ja bym na twoim miejscu rozważył jednak ASP.NET. Nigdy nie miałem z tym styczności, składnia do mnie nie przemawia jednak podobno jest to całkiem niezłe narzędzie.


Problem z rozwiązaniami Microsoftu stoją po stronie serwera. Na linuksie raczej nie uruchomisz .net a ja osobiscie nie wyobrażam sobie tworzenia struktury serwerów bez linuksów ana pokładzie...
Zbłąkany
@SHiP:
W obliczeniach numerycznych wysokiej precyzji bierze się pod uwagę czasem i 25 cyfr znaczących, a poza tym często czas takich obliczeń jest ważny (najczęściej wykonuje się to samo zadanie albo podobne wielokrotną ilość razy) więc niezależnie, czy miałeś na myśli czas wykonania, czy też dokładność obliczeń, to bym bardzo ostrożnie rzucał cyframi smile.gif
Kocurro
SHiP: ja na swoich serwerach mam spokojnie zainstalowane MONO i ASP.NET aplikacje chodzą (fakt, trochę kombinowania było z tym ale działa bez problemu), nawet ładnie działa Remoting. Więc nie widzę problemu z wykorzystaniem platformy .NET smile.gif

Na marginesie - nie używam takiego rozwiązania bo jest tańsze, bo nie lubię Microsoftu tylko dlatego, że nie potrafię dobrze skonfigurować serwera Windowsowego a Linuxa potrafię zabezpieczyć smile.gif

Pozdrawiam,
Łukasz
gam3r
http://www.timestretch.com/FractalBenchmark.html
http://shootout.alioth.debian.org/
http://blog.dhananjaynene.com/2008/07/perf...n-jruby-groovy/
http://scutigena.sourceforge.net/

oczywiście większość zależy od programisty, można przecież napisać kod działający szybciej w php niż w c++, ale przyznacie że cięzko to sobie wyobrazić.
również oczywiscie nie ma co porównywać języków zaprojektowanych do zupełnie innych zadań ( jak np. php i c ) ale języki już tego samego kalibru - np. grupe: php, python, ruby, asp.net, perl śmiało można porównywać, chociaż oczywiście to jak dokładnie spisze się któryś z nich to zależy od zadania jakie dostaną;

generalnie jeśli chodzi o web, to przy założeniu że programujemy najoptymalniej jak tylko potrafimy to python zwycięża php, ruby'ego, a w najbliższym czasie jeszcze ma przyśpieszyć pięciokrotnie: http://code.google.com/p/unladen-swallow/

inną sprawą jest oczywiście że w momencie pisania/tworzenia produktu, jakim ma być jakieś oprogramowanie to wybór narzędzi jest podyktowany raczej: dostępnością wsparcia dla jakiegoś środowiska, ilością dobrych bibliotek/frameworków, aniżeli szybkością z jaką działa napisany tam program; takie są kryteria dla 99% tworzonych dzisiaj rozwiązań - rozwiązań które nie muszą być superwydajne bo zawsze można dokupic kolejnego proca, ram, czy costam jeszcze. Jest jednak pewna grupa zadań, w których na pierwszym miejscu stoi wydajność
michalg
Ja może trochę odejdę od tematu.

Czy ktoś kiedyś próbował się bawić jakimiś kompilatorami do PHP? Czy da się tego używać? Czy to działa? Czy widać wzrost wydajności?

Nie mówięc tutaj oczywiście o wszelkiej maści akceleratorach php.
erix
Cytat
Nie mówięc tutaj oczywiście o wszelkiej maści akceleratorach php.

Przecież one działają na tej zasadzie - prekompilują kod do postaci binarnej... Chyba, że masz na myśli jakiś konkretny kompilator na myśli.
michalg
Cytat(erix @ 7.04.2009, 23:30:54 ) *
Przecież one działają na tej zasadzie - prekompilują kod do postaci binarnej... Chyba, że masz na myśli jakiś konkretny kompilator na myśli.


Chodzi mi o takie kompilatory, jak:
http://www.roadsend.com/home/index.php?pageID=compiler - natywny kod
http://phalanger.codeplex.com/ - bytecode .net
http://en.wikipedia.org/wiki/Project_zero - bytecode javy

Pewnie jeszcze jakieś inne też są.
erix
No widzę, ale jeśli chodzi o PHP, to zauważ:
Cytat
Roadsend compiles your PHP project to a single, native binary which does not require an interpreter.

Ale podejrzewam, że to działa na identycznej zasadzie jak akcelerator z tą różnicą, iż są dorzucane biblioteki umożliwiające wykonanie.
michalg
Cytat(erix @ 8.04.2009, 19:46:44 ) *
Ale podejrzewam, że to działa na identycznej zasadzie jak akcelerator z tą różnicą, iż są dorzucane biblioteki umożliwiające wykonanie.


Jak to napisałeś, to pomyślałem, że pewnie masz rację, że to tworzy plik exe zawierający oryginalny silnik PHP i prekompilowane skrypty. Tak działa chyba py2exe, który tworzy gotową paczkę do uruchamiania programów pythonowych. Takie rozwiązanie by było najprostsze.

Ale, nie - sprawdziłem i jednak nie poszli na łatwiznę
Z wikipedii (http://en.wikipedia.org/wiki/Roadsend_PHP):
Cytat
Roadsend PHP is a completely independent implementation of the PHP language and runtime environment, and is not based on the original implementation (using the Zend Engine). "Zend PHP" is not required, and is not used in any way, by Roadsend PHP. Roadsend is implemented in Bigloo Scheme and C.
[...]
Roadsend achieves native compilation by compiling to bigloo scheme, which in turn is compiled to C, then to machine code.

Więcej jest też w faqu na ich stronie.
S_Olewniczak
A co myślicie o Javie. Czy jest szybsza od pythona i czy nadaje się do zastosowań web?
Riklaunim
Cytat(S_Olewniczak @ 10.04.2009, 17:13:40 ) *
A co myślicie o Javie. Czy jest szybsza od pythona i czy nadaje się do zastosowań web?

Nie jest szybsza od Pythona dla prostych zastosowań (czytaj małe i średnie serwisy).


Ale wracając do tematu RoadSenda - ktoś coś skompilował większego za jego pomocą? PHP-Fusion i punBB się skompilowały ale miałem problemy z ich odpaleniem (chyba problemy wynikające z braków w implementacji RoadSenda). phpinfo przeszło smile.gif Może ezPublish przejdzie, nie używa on najnowszych bajerów PHP5, a taka binarka kodu maszynowego mogłaby znacząco go przyśpieszyć (przy takiej ilości kodu i plików).
nasty
Cytat(S_Olewniczak @ 10.04.2009, 17:13:40 ) *
A co myślicie o Javie. Czy jest szybsza od pythona i czy nadaje się do zastosowań web?


No co Ty... Java i zastosowania web? nie bądźmy śmieszni.
Fantazyn
Cytat(nasty @ 23.06.2009, 01:33:23 ) *
No co Ty... Java i zastosowania web? nie bądźmy śmieszni.


Czy mogę Cię prosić o rozwinięcie tego?

Edit: dziękuję za poniższe odpowiedzi.
erix
Śmieszne - prędkość, a właściwie zasobożerność
nie-śmieszne - możliwości języka; parę dużych serwisów na niej działa (np. polski Orange), ale z powodu "wydajności" często można spotkać prosimy spróbować później.
mike
Cytat(Fantazyn @ 23.06.2009, 09:04:05 ) *
Czy mogę Cię prosić o rozwinięcie tego?
A co tu rozwijać. Głupot się nie rozwija.
Każde narzędzie ma swoje zastosowanie. Java również jest z powodzeniem wykorzystywana w dużych projektach internetowych. Choć fakt, pisanie w Javie pierdół w stylu skrypt gości czy sklepik mija się z celem.
nasty
... się ma to wyczucie ironii, nie mike? ;-)
mike
Cytat(nasty @ 23.06.2009, 12:08:36 ) *
... się ma to wyczucie ironii, nie mike? ;-)
Czuję ironię ale nie u osób, które jej nadużywają.
"Połowę" rzeczy na Hydeparku piszesz z ironią więc się nie dziw.
nasty
Cytat(mike @ 23.06.2009, 14:44:03 ) *
"Połowę" rzeczy na Hydeparku piszesz z ironią więc się nie dziw.

Dobry jesteś biggrin.gif 1:0 biggrin.gif


edit:

Crozin: akurat to nie było z ironią smile.gif bo serio, tak ułożył zdanie, że cokolwiek bym nie odpowiedział na nie to mógłby mnie o brak wyczucia oskarżyć :-) więc wygrywa biggrin.gif
Crozin
To zapewne też ironia biggrin.gif
mike
Cytat(Crozin @ 23.06.2009, 15:07:37 ) *
To zapewne też ironia biggrin.gif
No widzisz. W złą połowę trafiłeś tongue.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.