C, C++ oder Java??

[WoSoft]

Wenn du zirkulare Referenzierung bei dei der Implementierung vom GC draußen lässt, kannste gleich Reference Counting machen.

Und wenn du Objective-C nimmst (immerhin die Muttersprache von OS X), dann ist das bereits eingebaut und nimmst du die Komfortinitialisierer, arbeitet es sogar automatisch.

 

[Sym]

@blutfink:
wo bitte habe ich gesagt, dass es sich nur um einen Algorithmus gehandelt hat? Es wurden viele verschiedene getestet und Java war in knapp 1/5 der Fälle schneller.

Die Laufzeitumgebung verhält sich anders. Und mit C++ kann man zwar versuchen, Java-Programme zu imitieren, verhält sich das Programm zur Laufzeit anders.

Und gerade Sortierprogramme bekommt man ziemlich gut mit Java hin. Was es doch langsam macht, ist der Interpreter zur Laufzeit. Wenn aber alle Klassen im Speicher vorhanden sind, ist das nicht mehr wichtig.

Und um es mit Deinen Worten zu sagen: Ich kann es nicht fassen, dass Du mir vorwirfst, es nur an einem Beispiel getestet zu haben und dann selber anhand eines Falkutätsalgos das Gegenteil beweisen willst.

Auch wenn oftmals C++ schneller ist (C ist im Grunde sogar schneller als C++), wird an Java stark entwickelt. Java wird immer schneller - leider jedoch nicht bei der Mac-Umsetzung, denn die läßt wirklich zu wünschen übrig.

 

[glotis]

programmiert man auch hier die Laufzeitoptimierungen nach. Natürlich stiege damit der Entwicklungsaufwand, aber das ist hier nicht der Punkt.

Sollte es jemanden interessieren, ich könnte mir z.B. mal ein Sortierproblem ausdenken und würde einen Kasten Bier drauf wetten.

Oder es biete doch bitte mal einer eine Java-Implementation hiervon:
https://www.macuser.de/forum/showthread.php?t=43182
(siehe Beiträge 13 bzw. 55)

Hi
du denkst dir ein Sortierproblem aus? ein ganz neues? und ein Algo dazu?
dann hast du dir den Kasten Bier verdient!
Die Kosten eines Algos werden normalerweise unabhängig von Programmiersprache und Hardware und OS betrachtet.
Und wenn man die Wahl der Programmiersprache auf Kosten des Entwicklungsaufwandes vorzieht, sagt das alles.
Vielleicht sollte man doch mal mehr projektbezogen denken, denn es gibt ein Nebeneinander der Programmiersprachen und nicht ein Ausschliessen.

 

[blutfink]

Hi
du denkst dir ein Sortierproblem aus? ein ganz neues? und ein Algo dazu?
dann hast du dir den Kasten Bier verdient!

Davon hat niemand geredet. Es geht nur darum, dem Rechner was zu tun zu geben. Dafür reicht ein sinnfreier Bubblesort. Dazu würde ich vielleicht ein paar äußere Anforderungen an die Implementierung vorgeben (Zahlen in Klassen gekapselt, Sortieralgorithmus unabhängig vom zu sortierenden Datentyp gehalten und noch ein paar andere Kleinigkeiten).

Die Kosten eines Algos werden normalerweise unabhängig von Programmiersprache und Hardware und OS betrachtet.

Richtig. Nur reden wir hier nicht von Laufzeitbetrachtungen von Algorithmen. Wir reden hier von Performancevergleichen konkreter Implementationen in Java und C++.

Und wenn man die Wahl der Programmiersprache auf Kosten des Entwicklungsaufwandes vorzieht, sagt das alles.

Was sagt das denn alles? Dass man höhere Performance u.U. gern mit höherem Aufwand erkauft? Das ist legitim. Sei froh, dass dein iTunes die MP3s mithilfe wochenlang optimierter AltiVec-Implementationen erzeugt.

Vielleicht sollte man doch mal mehr projektbezogen denken, denn es gibt ein Nebeneinander der Programmiersprachen und nicht ein Ausschliessen.

Absolut. Aber wer hat das Gegenteil behauptet? Und in Projekten, wo es nicht auf Performance ankommt, kann Java (oder sogar noch etwas "langsameres") die beste Wahl sein.

