JAVA schneller als C++ ? Stimmt das???

Java überzeugt nicht.

Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache des bewährten Weltmarktführers bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.

Die kostet nicht nur nichts, sondern überzeugt auch noch durch einen schnellen Return on Investment durch vorbildliche Sicherheit, Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit, Multiple Inheritance, echte Templates, Template Metaprogramming, Multi-Paradigms, funktionale Aspekte und Kontinuität in der Sprachpolitik.

Und das ist es schliesslich, worauf es Experten wie meinen hochqualifizierten Softwareentwicklern und mir im harten Tagesgeschäft des internationalen Wettbewerbs ankommt.

Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert durch praxisfremde Marketingstrategen mit Zwangs-OOP-Fixierung, hat keinerlei Chance, will man sich tagtäglich aufs Neue den Herausforderungen der Globalisierung und der mit dieser einhergehenden ständig wechselnden Anforderungen an das Entwicklungswerkzeug erfolgreich stellen. Da können einfach nur Lösungen von Profis für Profis zum Einsatz kommen, die hervorragend durch das Stroustrupsche Meisterwerk abgedeckt werden.

Gregor

frenki schrieb:

Java ist für die die einfach schnell und einfach entwickeln wollen und denen die User egal sind.

Das zeigt doch die Diskussion Swing vs. SWT in diesem Thread. Ein Programmierer der solche Entscheidungen aus Sicht der Entwicklung und nicht aus Sicht des Anwenders trifft hat in meinen Augen sowieso den Beruf verfehlt. Für die ist Java genau richtig.

Meine These: Wenn man sich für eine genutzte Bibliothek als Programmierer verstellen muss, weil sie komplett anders als der Rest des Programms funktioniert, werden hiermit auch Bugs verbunden sein, die im Programm entstehen. Aus meiner Sicht ist das also eine Bug-Quelle. Zudem wird das Programm an dieser Stelle schlechter wartbar sein und und und.

Mit andere Worten: Es gibt auch aus Sicht des Nutzers des Programms Gründe, die gegen SWT sprechen. Wenn eine genutzte Bibliothek nicht gut in das Programmiermodell passt, dann wird die Qualität der Software dadurch leiden.

...nur so ne Meinung.

Gregor

rapso schrieb:

java wurde nicht entwickelt um
[...]
3. allround eingesetzt zu werden

Hä? Was glaubst Du, warum Diskussionen wie diese überhaupt entstehen? Weil sich die Anwendungsgebiete von Java und C++ nicht überschneiden? Wahrscheinlich nicht. Die Anwendungsgebiete überschneiden sich in weiten Teilen. Und Java wird in sehr sehr vielen Bereichen eingesetzt (wenn man mal von Treibern absieht). Die Entwicklung von Desktopanwendungen gehört in jedem Fall auch zu den Anwendungsgebieten von Java. Und das ist auch ein Bereich, in dem die Java-Nutzung zunehmen wird.

Es muss endlich mal eine vernünftige Alternative zu Swing entwickelt werden. Swing ist rufschädigend für Java.

hab nur ich das gefühl, oder sind die meisten hier c++ programmierer, die keine arbeit finden, weil auf dem markt nunmal mehr java als c++ programmierer gesucht werden, und deshalb nichts besseres zu tun haben als ihren frust hier rauszulassen indem sie ihr halbes "expertenwissen" propagieren zu versuchen?

gurkenesser schrieb:

hab nur ich das gefühl, oder sind die meisten hier c++ programmierer, die keine arbeit finden, weil auf dem markt nunmal mehr java als c++ programmierer gesucht werden, und deshalb nichts besseres zu tun haben als ihren frust hier rauszulassen indem sie ihr halbes "expertenwissen" propagieren zu versuchen?

Bloß kein Neid. f'`8k

Bye, TGGC

gurkenesser schrieb:

hab nur ich das gefühl, oder sind die meisten hier c++ programmierer, die keine arbeit finden, weil auf dem markt nunmal mehr java als c++ programmierer gesucht werden, und deshalb nichts besseres zu tun haben als ihren frust hier rauszulassen indem sie ihr halbes "expertenwissen" propagieren zu versuchen?

