C++ / Java -> Vergleich

drakon

Scheppertreiber schrieb:

Java ist Hype, auch der durchschnittliche BWLer kriegt das noch zum Laufen.

Wenn es extrem in die Performance geht, so richtig laufzeitoptimiert, wird es
nicht die erste Wahl sein.

Man muß das abwägen - Performance oder einfach mal schnell ein Programm erstellen.
Beides hat seine Berechtigung.

Das ist ein wenig unfair gegenüber Java. Java ist mer als Hype. Man kann auch vieles in Java machen, aber wenn es wirklich um jeden Takt geht, wie Computerspiele, dann hast du recht, ist es nicht die erste Wahl. Und wenn es nicht ähnlich optimiert gebraucht wird, hat aber Java dennoch eine Berechtigung.

dust

Trollo, sagst ich hab keine Ahnung und stimmst dann zu, wie low ist das denn? Wie man todeslangsam auslegt ist jawohl jedem selbst überlassen, und für mich sind deine "kleinen Faktoren" schon todeslangsam. Und dass Java theoretisch schneller sein kann hat den Humbuck-Of-The-Year-Award verdient. Kein Kommentar mehr ...

asc

dust schrieb:

Und das Java theoretisch schneller sein kann hat den Humbuck-Of-The-Year-Award verdient.

Das ist nicht nur reine Theorie, sondern ist Tatsache. Die Frage ist aber nicht ob es möglich ist, sondern ob es sich in der Praxis tatsächlich bemerkbar macht (und da es meist ein Sonderfall darstellt, wird man es über den Programmablauf in der Regel nicht mitbekommen). Das Prinzip hierbei ist ähnlich wie bei C#:

