C++ / Java -> Vergleich

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

[Praktiker]

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)

[quarkmischer]

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

[einlasss]

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.

[Simon2]

Scheppertreiber schrieb:

Mir geht es (teilweise) NUR um die Geschwindigkeit....

Das wird hiermit zusammenhängen:

Scheppertreiber schrieb:

...unserer "Entwicklungsabteilung" (das bin ich)...

Spätestens, wenn Du in einem Team mit >2 Leuten zusammenarbeitest, dominieren andere Aspekte.

Scheppertreiber schrieb:

...
Wenn große Datenmengen (so ab 100 MB aufwärts) en bloc verarbeitet werden spielt das eine große Rolle. ...

Hmmm - stimmt so nicht in der Allgemeinheit.
Ich habe auch schon Programme geschrieben, die Massendaten verarbeiten (die auch GB an Daten verarbeiten) und da war Performance eher untergeordnet.
Sowas arbeitet man sowieso "im Batch" ab und nicht, wenn ein User davorsitzt und wartet.
Wichtiger war dann:
- Datenintegrität (wer will hinterher 2GB Binärdaten nach einem Fehler durchfräsen ?)
- Sync-Point-Schreibung
- Wiederaufsetzbarkeit
- geringer Ressourcenverbrauch (man sollte die Maschine ja auch nicht für andere lahmlegen)
- Einfache Bedienbarkeit (damit jeder Blödel in der Produktion das anwerfen kann) - gerade auch zum Wiederaufsetzen
- ...

Letztlich haben wir es auch (oder sagen wir: Trotzdem) in C programmiert , aber nicht wegen der Performance, sondern einfach weil wir auf einen großen Vorrat an C-Libs zurückgreifen konnten.

Gruß,

Simon2.

[dust]

Letztlich haben wir es auch (oder sagen wir: Trotzdem) in C programmiert , aber nicht wegen der Performance, sondern einfach weil wir auf einen großen Vorrat an C-Libs zurückgreifen konnten.

Soso, wer hätte das gedacht ^^. <- Bitte nicht ernst nehmen.

[Foxx90]

Ich will ja wirklich nicht stören zwischen euren ethischen Religionen (Oh man, genau das will ich doch verhindern), aber nur mal so am Rande, ihr redet fast IMMER von Geschwindigkeit. Bitte lasst den Faktor doch mal weg, was gäbe es dann für GRünde Java nieder zu machen ? Ich mein die gesamte Lib ist doch OpenSource, ok fast. Außerdem um einiges einfacher Plattform unabhänigig zu programmieren als C/C++, selbst wenn man Libs nutzt, kommt man meistens nicht darum rum selber Hand zulegen. So, klar es gibt bestimmt Sachen die kann Java einfach nicht. Hardware nah... Z.B. Laufwerke öffnen... Aber dafür gibt es ja die JNI! Damit sind solche Sachen möglich.

So nun zum großen Mysterium Geschwindigkeit!
Diejenigen die sagen, dass C++ SOVIEL schnneller ist, haben (bitte nicht falsch verstehen, dass is kein Aufruf zum Flamewar oder zum Trollen) einfach nicht sehr viel mit Java gemacht. Es gab eben ein Beispiel: Mit den Dateien die sehr groß sind etc. Kennst du NIO ? Dieses Prinzip basiert auf nativen C++ MEthoden (wenn ich mich nicht irre). Und das verarbeiten der Dateien dürfte (Ok, jenach Anwendung!) bei heutigen Rechnern weniger Rechenzeit in Beschlag nehmen, als 8ms oder vlt sogar 32ms auf die Festplatte zu warten bis die Daten gelesen wurden... Und da ist weder C++ noch Assembler schneller. Klar wenn du ne Datei verschlüsselst mit komplizierten Algorithmen dürfte Assembler bzw C++ dann punktne, weil die dann wirklich schneller sein dürften. Vermutlich sogar spürbar. Aber sowas könnte man ja trotzdem wieder native machen. Also ich denke, dass das kombinieren beider Sprachen der Schritt in die richtige Richtung ist. Deshalb wird C++ vermutlich nie aussterben, aber Java wird garantiert noch viel mehr an Bedeutung zukommen und ich bin mir sicher, dass auch die Spieleindustrie iwann Interesse an Plattformübergreifenden Spielen haben werden. UPS, dann müssten sie aber auf directX von MS$ verzichten. DAs geht natürlich GARNICHT!
Aber falls die Menschheit iwann mal weit genug ist, wäre Java bestimmt eine nette Alternative zur Programmierung von Strategiespielen.

So, das ist so meine Meinung über beide Sprachen, ich finds ansich lustig zu sehen, wie sehr Java teilweise noch "verachtet", wird und als Hype oder Crap abgetan wird. Ohne Libs kämt ihr doch auch in C++ nicht aus. Ohne boost oder wxWidgets ist es doch echt nervig Programme sauber zu erstellen. Ok es gibt natürlich noch die MEGA-PORTABLE WinAPI!!

Und wenn ich mich nicht irre,... ist doch die VM in C++ geschrieben. Ich mein SUN hat allen Leuten damit abgenommen, dafür zu sorgen, dass man auf allen Plattformen zurecht kommt!

ZULETZT noch eine kleines Beispiel aus dem Reallife, wo sich niemand beschweren würde:

ZIEL: Ich wollt ein Baumhaus bauen.

Variante 1: Ihr habt nichts was ihr direkt gebrauchen kkönnt. Sprich ihr habt zwar Baumsamen, und Wasser und Sonnne, aber ihr habt kein fertiges Bäumchen dass ihr fällen könntet, um das Holz zu benutzen.
Genauso bei den Werkzeugen: Ihr habt nur einen Block Roherz. So ihr habt allerdings Feuer und Ahnung über Physik: Trotzdem könnt ihr nicht so einfach Schrauben daraus fertigen, geschweige denn eine Bohrmaschine!