hehe, kommt mir auch so vor :0)

Hmm, schlagt mich aber ich denke das mit den JAVA Jobs hängt mit dem Anstieg der Web- und Mobilprojekte zusammen. C++ wird halt mehr für den Rest eingesetzt, diese Menge wächs nicht so stark an wie Handy und Web und daher werden nicht weniger C++ Jobs angeboten als früher.

groovemaster

Gregor schrieb:

Dennoch ist es so, dass die JVM als zwischengeschaltete Maschine in der Praxis kein wirklicher Performancefaktor ist. In der Theorie kannst Du Überlegungen in beide Richtungen anstellen. Da kann man sich gedanklich sowohl Vorteile als auch Nachteile der JVM konstruieren, keine Frage. Wenn die JVM wirklich ein derartiger Performancekiller wäre, wie man es nach deinem Beitrag hätte denken können

Deshalb habe ich ja von Anfang an geschrieben, dass Theorie und Praxis sich nicht überdecken. Vermutlich habe ich unterschätzt, dass einige Leute (Grüsse an Opti ) das falsch verstehen. Ich selbst glaube auch, dass in einer VM (nicht nur bezogen auf Java) viel Potenzial steckt. Und dass diesen vermutlich in weiten Bereichen der Softwareentwicklung die Zukunft gehört. Ich habe nur manchmal das Gefühl, dass einige JVM Verfechter glauben, dass es nur eine Frage der Zeit ist, bis die komplette Softwarewelt Java spricht. Das wird aber nicht passieren. Schon deshalb nicht, weil es nicht nur Web-Applikationen gibt oder GUI Anwendungen mit Klicki-Bunti Interface.

Optimizer schrieb:

Ok, wir sind uns einig, betrachten wir das von der theoretischen Seite. Dann erklär jetzt nochmal genau, wie JIT-Compilierung die Performance negativ beeinflusst.

Das ist 'ne ganz einfache Rechnung.

x + y + z = e1 // c++
w + x + y + z = e2 // java

x ist die Laufzeit des Programmstarts, also das, was noch vor main passiert. y ist die Laufzeit des Rumpfprogrammes, also alles in main. Und z das Programmende, also alles nach main. Bei Java kommt noch w hinzu, die JIT Kompilierung. Jetzt stellen wir die Formeln entsprechend um, und verbinden sie zu einer. Dabei erhalten wir:

e1 = e2 - w

Und wenn wir natürlich davon ausgehen, dass alle Werte weder negativ noch null sind, bedeutet das

e1 < e2

Wie gesagt, das ist vollkomem praxisfern. So sieht aber nunmal verallgemeinert die Theorie aus.

Optimizer schrieb:

Konstanter Aufwand ist theoretisch völlig bedeutungslos.

Praktisch, nicht theoretisch.

Optimizer schrieb:

Die besagt, dass nur 20% des Codes eines Programms für die Performance von Bedeutung sind.

Das kann dann aber sicherlich keine allgemeingültige Regel sein. Immerhin gibt es nicht immer GUI. Mittlerweile kaum noch, aber während meiner Ausbildung hatte ich zB sehr viel mit Automatisierungstechnik zu tun. Und dort sind 100% der Anwendung Performance relevant. Dieses läuft zyklisch, und wenn die CPU es nicht schnell genug verarbeiten kann, wird die Taktzeit zu hoch und ist damit unbrauchbar. Weil dann zB Signale zu lange brauchen, bis sie geschaltet werden. Oder geschaltete Eingänge erst zu spät "registriert" werden. Und GUI gibts da nicht. Wenn überhaupt, dann als separates Panel über eine externe Schnittstelle.

Optimizer schrieb:

Nein. Er kennt sie nicht gut genug.

Lassen wir es besser sein. Zuerst kennt er sie gar nicht. Jetzt nicht gut genug. Was kommt wohl als nächstes?

Optimizer schrieb:

Ich habe doch vom Inlining gesprochen.

Ich aber nicht. Punkt. Zumal dein Beispiel mit dynamischen Bibliotheken schon ein konretes Anwendungsszenario beschreibt. Hat also bei einer allgemeinen theoretischen Betrachtung nix verloren.

