PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : C++/Java/Scala Performance-Vergleich


Exxtreme
2011-08-16, 15:26:08
https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

Da gibt es auch einige Performance-Tipps zu den jeweiligen Sprachen. C++ ist in diesem Test ganze Größenordnungen schneller. Und auch die 64-Bit-Version von Java ist wesentlich flotter als die 32-Bit-Version.

Und wenn man diesem Abschnitt glauben schenken darf:

"Doug Rhode created a greatly improved version, which
improved performance by 3x to 5x. This version will be
kept in the havlak_cpp_pro directory. At the time
of this writing, the code was heavily dependent on several
Google internal data structures and could not be open sourced."

Dann geht noch viel mehr mit C++.

Trap
2011-08-16, 16:19:09
Das ist ein Vergleich, der sehr von der Performance der Datenstrukturen abhängt (wie man ja schon am noch möglichen Faktor 3-5 bei C++ sieht).

Generics sind da vom Ansatz etwas umständlicher, die meisten JVMs werden wohl nur eine generische Machinencodeversion erzeugen. Templates dagegen bekommen für jede Spezialisierung extra Machinencode. Dadurch verliert man bei Generics Chancen für Inlining und hat eventuell auch Autoboxing.

Weiter ist das ein Benchmark mit sehr einfacher Speicherverwaltung, alle Speicheraktionen sind auf den programmiererdefinierten Strukturen (mit jeweils einem einzelnen eindeutigen Besitzer) und keine Operationen auf den Daten. Man hat in dem Fall keinen Vorteil durch den GC, aber alle Nachteile.

Grundsätzlich finde ich den Vergleich durchaus sinnvoll, man muss nur berücksichtigen, dass er nur einen gewissen Teil der Performance der Programmiersprachen untersucht.

Exxtreme
2013-04-19, 16:35:56
http://www.techempower.com/blog/2013/03/28/framework-benchmarks/
http://www.techempower.com/blog/2013/04/05/frameworks-round-2/

Betrifft zwar jetzt Webframeworks, diese sind aber sehr oft mit bestimmten Programmiersprachen verbandelt. Auch hier interessant, dass viele "Hype"-Sprachen/Frameworks sehr langsam sind.

Trap
2013-04-19, 21:18:09
Ja, die sind langsam. So langsam, dass man schon bei 1 Millionen Request pro Monat einen 2. Server braucht...
Realistisch gemessen wahrscheinlich schon deutlich früher.

Aber ist das ein Problem? Wie muss das Verhältnis zwischen Zahl Entwicklern, Zahl Aufrufen, Kosten pro Entwickler, Kosten pro Server, Verhältnis Entwicklungsaufwände zwischen Frameworks und Verhältnis Performance zwischen Frameworks sein, damit sich das eine oder das andere lohnt? 6 Variablen, Verhältnis von 2 als Ergebnis, 1 bekannt, man muss man also 3 Annahmen treffen um eine Aussage zu bekommen.

Demirug
2013-04-19, 22:09:55
Server sind heute so billig das es meistens die günstigste Lösung ist solange Hardware auf ein Performance Problem zu werfen bis es gelöst ist.

