PHP - Breitensuche

Shade Of Mine schrieb:

CGI ist ja sehr dumm

und php läuft nicht immer als modul. aber hey, mach was du willst! nimm meinetwegen php und js im backend aber verzapf das keinem, der nach ganz oben will!

Bashar

Shade Of Mine schrieb:

PHP läuft als apache Module direkt im Kontext des Servers. Was enorme Performance Vorteile gegenüber zB CGI bringt. CGI ist ja sehr dumm und startet jedesmal einen neuen Prozess. FastCGI ist da schon etwas besser, aber immer noch nicht auf dem Niveau eines Apache Modules.

Und Apache ist der einzige relevante Webserver? Und es gibt keine C++-Module? Ich hab das Gefühl das ist kein technisches Argument, sondern wieder ein Verweis darauf, was verbreitet und üblich ist. Aber es ist auch nur ein Gefühl.

Das ganze kombiniert mit einem OpCode Cache reduziert die Startzeiten von PHP Code auf quasi 0.

Wieso sind die Startzeiten so relevant? Ein Prozess ist vielleicht nicht ganz so schnell gestartet, aber wenn dein PHP-Script im Sekundenbereich rumrödelt verblasst der Unterschied bei der Startzeit schnell.

314159265358979

Shade Of Mine schrieb:

Eine Astreine Themenverfehlung.
Weil du nicht kapierst worum es geht.

Gebe ich gleich mal so an dich zurück. Es geht hier um den TE und sein Problem. Der TE sagt: Ich nehme PHP und Algorithmus X, aber das ist vielleicht zu langsam, vielleicht sollte ich mich nach Algorithmus Y umsehen. Darauf sage ich nur: PHP ist einfach langsam, nimm eine schnellere Sprache.

Um nichts anderes geht es hier. Wenn ich Performance brauche, dann nehme ich ganz sicher nicht PHP. Das war schon immer so und wird für ziemlich lange auch sicherlich noch so bleiben.

/eof

Zeus

314159265358979 schrieb:

Shade Of Mine schrieb:

Eine Astreine Themenverfehlung.
Weil du nicht kapierst worum es geht.

Gebe ich gleich mal so an dich zurück. Es geht hier um den TE und sein Problem. Der TE sagt: Ich nehme PHP und Algorithmus X, aber das ist vielleicht zu langsam, vielleicht sollte ich mich nach Algorithmus Y umsehen. Darauf sage ich nur: PHP ist einfach langsam, nimm eine schnellere Sprache.

Genau dies zeigt den Unsinn, nicht die Sprache entscheidet die Ausführungsgeschwindingkeit des Programms sondern seine Implementierung ( Was denkst du warum mein Javascript-Beispiel zu gut abschneiden im Vergleich zu deinem PHP-Code). Seine Problemgröße rechtfertig ein Umstieg nicht im Ansatzweise. Bleibt ihm noch frei Optimierungsstategie die Logik in die Datenbank abbilden und andere Implementierungen zu benutzen(hiphop, pdc, hiphop-vm...) anzuwenden. Evtl. sprechen andere Faktoren doch für die Implementierung mit C++, Webserver mit FastCGI ist schon vorhanden, Webserver ist keiner mit Anderem geteilt... was auch immer. Aber diese Pauschalargumente geht mir echt auf die Eier.

314159265358979

Blablablabla. Mimimimi. Hör doch auf mit dem Gedöns. Niemand, aber auch wirklich niemand, der Performance braucht, nimmt PHP. Frag Google. Frag Facebook.

Zeus

314159265358979 schrieb:

Blablablabla. Mimimimi. Hör doch auf mit dem Gedöns. Niemand, aber auch wirklich niemand, der Performance braucht, nimmt PHP. Frag Google. Frag Facebook.

Facebook nutzt PHP! Deswegen investieren sie in bessere Implentierung - siehe Hiphop Compiler und hhvm.

314159265358979

Facebook nutzt einen PHP zu C++ Compiler, weil PHP zu langsam ist. Das würde ich nicht als Pluspunkt für PHP werten.

Zeus

314159265358979 schrieb:

Facebook nutzt einen PHP zu C++ Compiler, weil PHP zu langsam ist. Das würde ich nicht als Pluspunkt für PHP werten.

Aus ein Irrtum folgt Irrelevant, das kann jeder sehen wie möchte, im Ganzen ist es egal ob du oder ich es als als ein Minuspunkt(deine Meinung), Pluspunkt(wessen Meinung?), oder als nicht relavent ansieht(meine Meinung). Fakt ist, Facebook wird in PHP geschrieben.

Zeus schrieb:

Fakt ist, Facebook wird in PHP geschrieben.

facebook ist auch der größte dreck - kein gutes beispiel...

314159265358979 schrieb:

Facebook nutzt einen PHP zu C++ Compiler, weil PHP zu langsam ist. Das würde ich nicht als Pluspunkt für PHP werten.

warte, sie sind dadurch um faktor 2 schneller geworden und das hat sich schon gelohnt und hier wird faktor 7 von js zu c++ belächelt php bekommt man nicht schnell... liegt am sprachdesign.

btw. ein hiphop hello world ist mit ~30mb ein mehr als fettes baby, ich würde fast sagen, eine totgeburt :p

Shade Of Mine

314159265358979 schrieb:

[
Gebe ich gleich mal so an dich zurück. Es geht hier um den TE und sein Problem. Der TE sagt: Ich nehme PHP und Algorithmus X, aber das ist vielleicht zu langsam, vielleicht sollte ich mich nach Algorithmus Y umsehen. Darauf sage ich nur: PHP ist einfach langsam, nimm eine schnellere Sprache.

Das hat der OP nie irgendwo gesagt. Er hat nur nach der Speicherkomplexität bzw. möglichen Speicherproblemen gefragt. Die korrekte Antwort war "Bei sowenig Elementen ist alles egal".

Um nichts anderes geht es hier. Wenn ich Performance brauche, dann nehme ich ganz sicher nicht PHP. Das war schon immer so und wird für ziemlich lange auch sicherlich noch so bleiben.

Du bildest dir immer einen Punkt ein und bleibst darauf fixiert. Sicher wenn ich Number Crunching mache ist eine Webapp in PHP keine Gute Idee. Aber wenn ich eine Webapp haben will, ist C++ ebenfalls eine schlechte Idee. Number crunching in einer Webapp ist irgendwie doof.

Es geht um reellen Anfoderungen. Es ist kein Problem eine Webapp zu schreiben die in PHP soviel schneller ist als du sie in C++ mit normalen Aufwand hinbekommen könntest. PHP hat erst Skalierungsprobleme wenn wir an die absoluten extremen gehen - wie zB Facebook. Die haben etliche Milliarden Hits pro Tag. Das ist verdammt viel. Da ist zB yahoo oder microsoft.com ein dreck dagegen. Und dennoch könnte man es mit PHP stemmen. Das spricht schon ziemlich für PHP

Irgendwo sind halt dann doch immer Grenzen und man muss eine spezielle Lösung schaffen um den speziellen Umständen gerecht zu werden. Aber bei jeder normalen Webseite wie zB yahoo, microsoft.com, apple.com, etc. wäre PHP kein Problem. (yahoo, wikipedia, digg, flickr,... laufen zB auf PHP).

Du fixierst dich auf nebensächlichkeiten. Weil Execution Speed irrelevant ist. Das interessiert in der realen Welt niemanden. Was zählt ist Skalierbarkeit. Und PHP skaliert sehr gut.

ich bin mir inzwischen fast sicher, dass du noch nie in einem richtig schnellen auto gesessen bist - wär ja auch alles doof, n langsame sind ja gleich stark :p

314159265358979

Hahahahaha, du bist so unglaublich naiv.
Ich gebe dir ein weiteres Beispiel. Die Seite dsreal.de (Statistiken für das BG Die-Stämme) benutzt einen eigens dafür geschriebenem PHP-Interpreter, weil der Original-Interpreter zu langsam ist.

Aber ja, schon klar. PHP ist ja so toll.

Shade Of Mine

314159265358979 schrieb:

Hahahahaha, du bist so unglaublich naiv.

Facebook, digg, yahoo, flickr,...
nuff said

PS:
ich liebe es wie du immer vom Thema abweichst sobald dein standpunkt untragbar wird

Shade Of Mine schrieb:

Facebook, digg, yahoo, flickr,...

ist doch genau der punkt... wer will schon mit diesen firmen auf ein treppchen? wenn er in die königsklasse zu google darf

Michael E.

314159265358979 schrieb:

Ob der Algorithmus schlecht ist, spielt überhaupt keine Rolle. Ob man das mit Caching optimieren kann, ist ebenso scheißegal.

Der TE meinte, wenn der Algorithmus in PHP zu langsam ist, nimmt er einen anderen. Vielleicht eher die richtige Programmiersprache für rechenintensives Zeug aussuchen, anstatt zu behaupten, der Algorithmus wäre ungeeignet. DAS ist die Message.

Dann ist deine Message kompletter Blödsinn. Sogar bei der total simplen Breitensuche sieht man das: Auf dünn besetzten Graphen in Adjazenzlistendarstellung hab ich den Algorithmus in ner Skriptsprache durchgeführt, bevor du überhaupt die Adjazenzmatrix in deinem C++-Programm in den Speicher geladen hast.

Aber schauen wir uns mal den Anwendungsfall des OP an, d.h. 300 Knoten mit 900 Kanten. Hier mal in ner anderen langsamen Skriptsprache namens Ruby (der geneigte Leser darf das gerne nach PHP portieren, dafür bin ich zu faul):

require 'benchmark'

# zufälligen Graphen mit 300 Knoten und 900 Kanten erstellen
n = 300
m = 900
edges = (0..n).map{|i| []}
while edges.map{|a| a.size}.inject(:+) < 2*m
	v1 = rand(n)
	v2 = rand(n)
	if v1 != v2 && !edges[v1].include?(v2)
		edges[v1] << v2
		edges[v2] << v1
	end
end

# Breitensuche draufwerfen
time = Benchmark.measure do
	marked = Array.new(n, false)
	tree_edges = []
	queue = [0]
	marked[0] = true
	queue.each do |v|
		new_vertices = edges[v].reject{|w| marked[w]}
		queue.concat new_vertices
		new_vertices.each{|w| marked[w] = true}
		tree_edges.concat new_vertices.map{|w| [v,w]}
	end
	puts tree_edges.size
end

puts time

Ausgabe:

299
  0.000000   0.000000   0.000000 (  0.003000)

Mein Gott! 3 Millisekunden verschenkt! Starte schnell einen C++-Prozess, um Zeit zu sparen

Zeus

Seid wann ist Ruby langsam? Okey Ruby on JVM ist nicht spannend
http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html