Wir redeten hier aber von der Frage, ob "Java schneller ist als C++". Ich fände es schade, wenn Leute performancekritische Anwendungen schreiben wollen und durch Lesen des Forums hier den Eindruck bekämen, mit Java wären sie da auf der sicheren Seite.

 

[blutfink]

@blutfink:
wo bitte habe ich gesagt, dass es sich nur um einen Algorithmus gehandelt hat? Es wurden viele verschiedene getestet und Java war in knapp 1/5 der Fälle schneller.
[...]
Und um es mit Deinen Worten zu sagen: Ich kann es nicht fassen, dass Du mir vorwirfst, es nur an einem Beispiel getestet zu haben und dann selber anhand eines Falkutätsalgos das Gegenteil beweisen willst.

Vielleicht habe ich micht nicht so verständlich ausgedrückt. Meine Aussage ("eine beliebige Java-Implementation kann immer durch eine C++-Implementation geschlagen werden") stünde auch, wenn du es an tausend Algorithmen ausprobiert hättest. Solange die C++-Versionen nicht vernünftig optimiert sind, ist eure Messung nicht so interessant für die Wahl der Sprache bei performancekritischen Anwendungen.

Bei meinem Beispiel (Fakultätsberechnung) hingegen steht die Optimierung der Java-Variante offen. Du kannst optimieren, wie du willst, du wirst die Performance mit Java nicht erreichen, und zwar nicht mal entfernt. Das ist schonmal eine Aussage, findest du nicht?

Und gerade Sortierprogramme bekommt man ziemlich gut mit Java hin. Was es doch langsam macht, ist der Interpreter zur Laufzeit. Wenn aber alle Klassen im Speicher vorhanden sind, ist das nicht mehr wichtig.

Ich verstehe nicht, was du damit meinst.

Auch wenn oftmals C++ schneller ist (C ist im Grunde sogar schneller als C++) [...]

Kann man übrigens auch nicht so einfach sagen. Z.B. das oben skizzierte Sortierproblem ist ein typisches Gegenbeispiel (C kann keine Templates und kann daher die Vergleichsoperationen nicht inlinen). C++ enthält außerdem C, das heißt man kann zumindest immer gleichziehen.

 

[-Nuke-]

Das "Problem" bei Java ist ja die nicht veränderbare Prozessor-Unabhängigkeit.

Wenn ich ein schnelles Programm brauche (für einen bestimmten Fall), dann kann ich mir bei C/C++ z.B. einen Compiler von IBM kaufen und habe vielleicht so schon 50% mehr Performance. Dann kann ich noch die Prozessor-Erweiterungen ansprechen, wie Altivec, welches vielleicht noch mal 300% Leistung bringt. Dann kann ich mit C++ schon an sich über 300% schneller sein als Java, denn bei Java bin ich der VM ausgeliefert.

OK. Der Fall oben ist sehr speziell. Es ist auch so, das man unter Umständen bei Java leichter Probleme lösen kann, als in C++ mit der selben Performance wie in Java.

Aber jetzt generell zu sagen: "Java ist an manchen Stellen schneller als C++" halte ich für Käse. Der damalige Test in der c't, wo Java gewonnen hatte, hatte auch so viele Fehler auf Seiten von C++, dass die c't aufgrund der vielen "Leser-Tipps" das Ergebnis wieder umdrehen konnten. Mit Hilfe der "Leser-Optimierungen", war Delphi und C++ weitaus schneller als Java, statt anders herum. Das ging damals auch durch viele Internet-Foren.

In den Fällen wo Java schneller ist, liegt es nicht an der Sprache, sondern eher daran das ein anderer, besserer Algorithmus angewendet wird (pow, sin, cos, etc.), welcher in C++ erst noch umgesetzt werden muss, oder eine andere Bibliothek gebraucht wird, als die STL.

Wie gesagt. Der große Vorteil von C++ ist nunmal der Compiler und dessen Optimierung...

Ich will hier Java nicht schlecht machen. Die plattformunabhängige Idee von Java ist toll. Aber die Geschwindigkeit von Java hochzuloben, ist imo falsch. Denn da gibt es auch andere Sprachen, die noch schneller sind als Java mit ihren Standard-Funktionen. Z.B. ist Python in Berechnungen weitaus schneller als Java.

