Javascript erreicht 50% von C++ Performance
-
Halb so schnell wie C++, dass sollte für die meisten Anwendungen reichen, oder?
http://www.golem.de/news/ams-js-epic-citadel-laeuft-auch-in-chrome-und-opera-1311-102987.html
-
Ist das jetzt gezieltes Provozieren eines Flamewars?
-
pfff, 50% schnell ist 100% langsam ...
-
Ich find das spannend. Danke für dn Link.
C# ist gerademal so schnell wie javascript
-
Ich wüsste gerne, wie das gemessen wurde.
Was heißt denn 50% schneller?
Das Beispielprogramm ist in ziemlich schlecht, denn das Hauptbottleneck bei Spielen ist oft der Grafikkartenbus. Außerdem wird die grafische Berechnung nicht von Javascript ausgeführt, sondern von der Renderpipeline auf der graka bzw. den darin eingebauten Shadern und die sind weder in C++ noch Javascript, sondern in einer C-ähnlich Shadersprache.Außerdem sind Vergleiche schwierig, denn oft wird zwischen stark abstrahierenden (javascript) und hardwarenahen (C++) Sprachen anders gearbeitet, z.B. ist es möglich, dass javascript einen Memorypool nutzt, während C++ immer wieder neuen Speicher anfordern muss?
Dann interessiert mich noch, ob denn auch C++11 verwendet wurde, denn move macht einen nicht zu verachtenden Geschwindigkeitsunterschied aus, der die 50% auch auf 30% reduzieren kann.
Es ist aber sehr schön, was inzwischen alles möglich ist, obwohl ich beim Browser immer so ein bisschen skeptisch bin, denn es gibt größere Datenmengen und Gefahren (z.B. Viren) und ein richtiges Spiel herunterzuladen ist doch kein wirkliches Problem.
EDIT: Der Post soll nichts schlecht machen. Ich werfe nur ein paar Fragen und Probleme auf und kritisiere diesen Vergleich mit so konkreten Zahlen. Dennoch bin ich von der Entwicklung fasziniert.
-
Marthog schrieb:
Ich wüsste gerne, wie das gemessen wurde.
Das hier. Eine Nebebemerkung, dass irgendwas in irgendeiner Sprache 50% schneller oder langsamer ist, ist recht wertlos. Das kann zumal alles mögliche sein, zum Beispiel etwas, bei dem die Sprache kaum eine Rolle spielt, da nur Systemaufrufe oder ähnliches erfolgen (zum Beispiel hier Aufrufe an die Grafikbibliothek?) oder es kann auch ganz einfach stümperhafter Code in jeder Sprache sein. Ich habe schon Anfänger-C und -C++ gesehen, die man mittels kleiner Änderungen extrem beschleunigen konnte, da der Code nicht gut programmiert war und diese Sprachen solche Fehler nicht vergeben.
-
Hier sind die Ergebnisse:
-
Es geht doch um eine Grafikdemo, oder? Damit sind die Ergebnisse schon aussagekräftig, aber halt in einem gewissen Rahmen und nicht allgemein.
-
Mechanics schrieb:
Es geht doch um eine Grafikdemo, oder? Damit sind die Ergebnisse schon aussagekräftig, aber halt in einem gewissen Rahmen und nicht allgemein.
Gerade dann ist es doch eher ein Grafikkartenbenchmark. Eine Grafikanwendung rechnet typischerweise eher wenig auf der CPU und macht die meiste schwere Arbeit in Form von Aufrufen an die Grafikschnittstelle. Das hieße dann, dass das Javascript diesen kleinen Teil derart vermasselt, dass es insgesamt deutlich langsamer ist als C. Oder dass die Grafikschnittstelle der JVM erstaunlich gut ist. Oder ganz was anderes. Ohne eine etwas umfangreichere Analyse kann man hieraus keine Schlüsse ziehen, außer dass diese Javascriptengine halbwegs gut für 3D-Grafik geeignet ist. Aber nicht solche Bildschlagzeilen wie der Threadtitel.
-
Mechanics schrieb:
Es geht doch um eine Grafikdemo, oder? Damit sind die Ergebnisse schon aussagekräftig, aber halt in einem gewissen Rahmen und nicht allgemein.
Nein. Es ist egal, wie gut die Programmiersprache optimieren kann, wenn das Programm den Großteil der Zeit auf die Grafikkarte warten muss. Der eigentliche Algorithmus wird auf der Grafikkarte ausgeführt und das Programm muss selber nur Daten laden, die Eingeb verarbeiten, die Transformationsmatrizen verechnen und schließlich die richtigen Daten rendern lassen. Ich weiß nicht, wieviel Javascript überhaupt macht, aber ich weiß, dass bei einfachen 3d-Szenen, das Bottleneck meistens der Grafikkartenbus oder der Rendervorgang selbst sind.
Würde man ein paar andere Menschen einfügen, für die Kollision, Animationen und KI berechnet werden muss, würde die Performance möglicherweise ziemlich in die Knie gehen.
Ich habe nichts gegen das Projekt, es wird aber geschlossen, dass Javascript 50% langsamer als C++ ist, obwohl die Messungen gar nicht aussagekräftig sind.Wenn schon, dann sollten für so eine Aussage verschiedene Berechnungen für z.B. Sortieralgorithmen, Gaussian Blur auf ein Bild, A*-algorithmus, etc gegeben und dann die Geschwindigkeit verglichen werden.
-
naja, für mich klingt das erstmal garnicht so abwegig. asm.js ist eben ein JIT-compilat JS->LLVM. Da passt shcon, dass die performance gleichauf mit Java ist. Und Java ist nunmal keine lahme Schnecke
-
SeppJ schrieb:
Gerade dann ist es doch eher ein Grafikkartenbenchmark.
Und ich glaube, darum gings denen vor allem auch. Also, nicht um einen Grafikkartenbenchmark, sondern um deren Engine. Die wollten doch eigentlich nur zeigen, dass man deren Engine auch im Browser betreiben kann und die Performance durchaus akzeptabel ist (trotz dem, dass JavaScript hier so langsam ist oder wie auch immer).
-
Mechanics schrieb:
SeppJ schrieb:
Gerade dann ist es doch eher ein Grafikkartenbenchmark.
Und ich glaube, darum gings denen vor allem auch. Also, nicht um einen Grafikkartenbenchmark, sondern um deren Engine. Die wollten doch eigentlich nur zeigen, dass man deren Engine auch im Browser betreiben kann und die Performance durchaus akzeptabel ist (trotz dem, dass JavaScript hier so langsam ist oder wie auch immer).
Das haben sie dann auch erreicht. Aber es stößt keine Sprachdiskussion an, was der TE wollte.
-
Ich versteh das gerade eh nicht ganz:
Ist 50% gut?
-
Nathan schrieb:
Ich versteh das gerade eh nicht ganz:
Ist 50% gut?Zumindest dann, wenn man vorher in dem Ruf stand, eher 0.5 % zu haben.
-
SeppJ schrieb:
Marthog schrieb:
Ich wüsste gerne, wie das gemessen wurde.
Das hier. Eine Nebebemerkung, dass irgendwas in irgendeiner Sprache 50% schneller oder langsamer ist, ist recht wertlos. ...
+1
Weiters: da geht's nicht um JavaScript, sondern um ein stark eingeschränktes Subset von JavaScript.
Und dass das gleich schnell wie C# sein soll, das glaub ich auch erst wenn ich entsprechende Benchmark-Ergebnisse + verwendetem Code sehe.
Davon abgesehen... dass JavaScript (das vollständige) für ne Skriptsprache sauschnell ist, ist eh schon lange bekannt.
-
Lustig, was für Abwehrreflexe sowas auslösen kann ...
Marthog schrieb:
Wenn schon, dann sollten für so eine Aussage verschiedene Berechnungen für z.B. Sortieralgorithmen, Gaussian Blur auf ein Bild, A*-algorithmus, etc gegeben und dann die Geschwindigkeit verglichen werden.
Wie wärs damit:
https://github.com/dvander/arewefastyet/blob/master/benchmarks/asmjs-ubench/primes.cpp
http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubenchhustbaer schrieb:
Weiters: da geht's nicht um JavaScript, sondern um ein stark eingeschränktes Subset von JavaScript.
Es ging noch nie darum, asm.js von Hand zu schreiben. Dafür gibt es C++-zu-asm.js-Compiler (C++->LLVM->asm.js) und so. asm.js selbst ist eine Art menschenlesbarer Bytecode. Und wie im Benchmark zu sehen ist, ist das effektiv genauso schnell. Und ich würde sogar behaupten, es wird noch schneller, da sie sinnigerweise auf einen GC verzichtet haben.
-
Der Titel des threads ergibt, wenn man den Artikel gelesen hat, keinen Sinn. Die Unreal Engine ist doch sicherlich mit c oder c++ geschrieben. Dann hat man das statt direkt in Maschinencode eben über den Umweg von llvm bytecode in asm.js compiled. Und jetzt braucht es anscheinend "nur" doppelt so lang für gleiche Berechnungen, als wenn man es direkt in Maschinencode compiled hätte.
Von Hand geschriebenes Javascript wäre sehr wahrscheinlich deutlich langsamer.