Optimizer schrieb:

Der Punkt war: Man fasst in der Regel zusammen, was man kann. Man compiliert nicht für Pentium I, II, III, IV, 4 D (mit x64) mal Windows 9x, NT, Linux, macht insgesamt 15 Compilate ohne AMD. Zeig mir eine ernstgemeinte Software, für die es so viele Compilate gibt. Nein, man macht ne x86 Version, die ist dann schlecht optimiert, weil sie auf die gemeinsame Schnittmenge der Prozessoren aufbauen muss. Da liegen dann viele Möglichkeiten brach.

Du machst dir das zu einfach. Sicherlich ist die Möglichkeit, eine CPU durch die JIT Kompilierung besser auszunutzen, gegeben. Aber ähnliche Möglichkeiten hat man bei C++ ja auch. Das muss ja nicht immer nur bei der Kompilierung selbst passieren. Man kann auch zur Laufzeit die Fähigkeiten einer CPU auslesen. Und dann zB einen Funktionszeiger entsprechend umbiegen. Und wie gesagt, verschiedene Kompilate für verschiedene Prozessoren würde ich nicht als "exotisch" bezeichnen. In dem Ausmasz, wie du es übertrieben konstruiert hast, natürlich nicht.

Optimizer schrieb:

Wieso nicht? Weil der Compiler vor dem Programmstart ins Spiel kommt. Ist doch ganz klar!

Ach, tatsächlich? Gut das wir mal darüber geredet haben. Aber was die Vorteile nun sind, hast du mir immer noch nicht erklärt. Sofern ich dich richtig verstehe, profitiert davon ja nur die Runtime, aber nicht der main Teil.

Optimizer schrieb:

Beispielsweise ich lade ne DLL hinzu, die kommt an irgendne Basisadresse im Textsegment. Jetzt rufe ich darin ne Funktion auf. Mein Programm wurde jetzt aber schon compiliert, also muss es die Adresse der Funktion ausrechnen, Basisadresse + Funktionsoffset. Bei JIT-linking wüsste ich nach der JIT-compilierung, wo die Funktion der DLL im Speicher steht und kann während der JIT-compilierung meines Codes direkt die Adresse eintragen.

Naja, ganz so einfach ist es natürlich nicht. Du musst, zumindest bei C++ Anwendungen, immer noch zwischen Load- und Runtime Linking unterscheiden. Bei Load-Time Linking wird im Grunde das gleiche gemacht, wie bei der JIT Kompilierung. Die "richtigen" Adressen werden erst zur Laufzeit, also beim Beginn der Anwendung, in den Code eingefügt. Und bei Runtime Linking wüsste ich jetzt nicht, was eine VM da besser machen könnte. Zumindest nicht, wenn die Maxime gelten soll, dass nur einmal zu Beginn der Anwendung die JIT Kompilieirung erfolgen soll und somit keinen negativen Einfluss auf die Laufzeit des eigentlichen Programmes haben soll.

Optimizer schrieb:

Ich bin der Anfang (und das Ende).

Manchmal habe ich echt das Gefühl, _du_ bist zwar nicht Deutschland, aber zumindest TGGC.

Optimizer schrieb:

Ich habe es doch begründet.

Du hast zwar einige Detailbeispiele aufgezählt, die sich im Rahmen des Threads natürlich mit der Performance befassen. Aber dass JIT Kompilierung "insgesamt völlig überlegen" ist, ist für mich damit noch lange nicht begründet. Was nicht heissen soll, dass ich dir widersprechen will. Ich habe nur was dagegen, wenn Leute solche Propagandasprüche zum Besten geben, ohne dafür eine einleuchtende und vor allem ausreichende Erklärung zu liefern.

Optimizer schrieb:

Das Problem ist: Du hast deine Aussage über Langsamkeit explizit mit dem Interpretieren begründet.

Was, wie ich dir oben bewiesen habe, im gesteckten Rahmen auch logisch sein sollte. Dass das mit der Praxis nix zu tun hat, habe ich ja nun auch schon mehrfach erwähnt. Und wenn dich das Wort stört, dann denk dir halt einfach JIT Kompilierung.