Um zum Punkt zu kommen:
Java mag in einigen Fällen schneller sein, als in jenem Fall C++. Also z.B. den Kosinus des Sinus von 2^32 ausrechnen. Da mag bei den Standard-Befehlen Java schneller sein.
Bei Java ist die Geschwindigkeit aber festgelegt. Bei C++ kann ich andere Compiler, CPU-Erweiterungen oder schnellere Bibliotheken nutzen um das Blatt komplett zu wenden. Jetzt mal als Beispiel.

Java hat viele Vorteile. Besonders das All-In-One-Paket. Aber die Geschwindigkeit ist kein Vorteil.

 

[Sym]

Vielleicht habe ich micht nicht so verständlich ausgedrückt. Meine Aussage ("eine beliebige Java-Implementation kann immer durch eine C++-Implementation geschlagen werden") stünde auch, wenn du es an tausend Algorithmen ausprobiert hättest. Solange die C++-Versionen nicht vernünftig optimiert sind, ist eure Messung nicht so interessant für die Wahl der Sprache bei performancekritischen Anwendungen.

Bei meinem Beispiel (Fakultätsberechnung) hingegen steht die Optimierung der Java-Variante offen. Du kannst optimieren, wie du willst, du wirst die Performance mit Java nicht erreichen, und zwar nicht mal entfernt. Das ist schonmal eine Aussage, findest du nicht?

Oh man, natürlich kann man C++-Code auf die CPU trimmen. Aber auch das geht nicht immer. Bei den Tests wurde viel getüftelt und gemacht - ist ja nicht umsonst die BV-Forschungsabteilung.
Wenn Du für eine Bildberechnung aber mit C++ dann 15 Min brauchst und unter Java nur 13, ist Java schneller. Das das nicht prinzipiell so ist, stimmt wohl. Aber manchmal geht es doch.
Und die Fakultät zu berechnen ist ein sehr kleiner Algorithmus. Das man da Hardwarenahe programmieren kann und nicht 2 GB Speicher braucht, ist wohl klar. Bei größeren Dingen braucht es dies teilweise aber schon. Es ist auch immer eine Aufwandsgröße dabei. Wenn ich StandardC++ programmiere und halt Java ist Java nicht unbedingt langsamer. Wenn ich auf Quick'n'Dirty gehe, gibt es sicher Performanzpunkte (heißt ja nicht umsonst so), aber das halt zulasten des Aufwands und der Lesbarkeit.

Kann man übrigens auch nicht so einfach sagen. Z.B. das oben skizzierte Sortierproblem ist ein typisches Gegenbeispiel (C kann keine Templates und kann daher die Vergleichsoperationen nicht inlinen). C++ enthält außerdem C, das heißt man kann zumindest immer gleichziehen.

Aha, hier erkennst Du an, dass C++ manchmal schneller ist? Trotzdem ist es im Allgemeinen so, dass OOP ein wenig langsamer und speicherfressender ist. Und... manchmal (oder auch öfter) ist C++ schneller.
Und nur weil Du C Code nutzen kannst, kannst Du noch lange nicht gleich ziehen. Nutzt Du nämlich keine Klassen und nur C-Code, ist es kein C++-Programm mehr.

Ich will hier aber nun wirklich nicht weiter machen. Jeder hat seine Erfahrungen gemacht und für mich ist Java eine elegante Lösung. Einfach, Plattformunabhängig, wenig Fehleranfällig, Packagestruktur. Es gibt sogar schon native-Compiler und seid Java 1.5 sind sogar eine Abart von Templates dabei.

 

[Sym]

Das "Problem" bei Java ist ja die nicht veränderbare Prozessor-Unabhängigkeit.

Das ist nicht ganz richtig. Der übersetzte Code kann auf jeder JVM interpretiert werden (was nicht mehr so an der Geschwindigkeit zieht). Die JVM selber ist für jede CPU zugeschnitten und verwendet Teile automatisch. Das auf dem Mac Altivec vielleicht nicht unterstützt wird, ist pech, aber auf einer Sun hingt C++ oftmals Java hinterher.