Wäre unser Servercode mit C++ programmiert bräuchten wir wahrscheinlich auch weniger Hardware (wobei wir eher am RAM und weniger an der CPU limitiert sind). Trotzdem ist alles mit C# programmiert.

][immy
2013-04-19, 23:27:12
Server sind heute so billig das es meistens die günstigste Lösung ist solange Hardware auf ein Performance Problem zu werfen bis es gelöst ist.

Wäre unser Servercode mit C++ programmiert bräuchten wir wahrscheinlich auch weniger Hardware (wobei wir eher am RAM und weniger an der CPU limitiert sind). Trotzdem ist alles mit C# programmiert.
das liegt wohl eher an schnellerer entwicklung und leichterer wartung. hardware spielt glücklicherweise inzwischen nicht mehr so eine große rolle beim kunden.
ich kann mir im .net bereich immer nur an den kopf packen wenn dann ein kunde mit sql, sharepoint und sonst noch was mit einem einzelnen 8gb server angekommt. vor jahren waren diese 8gb noch sowas von gigantisch, aber inzwischen ... naja reicht grad mal so für ein altes entwicklungssystem
das liegt aber nicht an .net sondern zum großteil liegt es inzwischen daran das viele services genutzt werden, welche alle für sich laufen. dadurch haben die services alle nen ziemlich heftigen memory-footprint. zudem werden sie noch mal ausgebremst weil die services dann auch noch über webservices miteinandern kommunizieren damit diese nach möglichkeit auf viele server verteilt werden können. damit wird dann zwar jeder request für sich langsamer, aber es können mehr request gleichzeitig verarbeitet werden und damit die gesamt-performance des systems durch verteilung erhöht werden.

schon ein wenig absurd, damit es für alle schneller wird muss es für jeden langsamer werden ^^.
aber letztlich hat es alles mit schnellerer entwicklung zu tun, da es einfacher ist einzelne Prozesse auf verschiedene teams aufzuteilen, als das große teams an einem Prozess (der quasi alles kann) arbeiten zu lassen. nur werden für meinen geschmack services ein wenig zu exzessive genutzt.

Marscel
2013-04-20, 00:20:03
http://www.techempower.com/blog/2013/03/28/framework-benchmarks/
http://www.techempower.com/blog/2013/04/05/frameworks-round-2/

Betrifft zwar jetzt Webframeworks, diese sind aber sehr oft mit bestimmten Programmiersprachen verbandelt. Auch hier interessant, dass viele "Hype"-Sprachen/Frameworks sehr langsam sind.

Interessante Vergleiche, danke für die Links!

Schon erstaunlich, wie lahm Ruby und Rails gegen die Java-Frameworks sind. Andererseits ist RoR meiner Ansicht nach recht ungeschlagen, was das Gesamtpaket bezüglich Features betrifft: verglichen mit ASP.NET, purem PHP und Java-Servlets ist es echt wenig Schreibaufwand, man kann sich ziemlich gut auf die Businesslogik konzentrieren. Auf jede Frage findet man eine Antwort, für fast alles ein gepflegtes Gem. Wie sich hier Entwicklungsaufwand gegen den Hardwareverbrauch schlägt, würde mich interessieren.

Auch bei C++-Projekten frage ich mich, wie teuer ein Entwickler ist, der wirklich den aktuellsten Sprachstandard, STL und Boost kennt und entsprechend anzuwenden weiß, dass man das letzte dabei rausholt. Angesichts des z.T. sehr schwer zu durchschauenden Code und der etlichen Pitfalls, in die man laufen kann, finde ich C++ gewissermaßen heikel.

Yavion
2013-04-20, 00:59:17
Seit Version 11 hat C++ für mich sehr an Attraktivität gewonnen. Sicher, das meiste gab es schon vorher durch Dinge wie Boost. Aber als jemand, der sich nicht primär damit beschäftigt, geht es eher an einem vorbei, was in irgendwelchen Libs passiert.
Wenn ich mir aber C++ heute ansehe, steht es z.B. C# in der Sachen Ausdrucksstärke nicht mehr viel nach. Ich kann mir gut vorstellen, für zukünftige Projekte eine Kombination aus C++ und Qt einzusetzen, was ich vor 2 Jahren noch für undenkbar hielt.
MS trägt durch seine etwas undurchsichtige Politik leider auch dazu bei: Ich weiss z.B. heute immer noch nicht, ob man WPF bereits abgeschrieben hat oder in wie weit man dort noch Aufwand reinsteckt. Die abnehmende Bedeutung von Windows als alleinige Plattform ist auch ein wichtiger Grund.

Ganon
2013-04-20, 07:44:18
Schon erstaunlich, wie lahm Ruby und Rails gegen die Java-Frameworks sind.

Findest du?

Java ist eine VM in der verdammt viel Forschung und Entwicklung investiert wurde und hat einen verdammt schnellen HotSpot Compiler.

Ruby hingegen ist ein Ein-Mann Projekt (?) mit ein paar Mitentwicklern und ist komplett interpretiert. Dazu ist die Sprache so hochdynamisch, dass man nicht mal groß optimieren, da man jeden Typ zur Laufzeit verändern kann.

Finde ich dementsprechend nicht so erstaunlich, dass Ruby so schnarchlangsam ist.

Marscel
2013-04-20, 15:43:51
Ruby hingegen ist ein Ein-Mann Projekt (?) mit ein paar Mitentwicklern und ist komplett interpretiert.

Ein bisschen optimistischer war ich schon, immerhin gibts Ruby seit 18 Jahren. Ruby hat eine eigene VM (YARV genannt), und angesichts von Rubinius/MacRuby, die nach LLVM kompilieren oder JRuby für die JVM, denke ich, dass es grundsätzlich einigermaßen performant laufen kann. Mit 2.0 soll der GC nochmal optimiert worden sein.

Da rails-jruby ja auch aufgeführt ist und sich nicht allzu viel besser schlägt, rack-jruby allerdings schon, vermute ich, dass Rails die stärkste Bremse ist.

Gast
2013-04-21, 10:57:39
Andererseits ist RoR meiner Ansicht nach recht ungeschlagen, was das Gesamtpaket bezüglich Features betrifft: verglichen mit ASP.NET, purem PHP und Java-Servlets ist es echt wenig Schreibaufwand, man kann sich ziemlich gut auf die Businesslogik konzentrieren. Auf jede Frage findet man eine Antwort, für fast alles ein gepflegtes Gem. Wie sich hier Entwicklungsaufwand gegen den Hardwareverbrauch schlägt, würde mich interessieren.
Bei diesem Vergleich solltest du gegen JEE vergleichen. Kenne RoR nicht im Detail, nur oberflächlich, aber ich glaube nicht, dass da JEE in vielem nachsteht.
Gerade aber vor dem Hintergrund, wieviel Aufwand in JEE und wieviel in RoR steckt, ist das schon ein beeindruckendes Framework, keine Frage.

Marscel
2013-04-22, 01:20:48
Bei diesem Vergleich solltest du gegen JEE vergleichen. Kenne RoR nicht im Detail, nur oberflächlich, aber ich glaube nicht, dass da JEE in vielem nachsteht.
Gerade aber vor dem Hintergrund, wieviel Aufwand in JEE und wieviel in RoR steckt, ist das schon ein beeindruckendes Framework, keine Frage.

Die Enterprise Edition? Sicher ist die und Java nicht ohne, ich hab auch schon zwei Projekte damit machen müssen.

Rails: Man gibt Tabellenattribute an, migriert rein und alles ist angelegt, ich brauch mich nicht um die DB darunter kümmern (zmd. nicht bei gängigen Systemen), objekt-relationaler Mapper macht den Rest, kann man auch hin- und her versionieren. Erstellst mit einer DSL eben ein paar Routen, Rails baut etliche HTTP-Pfade und Actions für mich zusammen. Man legt die Controller an, die eigentlich nur minimalen Schreibaufwand erfordern, tw. sogar generalisier bar i.S.v. REST sind. Authentifizierung? Gem und ein paar Zeilen. Autorisierung? Gem + DSL, die für View-Aktionen selbst die Query vorkonfigurieren kann. Serialisierung? .to_json, .to_xml. Asynchrone Aufgaben? Gem + Redis + ganz paar Zeilen Setup. Testframework für Models, Controller: onboard, Kinderkram.

Hat mit Rails weniger als eher mit Ruby zu tun: Unzählige Helper-Gems, mit dem man eben mal ein Excel/PDF bauen, eben mal Formulare generieren, eben mal Hardcore-XML-Operationen durchführen, eben mal irgendwelche Clouddienste anbinden kann.

So macht Entwickeln für Webdienste eigentlich recht viel Spaß. Bei .NET und Java kann man auch das Assembly/Package hinzufügen, aber wg. starker Typisierung ist das selten "mal eben".

Java ist etwas anstrengend, finde ich (http://de.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition). Dann muss man sich erst wieder in etliche Abstraktionsschichten einarbeiten, evtl. ne Implementierung raussuchen und schon etliche Male hab ich mich beim Betrachten gefragt: "Was macht diese Software jetzt überhaupt?" :D

Aber nochmal zu Ruby, hier (http://blog.clifreeder.com/blog/2013/04/21/ruby-is-too-slow-for-programming-competitions/) im Vergleich zu Go: ja, ok, es ist höllisch lahm. Hatte beim Ausprobieren lokal dann auch keine Lust mehr.

universaL
2013-04-22, 09:15:28
Am Ende läuft es halt drauf hinaus, das richtige Tool für die Aufgabe zu finden. Und in den meisten Fällen wird die "Langsamkeit" von Ruby nicht entscheidend sein. Und wenn man dann beispielsweise rack-jruby und netty anschaut, dann ist es noch ein Faktor 7, aber wahrscheinlich ein ungefähr gleiches Abstraktionslevel.


Aber nochmal zu Ruby, hier im Vergleich zu Go: ja, ok, es ist höllisch lahm. Hatte beim Ausprobieren lokal dann auch keine Lust mehr.


Nachdem der Autor wohl die richtigen Datentypen in Go benutzt, ist es auch nicht mehr so schnell und braucht auch fast 3minuten ;-) Da Ruby "dynamisch die Int-Typen mappt" und keinen Overflow erzeugt, kann es sein das man irgendwann in den Typ für beliebig große Ints hineinläuft. Und der ist zum Beispiel auch in Java ziemlich lahm :-)

creave
2013-04-22, 18:02:10
Das Play framework (auch in den Tests dabei) ist quasi das Java/Scala äquivalent zu Rails, vielleicht wäre das für dich einen Blick wert @ Marcsel. Das Entwickeln geht damit meiner Ansicht nach nochmals komfortabler als mit Rails... getätigte Änderungen im Code greifen sofort, wenn man im Browser F5 drückt (kann sein, dass es in Rails mittlerweile? auch so ist, ich hatte vor einigen Jahren Probleme damit), und Änderungen am Model muss man nicht jedes mal per Befehl in die DB migrieren, sondern man wird im Browser darauf hingewiesen, dass sich das Model verändert hat - per Klick im Browser wird die DB dann on-the-fly angepasst. ORM, Caching, Routing (DSL basiert auf Scala) ist alles an Bord, Testdaten kann man mit YAML beschreiben, zum Entwicklen ist h2 als in-memory SQL-DB mit dabei.

Ansonsten ist das Konzept das gleiche, außer das play intern afaik einen asynchronen, eventbasierten Ansatz verfolgt anstatt dem klassischen one-thread-per-request.

Marscel
2013-04-22, 19:04:17
Das Play framework (auch in den Tests dabei) ist quasi das Java/Scala äquivalent zu Rails, vielleicht wäre das für dich einen Blick wert @ Marcsel. Das Entwickeln geht damit meiner Ansicht nach nochmals komfortabler als mit Rails...

Sieht interessant aus, werd ich mal einen Blick drauf werfen. Vielleicht macht es mit Scala ja mehr Spaß als mit Java.

getätigte Änderungen im Code greifen sofort, wenn man im Browser F5 drückt (kann sein, dass es in Rails mittlerweile? auch so ist, ich hatte vor einigen Jahren Probleme damit), und Änderungen am Model muss man nicht jedes mal per Befehl in die DB migrieren, sondern man wird im Browser darauf hingewiesen, dass sich das Model verändert hat - per Klick im Browser wird die DB dann on-the-fly angepasst.

Hoffentlich aber nicht alles auch im Produktivbetrieb, oder? Im Entwicklungsmodus eigentlich schon, aber der ist dann auch entsprechend langsamer.

Migrations machen aber angesichts von verschiedenen Environments durchaus Sinn und auch beim Deploy will ich das ja gerne automatisiert haben. Unter Rails setzt du dein Deploy-Skript auf, dann wird alles hochgeladen bzw. aus dem Repo synchronisiert, Migrations laufen auf einer Instanz, Assets werden kompiliert/komprimiert und ggf. auf CloudFront o.Ä. hochgeladen. Das muss man sich einmal zusammenkonfigurieren und dann ist das ein Befehl.

creave
2013-04-22, 19:51:58
Ist alles nur zum Entwickeln gedacht. Migrations gibt es natürlich (aka Evolutions), nur sind die zur Entwicklungszeit angenehmer verpackt (http://www.playframework.com/documentation/2.1.1/resources/manual/javaGuide/tutorials/zentasks/images/evolution.png), das db:migrate hatte ich hingegen öfters mal vergessen. Einen großen unterschied macht das natürlich nicht, fiel mir nur gerade so ein.

Frucht-Tiger
2013-04-22, 22:19:37
Das Play Framework unterscheidet sich meiner Meinung nach schon ziemlich von Rails. Die Zielsetzung ist zwar die gleiche, aber statt viel auf Code-Generierung und Mapping zu setzen wie Rails, werden bei Play eher möglichst einfache DSLs in den Vordergrund gerückt. Statts ORM gibt es z.B. Anorm, damit schreibst du dein SQL-Mapping selbst, was aber durch die Möglichkeiten von Scala mit wenig Code über die Bühne geht.

Es "fühlt" sich auch beim Programmieren einfach anders an. Während du bei Rails/Grails oft das Gefühl hast, es funktioniert halt einfach irgendwie so wie du es dir gedacht hast, brauchst du beim Play Framework ein paar kurze, prägnante Zeilen Code, die aber auch genau richtig sein müssen. Interessant ist es auf jeden Fall, aber eher als Alternative zu JEE, beim Prototyping/Rapid Development sehe ich Rails als überlegen an.

creave
2013-04-22, 23:01:24
Habe mich nur oberflächlich damit beschäftigt und kann nicht so tiefgründig berichten, aber der Workflow erinnerte mich schon sehr stark an Rails. Du scheinst Play mit Scala zu nutzen, ich habe das ganze damals mit Java ausprobiert und kam nur bei den Routes und Templates mit Scala als DSL in Berührung. Dieses Anorm kannte ich beispielsweise gar nicht, mit Ebean wird ja ein traditioneller OR-Mapper mitgeliefert, mittels JPA geht problemlos auch Hibernate und Co. Das "prägnant, aber bitte richtig" Gefühl kam bei mir mit Java irgendwie nicht auf, es war schon so "Rails-Laissez-faire", nur irgendwie moderner angehaucht. Das mit dem reduzierten Scaffolding fiel mir auch auf, ansonsten vom Code her quasi identische Models, Controller und Routes wie in Rails. Aber vielleicht sollte ich mich nochmal ausführlicher damit beschäftigen, vor allem wegen Scala.

Wo ich im Nachhinein betrachtet nicht ganz dahinter gestiegen bin ist der non-blocking Ansatz. Man darf ja beim Code, der pro Request sequenziell ausgeführt wird, keinen großen Bockmist bauen, da sonst die gesamte Anwendung blockiert. Auf deren Seite steht das auch mal in irgend einem Tutorial kurz erwähnt mit dem Verweis auf Callback-Funktionalitäten. Trotzdem werden dort in den Code-Beispielen direkt hintereinander fröhlich Daten aus Datenbanken und Caches geladen, die in Wirklichkeit ja auf ganz anderen Maschinen laufen können. Wenn man das mit dem Vert.x Framework vergleicht, dort trauen sich die Autoren nicht mal, einen ganz simplen Request an eine klassische, blockierende DB abzusetzen (z.b. via JDBC), ohne dafür eine Art Worker zu benutzen. Node.js bringt glaube ich gar einen eigenen, nicht-blockierenden Treiber für mysql mit. Warum ist das bei Play irgendwie ein weniger kritisches Thema, oder hab ich da was ganz falsch verstanden?