rapso

Gregor schrieb:

rapso schrieb:

welche sprache außer java generiert denn noch bytecode für den JIT ?

Was erwartest Du denn da? Keine? Da ist ne Liste mit über 200 entsprechenden Sprachen und Sprachvarianten: http://www.robert-tolksdorf.de/vmlanguages.html

das allermeiste sind scheinbar tools, keine sprachen.

Gregor schrieb:

rapso schrieb:

mal ganz ehrlich. wenn man ein "perfektes" programm für sich haben möchte, stellt man nen hochqualifizierten coder ein und lässt es ihn in c++ machen und zahlt entsprechend (weil man etwas gutes haben möchte und für soviel geld dann auch verlangen darf dass es kein speicherfresser ist). wenn man ein "perfektes" programm für den markt haben möchte, weil es irgendjemand benutzen soll der dafür geld ausgibt, dann stellt man sich zwei studenten/praktikanten ein und lässt sie es in java/c# schreiben und spart geld und kann sich sicher sein, dass das programm, egal wie es laufen wird, wohl keine accessviolations werfen wird (weil man $$$ machen möchte)

Naja, wer will schon ein "perfektes Programm" haben? ...und welches Programm ist schon perfekt, egal in welcher Sprache es geschrieben ist?

schön dass du das "-zeichen nicht verstanden hast, aber eben das sollte es implizieren.

Gregor schrieb:

In der Wirtschaft gibt es immer Grenzen bezüglich des Budgets, der Zeit usw.. Niemand ist da bereit, für etwas perfektes zu zahlen.

natürlich ist man das, es hängt nur von der firma ab, nicht umsonst gibt es mathematische analysemethoden für software mit der du mathematisch nachweisen kannst, dass ein ausdruck, eine funktion, ein programm usw. fehlerfrei ist. du kannst davon ausgehen, dass raketentriebwerke mit einer so getesteten/berechneten software laufen.
große firmen die software für eigene zwecke erstellen legen auch sehr viel mehr wert auf die qualität, als firmen die software verkaufen. das ist auch logisch, bei verkauf-software ist es das ziel damit geld zu verdienen, dass die software raus ist und solange du keine grobe/fahrlässige fehler hast, ist es erstmal egal, hauptsache der kunde hat bezahlt (bestes beispiel ist zZ photoshop, das in der neusten version derart schlecht ist, dass man damit absolut nicht proffesionell arbeiten kann). auf der anderen seite hast du die intern genutzte software, jeder fehler darin hat für das ende der produktion viel weitreichendere folgen, z.b. falsches runden von zahlen bei einer fräsemaschine. das ist deswegen oft derart wichtig, dass obwohl es die benötigte software schon gibt, die firmen ihre eigene schreiben mit eigener QA dafür.

Gregor schrieb:

Und man sollte auch nicht vergessen: Wenn man für ein gegebenes Projekt eine feste Zeit zur Verfügung hat und dieses Projekt mit Java schneller entwickeln könnte, bleibt einem mit Java auch mehr Zeit zum Debuggen und zur Optimierung.

das ist richtig für applikationen die schnell mal gemacht werden müssen bis zu einem termin. aber es gibt auch software bei der es andere zielsetzungen gibt wie eben z.b. performance und da erlaubt dir java an vielen stellen überhaupt nicht einzugreifen, man muss auf das generische system hoffen, und hoffen dass die optimierung die man vielleicht macht, dann auch in den nächsten versionen des JIT so interpretiert werden. ich kann beim programmieren mit c für ne arm cpu festlegen welche dinge im cache/scratchpad sein sollen und welches allignment benutzt werden soll, ich kann mir die adresse von gewissen teilen des speichers besorgen und die auf einer x86 cpu in den cache "pingen" wie es vom memorycontroller her optimal ist.
das kann ich mit java nicht, aber java wurde ja auch nicht für diese performancesachen gemacht.

Gregor schrieb:

Abgesehen davon stellst Du es so dar, als ob man für Java nur unqualifiziertes Personal nehmen würde, für C++ aber die höchstausgebildeten Leute. Hier möchte ich doch nochmal auf die üblichen Jobstatistiken verweisen. Da stehen nämlich auch immer die durchschnittlich gezahlten Gehälter dabei. Und die sind in vergleichbaren Regionen. IMHO gibt es bei Java-Jobs sogar etwas mehr zu verdienen, als bei C++. In jedem Fall ist daraus nicht zu erkennen, dass Java vor allem in Verbindung mit Studentenjobs genutzt wird.

es geht nicht um die gehälter der fertigstudierten-vollverdiener. es geht darum, dass es sehr viele firmen gibt, die mit java (und früher VB) applikationen entwickeln lassen, die keine vollprofis benötigen. so gibt es dann viele praktikaten, auszubildene usw. die mit VB/Java/etc programme für den markt schreiben, weil man es ihnen numal zutraut, eher als dass die einfach software mit c++ schreiben können.
um es klarzustellen: ich sage nicht, dass alle java-programmierer idioten sind, sondern dass man "idioten" lieber java gibt um ein produkt zu programmieren als c++, bzw. würde man alternativ einen erfahrenen programmierer mti c++ software erstellen lassen und den "idioten" erstmal voll ausbilden bevor er mit c++ software machen darf die man ihm schon lange mit java zutrauen würde.

und in zukunft wird es weiter in die richtung gehen, dass man einerseits programmierer "entmündigt" und durch sehr viel vorgefertigtes die arbeit abnimmt. aber das ist auch klar, rechner sind 100mal schneller als vor 8 jahren, die gleiche software muss aber nicht 100mal schneller laufen. was macht man also mit der ganzen leistung? man tauscht sie gegen entwicklungsgeschwindigkeit. wo jemand früher also nen monat an einem programm schreiben mußte, darf er nun in einer woche ein ebenbürtiges programm entwickeln... und das war eben mit ein ziel von java. ich weiß nicht, was daran schlimm sein sollte.
das ist doch überall so
- motoren verbrauchen die hälfte gegenüber früher -> fahrzeuge wiegen das doppelte.
- akkues haben doppelte kapazität -> handys/notebooks usw. verbrauchen das doppelte
- graphikkarten haben zigfache leistung -> spiele haben gleiche fps, dafür bessere graphik

DEvent

Ich habe den Thread jetzt ziemlich genau vefolgt und ist echt interessant bis jetzt. Aber groovemaster, du langweilst langsam. Du trollst jetzt einfach nur rum.
Optimizer hat etliche sehr gute Argumente genannt wieso ein JIT besser optimieren könnte als es ein C++ Compiler je kann.

x + y + z = e1 // c++
w + x + y + z = e2 // java

tolle Rechnung
Ich würde die Rechung eher so schreiben:
x1 + y1 + z1 = e1 // c++
w + x2 + y2 + z2 = e2
denn weder x, y noch z sind bei C++ und Java gleich.

Ein JIT kennt einfach das System auf dem das Programm läuft zu 100%. Wärend man bei C++ doch nur fürn x beliebigen x86 compiliert. Ausserdem kennt der JIT alles von dem Code. Egal ob es dein Programm ist oder Librarys von Marsmännchen. Somit kann er nun das komplette Programm genauestens optimieren. Wärend der C++ Compiler das Programm nur für einen Standard x86 optimiert und die fremd-Libs nicht anfassen kann.

Ausserdem ist die JIT Compelierung in O(n) also in konstanter Zeit, also völlig und total vernachlässigbar.

rapso schrieb:

Gregor schrieb:

rapso schrieb:

welche sprache außer java generiert denn noch bytecode für den JIT ?

Was erwartest Du denn da? Keine? Da ist ne Liste mit über 200 entsprechenden Sprachen und Sprachvarianten: http://www.robert-tolksdorf.de/vmlanguages.html

das allermeiste sind scheinbar tools, keine sprachen.

lol o.O
- eine programmiersprache generiert gar nix
- bytecode generieren tun compiler
- compiler sind tools
- auf der verlinkten seite werden compiler (tools) aufgelistet, die aus bestehenden und neuen sprachen java bytecode generieren