Wenn ich ein schnelles Programm brauche (für einen bestimmten Fall), dann kann ich mir bei C/C++ z.B. einen Compiler von IBM kaufen und habe vielleicht so schon 50% mehr Performance. Dann kann ich noch die Prozessor-Erweiterungen ansprechen, wie Altivec, welches vielleicht noch mal 300% Leistung bringt. Dann kann ich mit C++ schon an sich über 300% schneller sein als Java, denn bei Java bin ich der VM ausgeliefert.

Wie ich oben erwähnt hat, ist jede JVM auf die CPU zugeschnitten (soweit es derzeit geht, denn da wird ja dran entwickelt).

Aber jetzt generell zu sagen: "Java ist an manchen Stellen schneller als C++" halte ich für Käse. Der damalige Test in der c't, wo Java gewonnen hatte, hatte auch so viele Fehler auf Seiten von C++, dass die c't aufgrund der vielen "Leser-Tipps" das Ergebnis wieder umdrehen konnten. Mit Hilfe der "Leser-Optimierungen", war Delphi und C++ weitaus schneller als Java, statt anders herum. Das ging damals auch durch viele Internet-Foren.

Es ist nunmal schwer, die Sprachen auf deren Performanz zu vergleichen. Ich sage auch nicht prinzipiell, das Java schneller ist. Es nur nicht mehr haltbar, dass Java immer langsamer ist. Es hat sich sehr viel da getan.

In den Fällen wo Java schneller ist, liegt es nicht an der Sprache, sondern eher daran das ein anderer, besserer Algorithmus angewendet wird (pow, sin, cos, etc.), welcher in C++ erst noch umgesetzt werden muss, oder eine andere Bibliothek gebraucht wird, als die STL.

Nicht unbedingt. Für Standardoperationen muss man nicht mehr an C++ herumschrauben, um besonders hardwarenahe zu sein. Diese sind teilweise in Java besser in der JVM!! umgesetzt.

Wie gesagt. Der große Vorteil von C++ ist nunmal der Compiler und dessen Optimierung...

Nope, denn jede JVM ist auf die CPU optimiert. Bei der OSX-Portierung (an der Apple mit fuhrwerkelt) kann man leider nicht wirklich von Optimierung sprechen.

Um zum Punkt zu kommen:
Java mag in einigen Fällen schneller sein, als in jenem Fall C++. Also z.B. den Kosinus des Sinus von 2^32 ausrechnen. Da mag bei den Standard-Befehlen Java schneller sein.
Bei Java ist die Geschwindigkeit aber festgelegt. Bei C++ kann ich andere Compiler, CPU-Erweiterungen oder schnellere Bibliotheken nutzen um das Blatt komplett zu wenden. Jetzt mal als Beispiel.

Naja, einfach so einen neuen Compiler nehmen, klappt wohl nicht. Ich glaube, hier denken einige, dass die JVM auch plattformunabhängig ist, aber dem ist nicht so.

Java hat viele Vorteile. Besonders das All-In-One-Paket. Aber die Geschwindigkeit ist kein Vorteil.

Dem kann ich so Zustimmen. Ein Vorteil ist die Performanz bestimmt nicht.

So, das wars aber nun wirklich von mir...

 

[glotis]

Hi
ok reflektieren wir mal kurz, unser Ausgangsposter(Neuling) will eine Programmiersprache lernen und Webapplikationen schreiben und liest hier im Forum: Java ist langsam, 10000 langsamer, Java ist zum kotzen, Java ist Marketing...
Fürs Web nehmen wir sowieso php und mysql.
Ausserdem lernt er das c und c++ einfacher und viel schneller zu programmieren sind und objC eh die Haussprache von OSX ist und für performance- und sicherheit-kritische Anwendungen nehmen wir optimiertes C++.

