Die Frage die euch bleibt...

[Trockenobst]

nightfury schrieb:
--------------------------------------------------------------------------------
> gleiche App 150% Rechenaufwand wie unter C. Und das war ein grandioses
> Ergebnis...

Es ist doch nicht der absolute Wert oder der optimale Wert relevant. Vergleichen wir doch mal eine Swing-App mit einem C++ geschrieben App mit Gui die dazu auf fünf Plattformen laufen soll, dann sind wir bei 10x oder 20x der Entwicklungszeit gegenüber Java.

Mehr Entwickler sind ungefähr 10000x teurer als ein weiter CPU-Kern. Moores Law gilt - mit Abschlägen - auch für Mobile Geräte. Somit sind mir 150% lieber als 50.000€ für einen zweiten Mann. Dir vielleicht nicht, aber dann hast Du die 50.000€ übrig.

> Aber sicher doch. Solche Aussagen sind dermaßen weit entfernt von jeglicher
> rationalen Bewertbarkeit.

C++ ist in diesem Vergleich die Spitze (letzte Seite)
https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

Mit einer Einschränkung: "However, it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer."

Das ist der Punkt. Den Speed kriegt man, wenn man bereit ist Goldbarren zu werfen. Denn die Leute die das können findet man mit der Lupe.

Java ist in der Praxis *schnell* genug. Und auch schnell in der Entwicklung. Ich bin mir sicher, ich finde irgendwo einen ASM-Spezialisten für moderne X64 Architektur der jeden C++ Benchmark handgetuned schlagen kann.

Toll, dann hat man ein doofes Argument mit einer sehr spezifischen Betrachtung gewonnen. Aber den Krieg? Nicht mal im Ansatz.

> Nimmt man mal sowas wie JDownloader und Borland Together, dann fragt man
> sich wirklich wofür da CPU und RAM verbraten werden.

Borland *und* Together als Beispiel zu bringen - das wäre wie Windows XP ungepatcht als Beispiel zu nehmen und dann zu behaupten, es war nicht
Microsoft die Mist entwickelt haben, sondern das lag 100% an C++. Together war schon immer Bloatware und wird das bleiben. Das wäre es aber auch in C++ gewesen.

Ich könnte z.B. Fragen warum OpenOffice, dass in C++ geschrieben ist, z.T. bis zu drei Minuten braucht 1000 Seiten HTML Code zu importieren. Das müsste ja in C++ rasend schnell gehen. Meine eigene HTML->ODF Routine in Java dagegen (Kundenauftrag) schafft dass in weniger als 30 Sekunden. Es ist deswegen so *absurd* solche Vergleiche zu machen.

JDownloader zieht gerade mit 3mb/s vom Linuxserver. Und braucht auf einem AMD FX-6200 einen Core zu 5% Prozessorpower. Was ist daran jetzt lahm? Das die Gui sich etwas zäh anfühlt liegt an der Wahl des GUI-Frameworks und der Programmierung, nicht an Java.

Im weltweiten Banking werden Swing-Anwendungen benutzt um Realtime Kurse zu managen. Ich habe an Logistikanwendungen in Swing gearbeitet, die Realtime an 10.000ende verschiedene Lastwägen, Busse und Zugbewegungen angezeigt haben, und das via OpenGL mit rasender Geschwindigkeit auf einem (starken) Standard-PC. Whats slow, please?

Die Masse kann sich nicht irren. Und das sind meist Kapitalisten, die wollen Geld verdienen. Die haben sich schon richtig Entschieden. Nicht das ich C++ nicht selbst ab- und zu verwende. Hammer und Nagel und so. Aber deswegen Mühe ich mich (und bezahlt mich auch niemand) dafür, x% schneller in künstlichen Benchmarks zu sein.



1 mal bearbeitet, zuletzt am 17.11.12 03:09 durch Trockenobst.

[chrulri]

Schön zusammengefasst!

[ImBackAlive]

niw8 schrieb:
--------------------------------------------------------------------------------
> Das VMs an der Perfomance drehen, erst recht "erheblich", ist ein Märchen.
Aber Java tut es ;)

Na, mal im Ernst:
Es wird halt eine zusätzliche Schicht gebildet, die dann durchaus für Performanceverluste sorgt. Nun ist es zwar bei Java mittlerweile soweit, dass das ganz gut wegoptimiert wurde (gerade bei der Dalvik dürfte es doch sehr gut damit aussehen), aber einen Unterschied merkst du schon.
Wenn du VMs meinst, die beispielsweise im ESXi laufen, dann hast du sicherlich Recht. Das liegt aber vor Allem daran, dass durch das OS eine Schicht weniger gebildet (i.e. Userland) wird.

Zusätzlich hast du beim Java natürlich häufig noch den Interpreter-Overhead. Den darf man nicht vergessen.



2 mal bearbeitet, zuletzt am 19.11.12 11:47 durch ImBackAlive.

[ImBackAlive]

ZetaGlm schrieb:
--------------------------------------------------------------------------------
> Wie währe es mit IL-2 Sturmovik, Minecraft oder Apache Tomcat?
Ersteres kenne ich jetzt nicht richtig (ist glaube ich auch ein Spiel?), aber die Performance von Minecraft als "gut" zu bezeichnen ist schon etwas an der Realität vorbei. Gemessen an dem, was dort gemacht wird, werden die Ressourcen schon übel verbraten.
Mhm - Apache Tomcat, das ist jetzt natürlich recht schwierig zu beurteilen, da das doch sehr, sehr stark von den installierten Applikationen abhängt. Auf meinem Server braucht Tomcat auch gut und gerne 800-900MB RAM, obwohl die entsprechenden Einstellungen doch recht niedrig gesetzt sind (MaxHeapspace bspws. lediglich bei 256MB). Und das ist der Fall, wenn ich die dahinterliegende Applikation (Subsonic) nicht einmal benutze.


> Die reine Rechenperformance von Javaprogrammen ist nicht schlecht.
> Hier ist eine Seite, welche Algoritmen in verschiedenen Programmiersprachen
> implementiert und anschließend die Performance verlgleicht:
> shootout.alioth.debian.org
Prinzipiell hast du ja Recht, und es ist eben auch so, dass Java grundsätzlich durchaus performant arbeiten kann. Das hat dein Vorposter auch nicht bestritten, er sagt lediglich, dass er kein performantes Programm _kennt_.
Das mag vielfach auch daran liegen, dass wohl gerade "moderne" Entwickler in Java arbeiten. Ich kenne das selber: Als angehender Entwickler wird einem vielfach gar nicht mehr beigebracht, was Speicherverwaltung bedeutet, wie man Ressourcen schonend arbeitet, etc. - da fehlt einfach ein großer Klotz.
Klar - Java ist halt auch recht "einfach" zu erlernen und gut geeignet als Start, es macht aber in meinen Augen oftmals einen extremen Unterschied, wo der jeweilige Entwickler begonnen hat.
M.E. sollten Entwickler wieder mit Assembly anfangen, eventuell mit C, schlicht um die Grundlagen der Programmierung zu lernen. Um zu lernen wie eine CPU eigentlich funktioniert, was der RAM eigentlich macht, wie man effektiv arbeiten kann, ...

Vielfach tippe ich jedoch eher auf den Kostenfaktor - C/C++-Programm-Tuning kann mitunter sehr, sehr viel Zeit in Anspruch nehmen. Abgesehen davon, dass vielen für das spezielle Feintuning das Know-How fehlt und sich diejenigen, die es dann haben, entsprechend teuer bezahlen lassen.



2 mal bearbeitet, zuletzt am 19.11.12 12:03 durch ImBackAlive.