du weißt was 'scheinbar' bedeutet

mfg

DEvent

große firmen die software für eigene zwecke erstellen legen auch sehr viel mehr wert auf die qualität, als firmen die software verkaufen. das ist auch logisch, bei verkauf-software ist es das ziel damit geld zu verdienen, dass die software raus ist und solange du keine grobe/fahrlässige fehler hast, ist es erstmal egal, hauptsache der kunde hat bezahlt (bestes beispiel ist zZ photoshop, das in der neusten version derart schlecht ist, dass man damit absolut nicht proffesionell arbeiten kann). auf der anderen seite hast du die intern genutzte software, jeder fehler darin hat für das ende der produktion viel weitreichendere folgen, z.b. falsches runden von zahlen bei einer fräsemaschine. das ist deswegen oft derart wichtig, dass obwohl es die benötigte software schon gibt, die firmen ihre eigene schreiben mit eigener QA dafür.

Was hat das mit Java zu tun ? Rechnet Java falsch oder rundet es falsch ?
Ich würde sagen daduch, das man die Speicherverwaltung Profis überlässt, die Tagein Tagaus nichts anderes machen als den GC zu optimieren, sorgt man dafür das die Software sicherer ist.
Ein C++ Programmierer muss sich sorgen machen über die normale Implementation der Algorithmen und um die Speicherverwaltung. Bei Java und C# hat man es getrennt: Ein Spezialist arbeitet an der Speicherverwaltung, ein anderer an den Algorithmen.
Ausserdem ist es durch den wegfall der Zeiger eher sicherer :p

ich kann beim programmieren mit c für ne arm cpu festlegen welche dinge im cache/scratchpad sein sollen und welches allignment benutzt werden soll, ich kann mir die adresse von gewissen teilen des speichers besorgen und die auf einer x86 cpu in den cache "pingen" wie es vom memorycontroller her optimal ist.

Das ist genau das was der JIT und die Hot-Technologie macht. Wenn es sich lohnt kann der JIT den Code genau auf sowas optimieren und zwar zur Laufzeit des Programmes.

Jester

DEvent schrieb:

Ausserdem ist die JIT Compelierung in O(n) also in konstanter Zeit, also völlig und total vernachlässigbar.

Ja was denn nun? O(n) oder konstant?

*rofl*

DEvent

Jester schrieb:

DEvent schrieb:

Ausserdem ist die JIT Compelierung in O(n) also in konstanter Zeit, also völlig und total vernachlässigbar.

Ja was denn nun? O(n) oder konstant?

Ahh stimmt. Ich meinte linear. Linearer Zeitaufwand ist aber genauso vernachlässigbar.

P = NP!!!!!!!!!!!!!!!!111111111111111 (O(n!) ist vernachlässigbar)

DEvent

Die Mods sollten den Thread in die FAQ reinstellen

net 0

DEvent schrieb:

Die Mods sollten den Thread in die FAQ reinstellen

java vs. c++ threads gibts doch viele hier und immer füllen sie mehrere seiten...

Gregor

@rapso: Ok, habe deinen Beitrag vorhin wohl etwas falsch interpretiert. Mit deiner Erklärung bin ich mehr oder weniger einverstanden.

Bei den aufgelisteten Sprachen gibt es sicherlich auch noch ne ganze Menge anderes Zeug drin, keine Frage. Allerdings sind auch einige interessante Sprachen/Compiler enthalten, die Bytecode produzieren.

Man braucht aber letztendlich sowieso nur ganz wenige Sprachen. Ich habe noch nie etwas anderes als Java verwendet, um Code für die JVM zu produzieren. Nicht weil es nichts anderes gäbe, sondern weil der diesbezügliche Bedarf einfach nicht da ist. Interessant könnten zum Beispiel Sprachen wie "Groovy" sein. Auch irgendwelche Javavarianten von Prolog oder Lisp könnten für mich irgendwann interessant werden. Aber die meisten Sprachen bieten eigentlich nichts, was mich dazu bringen würde, sie in diesem Umfeld einzusetzen.