Naja, ich würde glatt behaupten er hat alles falsch verstanden
Wenn ich performance- und sicherheit-kritische Anwendungen im Web schreiben will dann kann man nur Java empfehlen und J2ee vielleicht mit einem Web-Framework(Turbine, Struts,Cocoon).Da ist er sehr schnell am Ziel. Das ganze auf einem Java-Applikation-Server und dann will ich den Performance Test sehen der mit C,C++ oder Php besser ist.
Der Aufwand um sich als Neuling einzuarbeiten, um C-Code auf dem Server laufen zu lassen der nicht nach 10 Sekunden gehackt ist, ist sehr hoch. Wenn man aber unbedingt will kann man ja immer noch eine Kosten-Nutzenrechnung machen und ein Performance-Vergleich bei den rechenintensiven Code und diesen in C++ realisieren, aber im Web wird es nicht auf die Millisekunden ankommen. Da dürfte nicht viel rum kommen, selbst bei deiner Fakultätsberechnung zumal es für einen Neuling bestimmt nicht leicht wird C++ zu optimieren.

 

[Sym]

...viel Text...

Da stimme ich Dir voll und ganz zu.

 

[-Nuke-]

Nope, denn jede JVM ist auf die CPU optimiert. Bei der OSX-Portierung (an der Apple mit fuhrwerkelt) kann man leider nicht wirklich von Optimierung sprechen.

Naja. So wie ich das sehe, gibt es keine VMs direkt für die einzelnen Prozessoren, wie Pentium4, AthlonXP, G4 oder G5.

Also ich sehe da keine direkte Prozessor-Optimierung. Klar das die VM da nicht 3-Stufig arbeitet, also Umsetzung->Umwandlung(x86,ppc,sparc)->Ausführung, sondern Umsetzung->Ausführung.

Aber egal... Solange Java im grafischen Bereich nicht massiv an Geschwindigkeit zulegt, findet es bei mir keine Anwendung. Da gibt es besseres.

 

[Sym]

Naja. So wie ich das sehe, gibt es keine VMs direkt für die einzelnen Prozessoren, wie Pentium4, AthlonXP, G4 oder G5.

Also ich sehe da keine direkte Prozessor-Optimierung. Klar das die VM da nicht 3-Stufig arbeitet, also Umsetzung->Umwandlung(x86,ppc,sparc)->Ausführung, sondern Umsetzung->Ausführung.

Aber egal... Solange Java im grafischen Bereich nicht massiv an Geschwindigkeit zulegt, findet es bei mir keine Anwendung. Da gibt es besseres.

Jupp, Du hast auch recht. Ich habe vorhin wohl auch ein bisschen Banane gedacht. Die JVM's haben eher eine verschiedene Architekturunterstützung als eine CPU-Unterstützung.
Und da es keine feste C++GUI gibt, sondern nur die verschiedenen Libraries ist Java da nun mal unvergleichlich gut. Im ernst: Der Swingteil von Java ist nun wirklich langsam (auch wenn es besser wird). SWT ist hingegen schon wesentlich besser (und wrappt meines Wissens auf C++Klassen).

 

[snady]

Diese freie Wahl habe ich nur privat, um mich dann i.d.R. für Cocoa/Objective-C zu entscheiden. Dienstlich gibt der Projektleiter vor, welche Klassen mit welchen Methoden ich in welcher Sprache zu schreiben habe.

Ja, das kenne ich auch von meinem Job her,..
Aber an der Uni ist man ( bei uns ) mit Java König. Da hier in den Einführungsveranstaltungen Java gelehrt wird, setzt man es auch in vielen Projekten ein. Und da macht Softwareentwicklung einfach mehr Spaß wenn man ordentlich voran kommt.

Grüße Sebastian

 

[WoSoft]

Ja, das kenne ich auch von meinem Job her,..
Aber an der Uni ist man ( bei uns ) mit Java König. Da hier in den Einführungsveranstaltungen Java gelehrt wird, setzt man es auch in vielen Projekten ein. Und da macht Softwareentwicklung einfach mehr Spaß wenn man ordentlich voran kommt.

Grüße Sebastian

Kommt wohl sehr auf die Uni an. Als ich studiert habe (schon ne Weile her), erzählte man uns erst, C sei die Mutter aller Sprachen, und dann hatte ich einen Prof. (Wettstein), der war erklärter C-Gegner und zog deshalb alle Vorlesungen "Architektur von Betriebssystemen" in Modula 2 durch.
Kleiner Gag: Er konnte sagenhaft schnell Code an die Tafel malen und dabei vertat er sich etwas und machte eine Schleife mit while auf und mit until zu. Als ich das zaghaft nachfragte, blaffte er mich an: Die Kleinigkeit werden Sie in Ihrem Compiler wohl noch ändern können.

 