Variante 2: Ihr habt feriges Holz, und einen Akkubohrer und eine Dose Schrauben.
Und das Holz klappt sogar bei jedem WETTER(Plattformen), sprich es quillt nicht, und leitet sogar Blitze ab (Ok, das fiktiv :D). Die Tätigkeit des Hausbauens, wirds dir dadurch nicht abgenommen, aber dennoch wird der Weg dahin vereinfacht, da ihr nicht das Rad nochmal erfinden müsst.

Ich denke mal ihr wisst wofür diese Metaphern stehen...

GRUß der Foxx

[Unregistrierter_Mitleser]

Tachyon schrieb:

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

Also ich finde diese Diskussion hier sehr interessant. Sehr viele Entwickler berichten hier von ihrer täglichen Arbeit. Ich finde das sehr lehrreich. Wirklich. Und ich möchte mich dafür bedanken.

[LOL WTF]

Foxx90 schrieb:

ZIEL: Ich wollt ein Baumhaus bauen.

Variante 1: Ihr habt nichts was ihr direkt gebrauchen kkönnt. Sprich ihr habt zwar Baumsamen, und Wasser und Sonnne, aber ihr habt kein fertiges Bäumchen dass ihr fällen könntet, um das Holz zu benutzen.
Genauso bei den Werkzeugen: Ihr habt nur einen Block Roherz. So ihr habt allerdings Feuer und Ahnung über Physik: Trotzdem könnt ihr nicht so einfach Schrauben daraus fertigen, geschweige denn eine Bohrmaschine!

Variante 2: Ihr habt feriges Holz, und einen Akkubohrer und eine Dose Schrauben.
Und das Holz klappt sogar bei jedem WETTER(Plattformen), sprich es quillt nicht, und leitet sogar Blitze ab (Ok, das fiktiv :D). Die Tätigkeit des Hausbauens, wirds dir dadurch nicht abgenommen, aber dennoch wird der Weg dahin vereinfacht, da ihr nicht das Rad nochmal erfinden müsst.

Ich denke mal ihr wisst wofür diese Metaphern stehen...

Nö. C++ vs. Java kann es nicht sein.

[Foxx90]

Soooo..... ? Dann vergleich mal C++ & Standart Library vs. Java StandartLib
Mir ist schon klar, dass es bei C++ für alles Libraries gibt, aber eben nicht mit der SL... Und wenn doch, bitte klär mich auf!

[zwutz]

Foxx90 schrieb:

ZIEL: Ich wollt ein Baumhaus bauen.

Variante 1: Ihr habt nichts was ihr direkt gebrauchen kkönnt. Sprich ihr habt zwar Baumsamen, und Wasser und Sonnne, aber ihr habt kein fertiges Bäumchen dass ihr fällen könntet, um das Holz zu benutzen.
Genauso bei den Werkzeugen: Ihr habt nur einen Block Roherz. So ihr habt allerdings Feuer und Ahnung über Physik: Trotzdem könnt ihr nicht so einfach Schrauben daraus fertigen, geschweige denn eine Bohrmaschine!

Variante 2: Ihr habt feriges Holz, und einen Akkubohrer und eine Dose Schrauben.
Und das Holz klappt sogar bei jedem WETTER(Plattformen), sprich es quillt nicht, und leitet sogar Blitze ab (Ok, das fiktiv :D). Die Tätigkeit des Hausbauens, wirds dir dadurch nicht abgenommen, aber dennoch wird der Weg dahin vereinfacht, da ihr nicht das Rad nochmal erfinden müsst.

oja... man hat schon eine Bohrmaschine. Allerdings hat die nur einen Bit: den falschen. Die Schrauben ziehen nicht richtig und das Holz ist zwar stabil, sieht aber miserabel aus.
So hat man bei beiden Varianten am Ende nur zwei Möglichkeiten: man fährt in den nächsten Baumarkt oder bestellt nen Handwerker. Nur das bei erster Variante nicht damit geprahlt wird, dass es nicht so sei

[LOL WTF]

Foxx90 schrieb:

Soooo..... ? Dann vergleich mal C++ & stan**** Library vs. Java StandartLib
Mir ist schon klar, dass es bei C++ für alles Libraries gibt, aber eben nicht mit der SL... Und wenn doch, bitte klär mich auf!

Das passt aber garnicht zu deinem Vergleicht. Dein Vergleich war Lochkarten vs. Programmiersprache.

[Foxx90]

Ja, mir ist schon klar, dass mein Vergleich krass war xD zwutz hats auf den Punkt gebracht... Ich mag C++ auch lieber, aber Java ist mindestens genauso gut bis vergleichbar gut... Halt nur auf anderen Gebieten, wo C++ bei Faktor Zeit einbüßungen macht ...

Gruß

[Simon2]

dust schrieb:

Letztlich haben wir es auch (oder sagen wir: Trotzdem) in C programmiert , aber nicht wegen der Performance, sondern einfach weil wir auf einen großen Vorrat an C-Libs zurückgreifen konnten.

Soso, wer hätte das gedacht ^^. <- Bitte nicht ernst nehmen.

Vielleicht wäre es klarer geworden, wenn ich geschrieben hätte "... C-APIs für Hardwaretreiber...".
(Ebenso wesentlicher Faktor war die Tatsache, dass das C-KnowHow in unserer Abteilung weiter verbreitet ist als Java, C++, Cobol, ASM, ... (was auch jeweils ein paar können - aber eben nicht alle)).

Gruß,

Simon2.