c++.de :: PHP

Unregistrierter

Zeus schrieb:

Fakt ist, Facebook wird in PHP geschrieben.

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

Unregistrierter

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

Shade Of Mine Moderator 15:08:10 26.04.2012 Titel:

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".

Zitat:

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.

Unregistrierter

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

314159265358979 Mitglied 15:24:25 26.04.2012 Titel:

Hahahahaha, du bist so unglaublich naiv.

Ich gebe dir ein weiteres Beispiel. Die Seite [url]dsreal.de[/url] (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 Moderator 17:09:02 26.04.2012 Titel:

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

Unregistrierter

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 :confused:

Michael E. Mitglied 23:25:23 26.04.2012 Titel:

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):

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31	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:

Code:
299 0.000000 0.000000 0.000000 ( 0.003000)

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

Zeus Mitglied 20:24:14 27.04.2012 Titel:

Seid wann ist Ruby langsam? Okey Ruby on JVM ist nicht spannend :P
http://blog.headius.com/2 ....... ruby-makes-ruby-fast.html