Ein Programm was mit C++ geschrieben und compiliert ist, kann nicht auf jedes Rechnerdetail hin optimiert sein (oder man schränkt sich mit der Plattform sehr stark ein). Zudem gibt es bestimmte Optimierungen die auf ein konkretes Laufzeitverhalten basieren. In beiden Fällen kann die VM/der Just-In-Time Compiler tatsächlich in Bereichen schnelleren Code erzeugen. Das wirkt sich in der Regel aber erst merkbar aus, wenn dieser Programmcode sehr häufig aufgerufen wird (Hier verlasse ich die Java-Theorien, und wende mich C# zu, da ich mich hier besser auskenne).

Bei C# wird zum Beispiel jeder Codebestandteil beim ersten Aufruf compiliert und für jeden weiteren Aufruf wird dieser Compilierte Abschnitt wiederverwendet. Da hierbei tatsächlich auf die konkrete CPU etc. optimiert werden kann ist es so das der Code schneller sein kann. Da beim ersten Aufruf aber mehr Zeit nötig ist, rentiert sich dies aber wie gesagt nur bei einem mehrfachen Aufruf des Codes.

So... man kann ja gerne alles als nonsense abtun, aber besser wäre es sich hier zu informieren. Und auch wenn es hier anders aussehen mag: Ich bin kein Java-Fan - ich habe nur etwas gegen die Gerüchte die sich seit anfang über Java halten, obwohl Java sich sehr stark weiterentwickelt hat. Ich bin aber nicht Betriebsblind und klammere mich nur an eine Sprache, und in jeder Sprache gibt es etwas gutes (Es gibt durchaus Gründe für die Sprachvielfallt), aber keine Sprache ist die Antwort auf alles... den das wäre 42

cu André

man sollte aber seine GUIs nicht mit Swing machen. Deren implementation von einem EventHandler sieht in etwa so aus:

handle(){ sleep(250); /* ms */ handleTheEvent(); }

@ java kritiker:

Sag mal, kennst du JNI ?? WEnn ja dann würdest du wissen, dass java nicht direkt C++ ausschliesst

Eine andere Frage: Angenommen ich erstelle ein Projekt mit NetBeans auf der "Designer"-Oberfläche... Dürfte ich für ein solches Programm Geld verlangen ? Sprich kein OpenSource etc... ?

Gruß ::WissensHungriger::

Entschuldigung javakritiker, ich meine natürlich Scheppertreiber

ERGO-> Ein gesunder Mix aus beiden ist denke ich absolut genial.
Denn java ist vlt in manchen Gebieten langsamer, aber es bietet geniale Vorteile.

@Javakritiker: Ich nehme mal an du weißt nicht warum Swing langsamer ist nichtwar ?
Swing wird von Java selbst "gemalt" und ist auch vollständig ist Java implementiert, dafür garantiert es auf ALLEN Java-unterstützen Plattformen das selbe LookAndFeel. Java hat definitiv seine Berechtigung. Genauso wie C++. Wenn C++ das Map aller Dinge wäre gäbe es keine anderen Sprachen!!

Die Sache ist doch so:
Wenn es nicht auf Speed ankommt, kann ich mir ne ganze Reihe Programmiersprachen vorstellen, die ich lieber als Java hätte.

Wie ich schon anfangs sagte, wenn jemand was gegen den Speed sagt, MACHT Beispiele! Trolleri ist hier nicht erwünscht... Ich brauche handfeste Informationen!

asc schrieb:

dust schrieb:

Und das Java theoretisch schneller sein kann hat den Humbuck-Of-The-Year-Award verdient.

Das ist nicht nur reine Theorie, sondern ist Tatsache. Die Frage ist aber nicht ob es möglich ist, sondern ob es sich in der Praxis tatsächlich bemerkbar macht (und da es meist ein Sonderfall darstellt, wird man es über den Programmablauf in der Regel nicht mitbekommen). Das Prinzip hierbei ist ähnlich wie bei C#:

Ein Programm was mit C++ geschrieben und compiliert ist, kann nicht auf jedes Rechnerdetail hin optimiert sein (oder man schränkt sich mit der Plattform sehr stark ein). Zudem gibt es bestimmte Optimierungen die auf ein konkretes Laufzeitverhalten basieren. In beiden Fällen kann die VM/der Just-In-Time Compiler tatsächlich in Bereichen schnelleren Code erzeugen. Das wirkt sich in der Regel aber erst merkbar aus, wenn dieser Programmcode sehr häufig aufgerufen wird (Hier verlasse ich die Java-Theorien, und wende mich C# zu, da ich mich hier besser auskenne).

Bei C# wird zum Beispiel jeder Codebestandteil beim ersten Aufruf compiliert und für jeden weiteren Aufruf wird dieser Compilierte Abschnitt wiederverwendet. Da hierbei tatsächlich auf die konkrete CPU etc. optimiert werden kann ist es so das der Code schneller sein kann. Da beim ersten Aufruf aber mehr Zeit nötig ist, rentiert sich dies aber wie gesagt nur bei einem mehrfachen Aufruf des Codes.

was auch wieder so nicht stimmt, denn java speichert nicht nach jedem programm-aufruf eine neue, optimiertere version des programms ab,

THEORETISCH ist es möglich, das java ZUR LAUFZEIT optimiert, was ich aber
heutzutage für völligen quatsch halte, kmail zu kompilieren zB dauert 10 mal länger als das programm im durchschnitt läuft, und da soll mir einer erzählen, er könne all die optimierungen während der laufzeit machen

das ist einfach quatsch und nur theoretisches rumgeblabber

dust

rrrrichtig ... @Ersteller .. wie gesagt, du kannst dir jedes beliebige Beispiel aussuchen ..

Simon2

Jau und wieder wird die "Performance-Sau" durchs Dorf getrieben ... damit man schön ignorieren kann, dass in >90% der Fälle ganz andere Kriterien ausschlaggebend sind.
So Sachen wie:
- welches Know-how ist verfügbar (was hilft's, wenn Du der Einzige im Projektteam bist, der die Sprache kann) ?
- Was wird auf der Zielplattform / der bisherigen Entwicklungsumgebung besser unterstützt ?
- In welcher Sprache ist bereits Code vorhanden (nur in seltenen Fällen fängt man auf "der grünen Wiese" an) ? Wofür gibt's bereits Libs ?
- Was gefällt dem Management gerade am Besten ?
- ...

All das macht bereits 80% der Entscheidung aus ... da spielen die tatsächlichen Sprachspezifika kaum noch eine Rolle (und erst Recht nicht, was Profis aus der jeweiligen Sprache rausholen könnten).

Oder warum läuft heutzutage noch soviel Cobol-Code ?

Gruß,

Simon2.

dust

Hat niemand was Anderes behauptet ..

Simon2

dust schrieb:

Hat niemand was Anderes behauptet ..

Also einer von uns ist blind ... ich sehe hier auf 3 Threadseiten seeeeehr oft die Worte "Geschwindigkeit" "schneller", "langsamer", "Performance", ....

Selbst hinter den Aussagen wie "Je nachdem, welche besser passt" kommt danach noch "... und wie wichtig Geschwindigkeit ist".
Mag sein, dass Du meine Ansicht teilst, aber dass hier nicht über "Performance" gestritten wird (bzw. dieser Aspekt als wesentliches Kriterium auftaucht), kann doch auch Dir nicht entgangen sein...

Gruß,

Simon2.

Scheppertreiber

Mir geht es (teilweise) NUR um die Geschwindigkeit. Wenn große Datenmengen (so ab
100 MB aufwärts) en bloc verarbeitet werden spielt das eine große Rolle. Da ist
hangestricktes C (abgesehen von Assembler) die erste Wahl und nicht zu toppen.

Bei einem reinen GUI-Programm, das eh 99% auf den "Klick" wartet, isses wurscht.

In unserer "Entwicklungsabteilung" (das bin ich) ist da auch einiges an Tools und
Know-How vorhanden. Spielt natürlich auch eine große Rolle. Mir fehlt auch die
Zeit um mich in Java etc. mal richtig reinzuwühlen. Die Notwendigkeit, das zu tun,
besteht mE auch nicht unmittelbar. Alter Wein neuen Schläuchen ...

asc

Praktiker schrieb:

was auch wieder so nicht stimmt, denn java speichert nicht nach jedem programm-aufruf eine neue, optimiertere version des programms ab,

THEORETISCH ist es möglich, das java ZUR LAUFZEIT optimiert, was ich aber...

http://de.wikipedia.org/wiki/Hotspot-Optimierung
(Siehe auch http://de.wikipedia.org/wiki/Dynamische_Optimierung )

Die Java VM von Sun verwendet dies verfahren wohl seit Java 1.3, und seither wurde es weiter optimiert.

Praktiker schrieb:

das ist einfach quatsch und nur theoretisches rumgeblabber

Es gibt auch einige Studien hierzu, wobei ich nicht alles glaube was darin steht (siehe z.B. den sehr schlecht gemachten c't Vergleich vor einigen Jahren der auf pure Unkenntnis von C++ zurückzuführen war).

Das in der Regel C++ schneller ist, habe ich nie wiedersprochen. Nur hierbei handelt es sich nicht um pure Theorie. Und es ist natürlich auch vom Anwendungsfall abhängig.

asc schrieb:

Praktiker schrieb:

was auch wieder so nicht stimmt, denn java speichert nicht nach jedem programm-aufruf eine neue, optimiertere version des programms ab,

THEORETISCH ist es möglich, das java ZUR LAUFZEIT optimiert, was ich aber...

http://de.wikipedia.org/wiki/Hotspot-Optimierung
(Siehe auch http://de.wikipedia.org/wiki/Dynamische_Optimierung )

Die Java VM von Sun verwendet dies verfahren wohl seit Java 1.3, und seither wurde es weiter optimiert.

Praktiker schrieb:

das ist einfach quatsch und nur theoretisches rumgeblabber

Es gibt auch einige Studien hierzu, wobei ich nicht alles glaube was darin steht (siehe z.B. den sehr schlecht gemachten c't Vergleich vor einigen Jahren der auf pure Unkenntnis von C++ zurückzuführen war).

Das in der Regel C++ schneller ist, habe ich nie wiedersprochen. Nur hierbei handelt es sich nicht um pure Theorie. Und es ist natürlich auch vom Anwendungsfall abhängig.

ich wollte auch eigentlich darauf hinaus,
das es mehr rechenzeit braucht, ein programm zu optimieren, als das
programm dann im durchschnitt läuft, also ist der ansatz, im allgemeinen!!!,
schon blödsinn ...

das einzige was helfen würde, wäre sowas wie
: erste programmlauf -> 50% optimiert, optimierte version speichern
: zweiter programmlauf -> optimierte version laden, weiteroptimieren ->75%

so wie java das zur zeit umsetzt, bringt es ja nur was, wenn das programm dann
auch monate läuft ..., und dann kann ich auch c//c++ speziell für
die platform kompilieren, also alles etwas sinnfrei

und meiner meinung nach, kommt es bei jeder anwendung irgendwann dazu,
das man auch mal mit datenmengen von 100MB umgehen muss,
(ich sollte zB mal in java sowas wie einen bildbetrachter schreiben,
als aber der GC irgendwie nicht damit klarkam, das man 10MB
bilder, wenn sie gesehen wurden, nicht mehr im speicher braucht,
bin ich auf Qt umgestiegen (2 Wochen entwicklungszeit für die java version verschwendet ...),
Lösung in Java wäre son Quatsch wie "GC mit Mausklick aufrufen" wenn nötig gewesen
)

es ist nunmal so :
ist ein c++ programm zu langsam, fängt man an zu optimieren

ist ein java-programm zu langsam, dann wartet man auf ne neue jvm, oder dreht däumchen,
oder schreibt es nochmal in c++

(wenn die verwendeten algorithmen nicht schuld sind)

Praktiker du weißt schon das es einfacher ist bytecode zu kompilieren statt C++ zu parsen und zu kompilieren oder?

Tachyon

Boa ey, ich kann, zumindest bei den Registrierten, echt nicht glauben, dass sie sich tatsächlich mal wieder auf so eine Diskussion einlassen...

Praktiker schrieb:

so wie java das zur zeit umsetzt, bringt es ja nur was, wenn das programm dann
auch monate läuft ...

Machen Serveranwendungen auch

und meiner meinung nach, kommt es bei jeder anwendung irgendwann dazu,
das man auch mal mit datenmengen von 100MB umgehen muss,
(ich sollte zB mal in java sowas wie einen bildbetrachter schreiben,
als aber der GC irgendwie nicht damit klarkam, das man 10MB
bilder, wenn sie gesehen wurden, nicht mehr im speicher braucht,
bin ich auf Qt umgestiegen (2 Wochen entwicklungszeit für die java version verschwendet ...),
Lösung in Java wäre son Quatsch wie "GC mit Mausklick aufrufen" wenn nötig gewesen
)

Ja, für Desktopanwendungen mit großen Datenmengen und schwankendem Speicherverbrauch ist Java nicht wirklich geeignet, weil auch die JVM den Speicher nur ungern wieder ans System abgibt.

es ist nunmal so :
ist ein c++ programm zu langsam, fängt man an zu optimieren

ist ein java-programm zu langsam, dann wartet man auf ne neue jvm, oder dreht däumchen,
oder schreibt es nochmal in c++

(wenn die verwendeten algorithmen nicht schuld sind)

In den meisten Fällen sind es aber die Algorithmen oder das Design was die Performance bremst.

C++ / Java -&gt; Vergleich

C++ / Java -> Vergleich