[Sym]

Kommt wohl sehr auf die Uni an. Als ich studiert habe (schon ne Weile her), erzählte man uns erst, C sei die Mutter aller Sprachen, und dann hatte ich einen Prof. (Wettstein), der war erklärter C-Gegner und zog deshalb alle Vorlesungen "Architektur von Betriebssystemen" in Modula 2 durch.
Kleiner Gag: Er konnte sagenhaft schnell Code an die Tafel malen und dabei vertat er sich etwas und machte eine Schleife mit while auf und mit until zu. Als ich das zaghaft nachfragte, blaffte er mich an: Die Kleinigkeit werden Sie in Ihrem Compiler wohl noch ändern können.

Es kommt auch darauf an, wie lange Du schon von der Uni fern bist. Solange gibt es ein vernünftiges Java nun auch nicht. Bei uns wird es seid knapp 5 Jahren wirklich gelehrt.

 

[snady]

Kommt wohl sehr auf die Uni an. Als ich studiert habe (schon ne Weile her), erzählte man uns erst, C sei die Mutter aller Sprachen

Ja, da hast du recht. Ein Kollege Studiert an einer anderen Uni, und dort bekommen die Studies erst mal was von C++ erzählt.
Aber wahrscheinlich ist auch wichtig "wann" man Studiert,.. vielleicht finden die ja demnächst alle C# ganz toll ( oder irgendwas anderes ).

Grüße Sebastian

PS: Aber ich glaube die erste Sprache die man lernt prägt einen schon etwas.

 

[Diskordia]

@Sym
Zur Frage ob ich Java Professionel benutze:
Ich studiere Informationstechnologie in einer FH, bei uns wird hauptsächlich Java verwendet.

Wieso hässlich:
Swing benutzt nicht immer die schönen Systemwickets sondern bringt eigene Graphiken mit. SWT benutzt die Windowing-GUI-Elemente vom System, d.h. Mit SWT hast du immer eine native GUI!

Wiso SWT nicht langsam ist:
Da SWT das systemeigene Windowing benutzt, werden vorkompilierte Elemente benutzt, die ans jeweilige System angepasst sind. Wenn du SWT als langsam betrachtest, dann must du auch Cocoa als langsam betrachten, weil schlussendlich die gleichen Bibliotheken verwendet werden!

GruZZ Diskordia

 

[Sym]

@Sym
Zur Frage ob ich Java Professionel benutze:
Ich studiere Informationstechnologie in einer FH, bei uns wird hauptsächlich Java verwendet.

Wieso hässlich:
Swing benutzt nicht immer die schönen Systemwickets sondern bringt eigene Graphiken mit. SWT benutzt die Windowing-GUI-Elemente vom System, d.h. Mit SWT hast du immer eine native GUI!

Wiso SWT nicht langsam ist:
Da SWT das systemeigene Windowing benutzt, werden vorkompilierte Elemente benutzt, die ans jeweilige System angepasst sind. Wenn du SWT als langsam betrachtest, dann must du auch Cocoa als langsam betrachten, weil schlussendlich die gleichen Bibliotheken verwendet werden!

GruZZ Diskordia

Hi,

ich habe jetzt noch einmal nachgesehen. Wo habe ich behauptet, das SWT langsam ist? Ich habe nur geschrieben, dass Swing nicht der Geschwindigkeitbringer und SWT da halt besser ist. Gegen SWT habe ich mich definitv nicht ausgesprochen, da ich davon vieles gut finde.

Und mit SWT hast Du mW immer nur die GUI, die Du dabei auch nutzt. Es gibt dort doch auch verschiedene Bibliotheken, die Du nutzen kannst, oder?

Swing sind bei mir auf dem Mac aus, wie ein Mac-Programm und unter Windows, wie ein Windows Programm. Ich finde, besser könnte es nicht aussehen.

Ich verstehe nicht ganz, was Du hier meinst, denn so wie Du das schlilderst, habe ich das definitiv nicht gesagt (weil ich es nämlich ganz anders sehe). Oder meintest Du gar nicht mich?