Warum Java vom Prinzip her schneller als C++?

SIDEX

bitte schön:

http://www.galileocomputing.de/openbook/javainsel/java-03.htm#Xxx279093

aber krieg keine überdosis

JBeni

Warum sollte man eine Sprache ablehnen, nur weil sie nicht wie C/C++ ist?

Das frag nicht mich! Ich kenne jedenfalls mehr als einen Programmierer die bei allem was kein "C" im Namen hat rot sieht (und das sind keine Anfänger). Woher das kommt... wüsste ich auch gerne.

Ein Programm, dass auf einmal und ohne brauchbare Kontrolle des Benutzers große Mengen Rechenleistung anfordert, kann nicht Problem des Betriebsystems sein.

Ok, hier sollte man differenzieren: wenn mehrere Programme laufen und eines klaut den anderen Rechenzeit, dann ist das OS schlecht (*hüstel* kann man immerwieder schön bei Windows beobachten...).
Wenn es programmintern abläuft, ists natürlich was anderes.

Auch das Java-Programm kann für zeitkritische Anwendungen verantwortlich sein.

Hm, mal ein bisschen rumgegoogelt. Da gibt es doch das ein oder andere Projekt das sich genau mit diesem Problem befasst. Wieweit die Page Marketingeblubber ist, und wieviel davon echt ist, weiss ich aber nicht.

JBeni schrieb:

Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...

Warum? Reden ist Silber, Schweigen ist Gold?

Das System ist IMHO der grösste Nachteil der JVM, deshalb schweige ich.

Bei einer nicht geringen Zahl von Programmen würden die temporären Speicherlecks nichtmals den Speicherverbrauch der JVM erreichen, würden also unterm Strich trotz Speicherverschwendung speichersparender arbeiten als das entsprechende fehlerfreie Java-Programm.

Naja, das OS ist auch so eine Art VM. Von daher benötigen heutige Programme von Grund auf ~300 MB RAM

JBeni schrieb:

Von der Anwenderseite lohnt es sich, wenn man Dualboot hat (Ok, das war jetzt ein schwaches Argument, fast niemand benutzt sowas).

95% der Linux-Anwender? Ich habe auch noch eine Windows-Version, wenn auch fast nur zum Spielen, wenn ich mal dazu komme.

95% * (10% Systeme die überhaupt Linux haben) * (10% Die dieselbe Software auf beiden Systemen benötigen) = verschwindend gering

JBeni schrieb:

Dann benötigt man noch jemanden der die verschiedenen Frameworks gut genug kennt.

Stimmt. Aber wo ist das Problem - weigern sich Programmierer bzgl. GUI-Frameworks dazuzulernen?

Hoffentlich nicht *g*. Aber man kann ein Framework nicht in einem Tag kennen lernen. Wenn dann Wochen auf kennen lernen + coden + debuggen + etc. draufgeht ist das nicht so dolle.

C++ achtet sehr auf Kompatiblität zu Vorgängerversionen. Es reicht trotzdem nicht. Ich hatte letztes Jahr eine nette Diskussion mit jemanden, der Probleme hat C-Sourcecode von anno dazumal auf aktuellen C++ Compilern zu kompilieren. Neuentwickeln ist zu teuer. Diese Leute interessiert "Das war ein großer Schritt" nicht. Die haben Software, die ein aktueller Compiler mit abertausenden Warnings kompiliert. Ob das alles wirklich noch funktioniert? Alles nochmal anfassen? Wer weiß, was dann alles versehentlich verändert wird!?

Wenn ich dem was von Java erzählen würde, der würde mich fragen, warum er nicht gleich PHP nehmen soll.

Mein Kollege hat sich letzhin ein neues Visual Studio besorgt. Er fluchte gottsjämerlich, dass nichtmal der Code geschrieben im Vorgänger kompilierte...

Als ich von 1.4 auf 1.5 wechselte gabs ein paar Warnungen, aber die Programme liefen dennoch ohne Probleme. Mit ein paar Klicks in der IDE waren auch die Warnungen hübsch sortiert, und die 1.4<->1.5 Warnungen konnten ignoriert werden (der Code war ja nach 1.4-Standard korrekt).

Ich konnte also mitten in der Projektentwicklung die Version wechseln. Sorry, bis heute konnte mir noch niemand ein Versionsproblem bei Java (inkl. Quellcode!) zeigen (nicht mal der TGGC ), hier ist ein + Punkt für Java.

Willst Du den Hype der nächsten Generation wissen? Zu Fuss gehen. Mal gucken, ob das in der nächsten Version von Java auch drin ist - C# hat es ja über das unsafe-Schlüsselwort integriert.

Und dann C++-Code direkt in Java eingebettet? Mal bitte den Teufel nicht an die Wand
Und nein, das ist sehr unwahrscheinlich, eigentlich wird versucht Java "rein" zu halten. Java springt nicht auf jeden Featureitis-Hype-Zug auf, sondern versucht sich solange wie möglich vor Innovationen zu schützen. Deshalb dauerte es auch so elend lange bis endlich Generics kamen.

Java 1.6 hat GARANTIERT ein Schlüsselwort, um Klassen zu verschachteln und alle werden jubeln und sagen 'Java ist die inovativste Sprache der Welt' und diejenigen, die C++ programmieren, werden wieder mal freundlich lächeln und sich einen grinsen.

Hr, braucht es nicht. Gibt es schon seit Java 1.2 (oder wars 1.1?). Das nennt sich innere, anonyme oder Methodenklasse (Klassen kann man direkt in einer Methode definieren. War ziemlich überrascht, als ich das bemerkte).
Java 1.6 wird (wie immer) Erweiterungen der Standardlib haben, der Syntax wird nicht verändert.

In C++ habe ich seit 15 Jahren freie Wahl des Verkehrsmittels. Deswegen bekomme ich dann zu hören, da macht ja jeder alles, wie er will - den Sourcecode versteht dann ja kein Mensch mehr.

Du willst sagen, du verstehst den Quellcode eines fremden C++-Programmieres beim ersten hinschauen? Hut ab, aber dafür hast du lange geübt.

Wart mal ab: In fünf Jahren wird die Java-Gemeinde die freie Wahl des Verkehrsmittels feiern und auch noch glauben, was ultimativ Neues gefunden zu haben.

Wird sie nicht. Bis jetzt gab es erst 2 Erweiterungen. Bei dieser Geschwindigkeit ist in den nächsten 5 Jahren nichts zu erwarten (vorausgesetzt, dass Sun, als treibende Kraft hinter Java, ihre Politik nicht ändern).

schreib' mir eine PM

Funktioniert in diesem Forum nicht.

Mit Zeigern zu programmieren ist Kampfjet-Fliegen. Dass Programmierer aus der Sandbox da abstürzen, ist in der Regel keine Fehlfunktion des Jets.

LOL

JBeni schrieb:

Haskell kann ich dir noch empfehlen. Wie Prolog, nur besser.

Kennst Du ein gutes Tutorial, ich wäre interessiert, da Du nicht der erste bist, der mich auf Haskell aufmerksam macht.

Ich finde A Gentle Introduction to Haskell ganz gut.

Informatiker werden immernoch gesucht.
Trotzdem finden viele Informatiker keine Arbeit.

Vielen fehlt es an Visionen. Das können Vorgesetzte kompensieren.
Den meisten fehlt das Verständnis, was sie da wirklich tun. Solche Leute programmieren auch C++ und man kann es ihnen leider nicht verbieten. Solche Leute mache ich verantwortlich für den inzwischen schlechten Ruf unter Nicht-C++-Programmieren.

Schön gesagt. Für C++ kann man auch Java einsetzen, passt genausogut.

interpreter

SIDEX schrieb:

jemand meinte hier dass c# besser sei weil es call by reference untertzützt? das ist quatsch mit souce sag ich nur!!!

Dein Textverständnis ist offensichtlich genauso schlecht wie deine sonstigen Ausführungen. Wenn du am Ende deines Studiums deinen Text nochmal liest, wirst du (wie ich jetzt) hoffentlich auch drüber schmunzeln können.

JBeni

SIDEX schrieb:

hallölchen

nun wollt ich mich hier mal auch bisschen abreagieren *g*

Dann sei herzlich Willkommen. Ich gebe dir mal ein bisschen Kanonenfutter weil ich nicht einschlafen kann.

zu sagen dass java so wundervoll ist weil es nun so schön platformunabhängig ist find ich unsiinig. ist denn c++ nicht platformunabhängig? ok dann muss ich eben paar zeilen code ändern und neu compilieren, und?

Und: du hast dann praktisch mehrere Programme (oder spielst dich mit Makros zu tode). Der Verwaltungsaufwand steigt.
Unser Prof meinte: "ein guter Programmierer ist faul." Mehr Verwaltungsaufwand widerspricht diesem Optimum.

und nun kom ich zu einem für mich sehr sehr verwirrenden teil in java

man kann java nähmlich sehr einfach in einem satz beschreiben:
beinahe jedes element seien es strings, arrays und und und, ist ein objekt, weil sie von der java.lang.object abstammen und erben und jedes objekt ist wiederum eine referenz.

- Jede Klasse erbt von java.lang.Object. Ein Array kann man hier als eine Art Spezialklasse anschauen. "int", "float", etc sind hingegen Primitive und haben ein anderes Verhalten.
- Jedes Objekt sitzt irgendwo im Speicher rum.
- Eine Variable im Quellcode wird zu einer Referenz zur Laufzeit und referenziert ein Objekt.

Eigentlich alles ganz einfach

so und nun sagt sun java ist sicherer, weil sie auf die zeiger verzichtet haben? LOOOOL *g* hier ist einfach alles eine referenz. echt respekt jungs, da haben die echt mal was geschafft. und die nullpointerexception nervt einen überhaupt nicht jede 5 sekunden.

Wenn du dein Programm richtig schreibst, nein, tun sie nicht
Eine Referenz der mit String angeschrieben ist, kann nicht plötzlich auf ein Wasabuduobjekt zeigen - in C++ durchaus möglich. Eine Referenz kann auch nicht irgendwo wild auf einen beliebigen (sinnlosen) Speicherbereich zeigen. Das ist doch um einiges sicherer.

soooooo, weiter gehts. kommen wir zu GC von java. okay ist n schönes teil, weil man nicht für jeden mist einen destruktor schreiben muss aber, dass eine maschiene es besser machen kann als der mensch, glaub ich einfach nicht.

Ohne GC: du musst sicherstellen dass ein Objekt erst abgeräumt wird, wenn es von niemandem mehr benutzt wird.
Mit GC: das Objekt wird automatisch abgeräumt wenn es von niemandem mehr benutzt wird.

Jetzt erklär mir mal wie du in "etwas sicherstellen" weniger Fehler machen kannst als in "<empty>"?

Dass man bei einem GC zuerst alle Referenzen kappen muss, ist ein anderes Thema (Speicherlecks kann man in Java wie in C++ ohne grösseren Aufwand generieren).

ist java denn so perfekt und nichts verwirrendes beinhaltet, nur weil es dort keine zeiger und mehrfachvererbung gibt? java kann z.B: mit den ganzen klammern nur so vor sich hin spucken, da soll mal einer klar kommen.

Es gibt z.B. auch kein Operatoroverloading, Templates oder Funktionspointer. Ja, mit der Beschränkung auf weniger Syntaxelemente ist Java eindeutig übersichtlicher. Perfekt ist es deswegen nicht, eine perfekte Programmiersprache gibt es derzeit nicht.
Für dein Klammernproblem: Codeeinrückung lautet das Zauberwort

SIDEX schrieb:

also ich muss sagen als ich erste schritte in java gemacht habe, konnte ich schon von der sprache fast kotzen. die schönen sprüche dass java c++ sehr ähnlich sei haben mir am anfang hoffnung gemacht aber jetzt würde ich jeden umbringen der das noch mal behauptet.
ohne genau zu werden muss ich als erstes sagen unter c++ hatte ich einfach das gefühl mehr kontrolle über meinen rechner zu haben.

Aha, jetzt musst Du nur noch definieren was Du mit "ähnlich" meinst. Und ja, die Syntax ist sehr ähnlich. Wodurch hast Du in C++ mehr kontrolle über Deinen Rechner, nur durch Zeiger? Dir ist klar das Referenzen vom Prinzip her nichts anderes als Zeiger sind? Dir ist auch klar, dass man in C++ ebenfalls wann immer möglich Referenzen Zeigern vorziehen sollte?

SIDEX schrieb:

zu sagen dass java so wundervoll ist weil es nun so schön platformunabhängig ist find ich unsiinig. ist denn c++ nicht platformunabhängig? ok dann muss ich eben paar zeilen code ändern und neu compilieren, und? java im vergleich zu c# ist aber wiederum besser, weil nun wirklich platformübergreifend ist.

Es programmiert keiner nur aus dem Grund in Java weil es plattformunabhängig ist. Aber es ist ein Grund der mitunter eine wichtige Rolle einnehmen kann. Anscheinend hast Du noch nie versucht ein etwas größeres Programm unter Windows, Linux, BSD und SVR4 zu laufen zu bringen. Sonst wüsstest Du was Java hierbei so attraktiv macht.

SIDEX schrieb:

man kann java nähmlich sehr einfach in einem satz beschreiben:
beinahe jedes element seien es strings, arrays und und und, ist ein objekt, weil sie von der java.lang.object abstammen und erben und jedes objekt ist wiederum eine referenz.

Das nennt sich OOP. In diesem Fall nicht immer glücklich, aber es hat in der Praxis einfach viele Vorteile.

SIDEX schrieb:

so und nun sagt sun java ist sicherer, weil sie auf die zeiger verzichtet haben? LOOOOL *g* hier ist einfach alles eine referenz. echt respekt jungs, da haben die echt mal was geschafft. und die nullpointerexception nervt einen überhaupt nicht jede 5 sekunden.

Wo hat Sun das geschrieben?
BTW: Wenn Du in Java NullPointerExceptions bekommst, bekommst Du in C++ in der gleichen Situation einen SegFault. Das ist ein reiner Programmierfehler, der nichts mit Java oder C++ zu tun hat.

SIDEX schrieb:

soooooo, weiter gehts. kommen wir zu GC von java. okay ist n schönes teil, weil man nicht für jeden mist einen destruktor schreiben muss aber, dass eine maschiene es besser machen kann als der mensch, glaub ich einfach nicht. ausserdem tuen manche so als ob es keinen für c++ gäbe. hab zwar noch nie einen benutzt aber gehört habe ich schon mal davon, zumindest, dass es in entwicklung ist.

GC ist kein Allheilmittel, aber er ist in bestimmten Situationen für die Performance sogar wichtig, da der Programmierer zur Entwicklungszeit nicht abschätzen kann, wann auf dem spezifischen System ein guter Zeitpunkt erreicht ist(nein ich meine keine Client-Anwendungen auf x86).

SIDEX schrieb:

ok noch ein nachteil von java: schon mal gesehen wie ein array von der JVM implementiert wird? nein? okay ein beispiel:
int[] lahmarsch = { 1, 2, 3 };

//und so siehts dann aus

int[] lahmarsch = new int[3];
lahmarsch[0] = 1;
lahmarsch[1] = 2;
lahmarsch[2] = 3;
juhu und jetzt stellt euch mal nen mille-array vor. ich weiß zwar nicht genau aber ich vermute mal in c++ wird es anders behandelt. so und java soll schneller sein? wieder mal quatsch mit souce

Der ging mal wieder nach hinten los. Der Thread Titel heisst übrigens auch "Warum Java vom Prinzip her schneller als C++?" und nicht "Java ist schneller". Wenn Du wirklich mal repräsentative Beispiele für die Performance und Einsatzgebiete in Java sehen möchtest, dann schau Dir mal J2EE an. So nennt sich dass Zeug was die in der Java-Praxis häufig verwenden.

SIDEX schrieb:

ahhh noch was vergessen. ich habe schon oft gesehen dass die java-fans sich über zeiger-auf-zeiger in c++ beschwerrt haben weil es so verwirrend war. dazu muss ich ne frage stellen: ist java denn so perfekt und nichts verwirrendes beinhaltet, nur weil es dort keine zeiger und mehrfachvererbung gibt? java kann z.B: mit den ganzen klammern nur so vor sich hin spucken, da soll mal einer klar kommen.

Ich habe wie die meisten anderen auch keine Probleme mit Zeigern auf Zeigern auf ein Array von Funktionszeigern die als Parameter wiederum Zeiger auf Funktionen bekommen.

Die guten Java Programmierer haben alle einen Background in vielen anderen Sprachen, dass ist für jeden Programmierer einfach unabdingbar. Ehrlich gesagt, finde ich Zeiger sogar sehr einfach. Schon mal Assembler programmiert?

Meine persönliche Sprache der Wahl ist C(manchmal auch C++). Aber in der Praxis ist Java einfach nur genial! Du hast viel zu wenig Zeit mit viel zu wenig guten Programmierern und must bis zu einem Stichtag eine Anwendung präsentieren. Das ist einer der Gründe warum Java so erfolgreich ist!

Manuelh87

JBeni schrieb:

Wenn du dein Programm richtig schreibst, nein, tun sie nicht
Eine Referenz der mit String angeschrieben ist, kann nicht plötzlich auf ein Wasabuduobjekt zeigen - in C++ durchaus möglich. Eine Referenz kann auch nicht irgendwo wild auf einen beliebigen (sinnlosen) Speicherbereich zeigen. Das ist doch um einiges sicherer.

Wenn du richtig schreibst... dann passiert das auch in c++ nicht!

Überhaupt möchte ich sagen das man Äpfel nicht mit (fetten langsamen ) Birnen vergleichen kann...
Beide Sprachen haben vorteile:
Ich könnte in java ein programm erstellen und mir sicher sein dass es so sofort auf einem anderen system läuft (einzige voraussetzung die JVM, ist aber eh klar); das ist ein völlig anderer ansatzpunkt als bei c++. Ich finde dieses Möglichkeit gibt java durchaus eine Berechtigung.

Aber da c++ native compiliert wird, ist es ja wohl offensichtlich dass java als interpretierte sprache nie so schnell sein kann... -> niemals!!!
Außer natürlich man schreibt sein c++ programm so ineffektiv und langsam wie möglich. Man kann alle (wirklich alles) optimierungen die die JVM je machen könnte auch in sein c++ programm einbauen. Kann ja auch ne VM machen mit c++. Von daher kann sich java beim vergleich mit c++ auf einem bestimmten system *immer* brausen! Noch dazu hat mir bis jetzt niemand zeigen können was die JVM echt optimieren kann, was nicht aus einem programmierfehler ausgeht. hab mal als beispiel eine schleife bei der einen funktion die einen fixen wert zurückbekommt bei jedem durchlauf aufgerufen wird bekommen. Tja, und wo optimiert die JVM da was? Sie macht höchsten den fehler des programmierers weg. Also "optimiert ihn raus"; man könnte ihn aber auch einfach vermeiden...

Also sry, aber es ist sinnlos eine interpreter sprache gegen eine mit nativ code antreten zu lassen... Und diese laufzeitoptimierung, naja bin kein großer fan von ihr, denn die verbraucht ja auch bei der analyse performance und ja, wie gesagt, hab eigentlich noch kein richtig gutes bespiel wo sie optimiert gesehen, außer eben solche "fehler" die man ja auch einfach ausbessern kann.

Damit red ich ja niemandem java aus. Nur ich kann irgendwie nicht mit java arbeiten weil mir einfach zu viel flexibilität abgehen würde, und auch der ganze syntax den ich so liebgewonnen hab ...
Aber wenn mich das nicht so stören würde, sag ich euch würd ichs gscheit lernen und auch benutzen, denn der fakt das es dann auf fast allen systemen ohne neu kompilieren läuft, ist find ich, auch ne ganze menge wert.

in diesem sinne... (und streitet euch nicht zu viel )
mfg Manuel

SIDEX schrieb:

bitte schön:

http://www.galileocomputing.de/openbook/javainsel/java-03.htm#Xxx279093

aber krieg keine überdosis

Naja, du kannst nicht verlangen, dass du in Java genauso programmieren kannst wie in C++, bei gleicher Effizienz. Ich gehe mal davon aus, du willst lokal in einer Funktion ein Array mit den immer selben Startwerten, die sich aber nachher ändern. Wenn sie sich nicht ändern würden, wäre es ziemlich dämlich, das immer gleiche Array neu anzulegen.
In diesem Fall machst du einfach ein statisches Array mit den Startwerten und klonst es jedesmal. Das kann nicht wesentlich langsamer sein, weil auch wenn das Array in C++ auf dem Stack liegt, müssen irgendwie die Werte zugewiesen oder auf den Stack kopiert werden.

so kostet die Zuweisung sehr viel Laufzeit, da wir viele Zugriffe haben, die auch alle schön durch die Index-Überprüfung gesichert sind

Das ist natürlich Blödsinn. Sowas optimiert die VM wahrscheinlich seit 1.3 schon weg. Ebenso wie du nicht glauben brauchst, dass in einer einfachen for-Schleife, die bis zur Array-Länge läuft, bei jedem Zugriff die Index-Prüfung stattfindet.

Daher ist davon abzuraten, etwa Bilder oder große Tabellen im Programmcode zu speichern.

Und das bedarf sowieso keines weiteren Kommentars. Fazit: Ich steige wieder auf meine alten Drogen um.

Manuelh87 schrieb:

Also sry, aber es ist sinnlos eine interpreter sprache gegen eine mit nativ code antreten zu lassen... Und diese laufzeitoptimierung, naja bin kein großer fan von ihr, denn die verbraucht ja auch bei der analyse performance und ja, wie gesagt, hab eigentlich noch kein richtig gutes bespiel wo sie optimiert gesehen, außer eben solche "fehler" die man ja auch einfach ausbessern kann.

Java wird ist keine klassische Interpretersprache! Java ist zur Laufzeit im Speicher genauso Maschinencode, wie C++. Es hat nur halt den einmaligen overhead, der aber in der Praxis(und den richtigen Einsatzgebieten vorausgesetzt) überhaupt keine Rolle spielt!
http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_1.html

Kann das sein, dass ihr alle Java nur in falschen Anwendungsgebieten seht? Du willst ein gutes Beispiel für Performance in Java?

http://de.bea.com/index.jsp
http://www.jboss.org
http://www.sap.com/germany/index.epx

Warum wird auch immer nur eclipse genommen? Was ist mit dem JDeveloper, NetBeans oder dem Sun Java Studio? Das mit eclipse ist ein alter Hut. Das ist genauso als wenn ich für die häufigen Probleme eines bekannten Browsers die Programmiersprache verantwortlich mache. Es kommt immer auf den Programmierer an!

Manuelh87

Kritiker schrieb:

Java ist zur Laufzeit im Speicher genauso Maschinencode, wie C++.

NEIN!

das was die mit byte-code meinen ist NICHT Maschinencode!!!

hast wohl deinen eigenen text nicht ganz verstanden... was macht dann deiner meinung nach die virtual maschine? java liegt eben nicht in native code for sondern in einem code der dann von der JVM interpretiert wird. Damit hab ich ja ned gmeint dass er geparst wird, also so wie halt auf html seiten. natrülich wird java code "compiliert" so wie auch .net "compiliert" wird. Aber in keinen maschinen (=native) code sondern in ich nenns mal java-code. dieser wird dann von der virtual maschine umgesetzt.

Und darum muss er ja langsamer sein oder maximal gleichschnell... also bei perfekter umsetzung... das ist ja wohl logisch.

mfg Manuel

JBeni

*sorry, hier stand Mist*

Gregor

Manuelh87 schrieb:

das was die mit byte-code meinen ist NICHT Maschinencode!!!

hast wohl deinen eigenen text nicht ganz verstanden... was macht dann deiner meinung nach die virtual maschine? java liegt eben nicht in native code for sondern in einem code der dann von der JVM interpretiert wird. Damit hab ich ja ned gmeint dass er geparst wird, also so wie halt auf html seiten. natrülich wird java code "compiliert" so wie auch .net "compiliert" wird. Aber in keinen maschinen (=native) code sondern in ich nenns mal java-code. dieser wird dann von der virtual maschine umgesetzt.

Nein, sorry. Du hast keine Ahnung bzw. hast einen Wissensstand, der auf dem Level von Java 1.1 ist.

Die JVM nutzt heutzutage einen sogenannten Jitter. Das ist ein "Just in time compiler". Der übersetzt den Bytecode zur Laufzeit in nativen Maschinencode. Wenn das geschehen ist, liegt der Code nativ vor und kann entsprechend schnell ausgeführt werden. Da gibt es dann keine "Interpretation" mehr.

Zudem werden zur Laufzeit die sogenannten "Hotspots" analysiert. Also die Codebereiche, in denen besonders viel gerechnet wird, weil sie oft durchlaufen werden. Hier wird dann ganz besonders stark optimiert.

Es dauert natürlich ne gewisse Zeit, so eine Analyse zu machen und zu kompilieren. Deshalb brauchen Javaprogramme normalerweise eine gewisse Aufwärmphase, bis sie ihre volle Performance zeigen können. Das beobachte ich zum Beispiel auch bei meinem Projekt, das einen Raycaster beinhaltet ganz deutlich: Wenn man da ein Volumen mit der Maus rotiert, dann werden die ersten 2 Bilder deutlich langsamer erstellt als die restlichen... die ersten beiden brauchen vielleicht 150ms und die danach dann nur noch 75ms oder so.

Xin

Löle Sidex.

SIDEX schrieb:

nun wollt ich mich hier mal auch bisschen abreagieren *g*
natürlich kann ich nicht viel mit manchen leuten mithalten die schon jahrelang erfahrung haben aber trotzdem will ich mal was sagen.

a) Abreagieren geht nicht. Du studierst und wenn Du im ersten Semester bist, brauchst Du noch VIEL Gelassenheit. (Hab' selber Infomatik studiert).
b) Wenn Du im ersten Semester programmieren lernst, also über ~3 Monate Programmiererfahrung verfügst, sollte man zuhören und wenig sagen, sonst wird das auf kurz oder lang peinlich. ;-> So be careful. 3 Jahre 'Komponentenschieben' (Delphi) läuft bei mir nicht unter Programmiererfahrung, rechnen wir mal ein Jahr dazu

SIDEX schrieb:

ohne genau zu werden muss ich als erstes sagen unter c++ hatte ich einfach das gefühl mehr kontrolle über meinen rechner zu haben.

[...]

so und nun sagt sun java ist sicherer, weil sie auf die zeiger verzichtet haben? LOOOOL *g* hier ist einfach alles eine referenz. echt respekt jungs, da haben die echt mal was geschafft. und die nullpointerexception nervt einen überhaupt nicht jede 5 sekunden.

Hmm... in C++ bekommst Du da keine Exception, mit etwas Glück 'nen Segmentation fault.
Die Nullpointerexception erscheint mir also noch ganz hilfreich, damit der Rechner nicht die Kontrolle über Dich erhält. ^^

Am Rande... Referenzen und Zeiger sind in C++ nicht identisch... Referenzen in C++ sind Zeiger mit Netz und doppelten Boden, solange man ausschließlich mit Referenzen arbeitet, muss man schon etliches verbiegen, um einen Nullpointer hinzubekommen.

Scherz beiseite: Nimm Dir Papier und Bleistift - nicht den Computer - und guck Dir an, wie Zeiger funktionieren.
Der Punkt-Operator und der Index-Operator sind Adress-Additions-Operatoren. Lass Dir Adressen anzeigen und das musst Du auf Papier nachvollziehen können.
Wenn Du das in C++ kannst und begreifst, was passiert, dann gibt's auch keine Nullpointer-Exceptions mehr.

SIDEX schrieb:

soooooo, weiter gehts. kommen wir zu GC von java. okay ist n schönes teil, weil man nicht für jeden mist einen destruktor schreiben muss

Dazu wirst in C++ nicht auch nicht gezwungen.
Das Problem ist viel eher, dass Du es in Java und C# nicht kannst. Wenn Du garantieren musst, dass die Daten vernichtet werden, dass alle Verbindungen gekappt werden, dann hangelt man sich mit irgendwelchen Sonderfunktionen rum, weil ein delete nicht geht.

SIDEX schrieb:

ok noch ein nachteil von java: schon mal gesehen wie ein array von der JVM implementiert wird? nein? okay ein beispiel:
lahmarsch[0] = 1; lahmarsch[1] = 2; lahmarsch[2] = 3;
juhu und jetzt stellt euch mal nen mille-array vor. ich weiß zwar nicht genau aber ich vermute mal in c++ wird es anders behandelt. so und java soll schneller sein? wieder mal quatsch mit souce

Falsch vermutet. Dein Prozessor macht rund 3 Milliarden Zuweisungen dieser Art pro Sekunde. Ein move sollte jedenfalls nicht mehr als einen Takt kosten. Macht bei 3GHz und 32 Bit (int) etwa 12Gigabyte pro Sekunde. Das Programm ist also nicht der Flaschenhals, sondern der Speicher, der so schnell gar nicht Daten aufnehmen kann. Bei derartigen Anwendungen hat Java einen Nachteil, da die Startzeit hoch ist (JVM laden, kompilieren), ein natives Programm hat hier keine entsprechende Initialisierungsphase, kann also sofort starten. Nachdem die JVM dann aber mal da ist und das Programm kompiliert ist, treten zwei native Programme gegeneinander an, die vermutlich gleich schnell sind.
Wäre das Array gigantisch groß (was nicht als guter Programmierstil zu werten wäre), so müsste Java regelmäßig nachkompilieren, sobald der Cache für Nativecode vollständig ausgeführt wurde, würde also auf Dauer Boden verlieren.

Es gibt Dinge, die werden so gemacht, wie sie gemacht werden, weil ein Computer eine Maschine ist und aich nicht Lösungen ausdenkt, sondern durchführt. Um einen Aktenordner zu kopieren, nimmt ein Blatt heraus, kopiert es und nimmt dann das nächste. Programmiersprachen besitzten gegebenfalls Funktionen um Aktenordner zu kopieren, aber intern wird immernoch Blatt für Blatt kopiert.

SIDEX schrieb:

so ich glaube ich sollte zum ende kommen ansonsten kann ich mich hier noch die ganze nacht über java beschwerren.

Sich über Java zu beschweren ist ok
Aber die Argumentenauswahl wird sich mit fortschreitender Programmiererfahrung verbessern. Und Du wirst Argumente für - und gegen - alleProgrammiersprachen - auch für C++ finden.

SIDEX schrieb:

ahhh noch was vergessen. ich habe schon oft gesehen dass die java-fans sich über zeiger-auf-zeiger in c++ beschwerrt haben weil es so verwirrend war. dazu muss ich ne frage stellen: ist java denn so perfekt und nichts verwirrendes beinhaltet, nur weil es dort keine zeiger und mehrfachvererbung gibt?

Verwirrung ist immer schädlich.
Die Frage ist eher, ob es für eine Sprache ein Fortschritt ist, wenn man nützliche Dinge verbietet - wie eben Zeiger auf Zeiger oder Mehrfachvererbung - weil ein Teil der Programmierer damit nicht umgehen können. Man könnte ja auch die Programmierer besser ausbilden oder einem schlecht ausgebildeten Programmierer verbieten in C++ Zeiger oder Mehrfachvererbung zu nutzen.

Manuelh87

Nein, sorry. Du hast keine Ahnung bzw. hast einen Wissensstand, der auf dem Level von Java 1.1 ist.

Wissensstand = 0.0; (Soll heißen mein wissenstand!!)
aber ließ dir mal aufmerksam durch was du geschrieben hast und sag mir dann bitte wie mich dann das java programm überholen will. also wie ein java programm aussieht, dass IMMER schneller als ein vergleichbares c++ programm ist??

ich mein dein jitter ist ja ganz net... aber irgendwann muss der auch compilieren; und wenn er das einfach am anfang quasi macht, dann wie bitte soller noch optimieren??

Ich glaub dir gerne dass du viel besser bescheid weist über das ganze zeug, denn ich hab mir ned genau durchgelesen was sie da behaupten, aber denk dir mal durch wie du das hier dargestellt hast... wie soll das funktionieren?? wie optimiert er dann dynamisch?? den maschinencode? den bytecode davor? wie???

Mein wissensstand in java und so ist vielleicht gering, aber ich kenn auch die maschinennahe seite; wenn auch nicht sehr gut; und von daher kann ich dir sagen, dass du es nicht schaffen wirst ein java prog. zu entwickeln dass die beste umsetzung in c++ schlägt, da nämlich notfalls für die beste umsetzung in c++ nochimmer das schreiben einer JVM übrig bleibt.... verstehste??

mfg Manuel

Gregor

Manuelh87 schrieb:

und sag mir dann bitte wie mich dann das java programm überholen will. also wie ein java programm aussieht, dass IMMER schneller als ein vergleichbares c++ programm ist??

Ich habe schon ziemlich weit vorne in diesem Thread etwas bezüglich solcher Aussagen gesagt. Ich habe zum Beispiel einen Bereich genannt, in dem C++ nicht optimieren kann, Java aber prinzipiell schon: Das betraf das Inlining bei vorliegender Laufzeitpolymorphie. Stell dir einen Algorithmus vor, der aus verschiedenen Bausteinen zusammengesetzt ist, die zur Laufzeit zusammengefügt werden. Für jeden Baustein gibt es eine abstrakte Basisklasse oder ähnliches und mehrere konkrete Klassen, die die geforderte Funktionalität dieses Bausteins auf unterschiedliche Weise realisieren. Stell dir weiter vor, dass dieser Baustein in einer Schleife genutzt wird, die sehr oft durchlaufen wird. C++ könnte da dann kein Inlining betreiben, da es zur Compilezeit nicht die Informationen zur Verfügung hat, welche konkrete Realisierung da wann gebraucht wird. Der Hotspot-Jitter hat diese Informationen und könnte somit entsprechendes Inlining betreiben. Solche konfigurierbaren Algorithmen setze ich im Übrigen sehr sehr häufig ein.

Naja... soweit zur Theorie. Wie es wirklich aussieht, habe ich ja auch weiter oben geschrieben. Sowohl in C++ als auch in Java kommt man nicht ans Optimum heran. Insofern ist das eine Phantomdiskussion. Man sollte eher von mal zu mal testen, ob eine gegebene Technologie die Anforderungen für ein bestimmtes Projekt erfüllt oder nicht. Allgemeine Aussagen sind da eher mit Vorsicht zu genießen.

...ach ja: Bevor hier wieder einer kommt mit: "Mit C++ kann man da auch optimieren, weil man mit C++ ja ne VM schreiben kann...". Dann würde man so weit gehen, dass man sich eine neue Sprache schafft und letztendlich landet man dann wieder bei etwas wie Java oder C# oder so. Die JVM von Sun ist ja auch in C++ geshreiben, trotzdem sagt man zu Java Java und nicht "modifiziertes C++" oder so.

Artchi

Manuel87! Der JIT von Java compiliert nicht zu Anfang des Programmstart, sondern zur Laufzeit (Just in Time!) entscheidet er, was und vorallem wie er kompiliert. Ein sehr einfaches Beispiel:

switch(i) {
 case 0:
    blabla;
    break;
 case 1:
    blabla;
    break;
}

So, wenn der JIT an die gezeigte Stelle kommt, führt er diese normal aus. Er merkt sich aber wie das Ergebnis war. Z.B. das case 1 eingetreten ist. D.h. case 1 wird wahrscheinlich öffters als case 0 betroffen sein. Beim nächsten Durchlauf dieser Stelle wird er das ganze in Maschinencode kompilieren, aber mit dem UNterschied, das case 1 vor case 0 geschoben wird. Weil so brauch die CPU weniger Vergleiche machen, da case 1 wahrscheinlich öffters bei dem switch zutreffen wird.

Das ist jetzt so einfach mal von mir und meiner Vorstellung des JIT. Wenn das Java nicht machen würde, wäre Java noch langsamer. :p

Jetzt sagen sicherlich die Java-Fans: Ätsch! Wir werden dadurch C++ einholen.

Da sage ich nur: Ätsch! Für C++ gibts das heute auch schon, wenn auch nicht zur Laufzeit beim Endanwender. Aber das PGO (Profile Guided Optimazation) vom VisualC++ 2005 Compiler macht genau das beim Entwickler! Vorgehensweise:

1. Release Build erstellen, mit aktivierten PGO.

2. Das fertige Kompilat wird jetzt vom User einmal laufen gelassen. Bei einer Server-Software wird dann halt der Server einmal laufen gelassen. Oder bei einem Spiel, wird halt ein paar Sekunden gespielt, damit z.B. die 3D-Engine einmal alles mögliche dargestellt hat. In der Zwischenzeit macht PGO eine Statistik, z.B. über die oben genannten Switch-Fälle. Halt alles das was statistisch zur Laufzeit optimert werden könnte.

3. Mit diesen gewonnen Infos wird dann einfach ein optimierter Build erstellt. Und schon hat man einen Code der auch Laufzeit-Optimierung enthält.

Laut Microsoft hat das neukompilieren ihres SQL Servers 2005 allein nur durch die neue PGO-Funktion den Server im Schnitt 20-30% schneller gemacht!

Manuelh87

Gregor schrieb:

...ach ja: Bevor hier wieder einer kommt mit: "Mit C++ kann man da auch optimieren, weil man mit C++ ja ne VM schreiben kann...". Dann würde man so weit gehen, dass man sich eine neue Sprache schafft und letztendlich landet man dann wieder bei etwas wie Java oder C# oder so. Die JVM von Sun ist ja auch in C++ geshreiben, trotzdem sagt man zu Java Java und nicht "modifiziertes C++" oder so.

hab mir schon gedacht das du das nicht verstehen wirst. ich mein ja nur deine so hochgelobten algos der verbesserung könnten ja trotzdem in einem c++ programm ebenfalls miteingebracht werden könnten...

das mit der basis klasse ist ja schön und gut... und warum funktioniert das jetzt in c++ schlechter?? wenn dich die virtual calls stören dann kannst du die natürlich auch mit ein paar kniffen umgehen, sodass nur ein virtueller call benötigt wird... es liegt alles bei dir als c++ coder...
aber um soetwas einzusehen muss man halt auch ein hardware-nahes vertändniss haben... ist ja schön das du theoretisch weißt wie gesagt wird dass die jVM etwas umsetzt.
Es gibt soo viele möglichkeiten genau dieses verhalten, welches du ja so toll findest, in c++ selbst zu machen und zu verwenden... man muss halt dabei nachdenken.. aber das ist ja nicht negativ, oder?

mfg Manuel

Manuelh87

Artchi schrieb:

Manuel87! Der JIT von Java compiliert nicht zu Anfang des Programmstart, sondern zur Laufzeit (Just in Time!) entscheidet er, was und vorallem wie er kompiliert. Ein sehr einfaches Beispiel:
switch(i) {
 case 0:
    blabla;
    break;
 case 1:
    blabla;
    break;
}
So, wenn der JIT an die gezeigte Stelle kommt, führt er diese normal aus. Er merkt sich aber wie das Ergebnis war. Z.B. das case 1 eingetreten ist. D.h. case .....

aha... weißt du wie ein guter c++ compiler das umsetzt??
ein vergleich ob der index in range liegt, und dann ein jump table... na da stauenen die java fanatiker...
Und um die reihung richtig zu haben... halt bei ifs... ja sry, aber wer schreibt den das programm?? du wirst ja wohl selber wissen welcher case wahrscheinlicher ist... völlig unnötig da einen auslastungstest zu machen...

im gegenteil: jetzt mach ich als kleiner fetter java coder eine funktion und stell bewusst ein case for das andere weil ich diese reihenfolge bevorzuge (gehen wir mal davon aus das switch case als cmp umgesetzt wird) weil der code dahinter öfter aufgerufen wird. so jetzt ist aber das erste case das andere und die JVM schiebt jetzt das ganze in die falsche reihenfolge und kompiliert das dann, nach deinem schema...? oder vielleicht doch nicht??

-> wo ist jetzt die große verbesserung durch die JVM??
mfg manuel

Xin

JBeni schrieb:

Ein Programm, dass auf einmal und ohne brauchbare Kontrolle des Benutzers große Mengen Rechenleistung anfordert, kann nicht Problem des Betriebsystems sein.

Ok, hier sollte man differenzieren: wenn mehrere Programme laufen und eines klaut den anderen Rechenzeit, dann ist das OS schlecht (*hüstel* kann man immerwieder schön bei Windows beobachten...).
Wenn es programmintern abläuft, ists natürlich was anderes.

Kein OS kann mehr Rechenzeit/Zeiteinheit liefern, als die Hardware liefern kann. Das Umkopieren von großen Speicherblöcken kostet Rechenzeit und die GC fragt nicht beim OS an, ob jetzt ein richtiger Zeitpunkt wäre und kann auch nicht warten, weil sonst Java nicht weiterlaufen würde.

JBeni schrieb:

JBeni schrieb:

Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...

Warum? Reden ist Silber, Schweigen ist Gold?

Das System ist IMHO der grösste Nachteil der JVM, deshalb schweige ich.

Da stichel ich noch ein wenig...
Das wichtigste Merkmal von Java ist die JVM und die JVM ist der größte Nachteil von Java. Damit ist das wichtigste Merkmal von Java ein Nachteil, wenn ich das grade richtig verstehe!?

JBeni schrieb:

95% * (10% Systeme die überhaupt Linux haben) * (10% Die dieselbe Software auf beiden Systemen benötigen) = verschwindend gering

Mich würde mal die Quote interessieren, wenn man die ganzen Gamer und LAN-Party-Gänger abzieht, die vermutlich keine Java Spiele zocken...
Diese Systeme sind schließlich keine Computer, sondern Spielzeuge. Waschmaschinen enthalten ebenfalls Computer, werden aber in der Statistik auch nicht geführt, sonst wäre die Zahl der Dualboot-fähigen Systeme vermutlich verschwindet gering. ^^

JBeni schrieb:

Stimmt. Aber wo ist das Problem - weigern sich Programmierer bzgl. GUI-Frameworks dazuzulernen?

Hoffentlich nicht *g*. Aber man kann ein Framework nicht in einem Tag kennen lernen. Wenn dann Wochen auf kennen lernen + coden + debuggen + etc. draufgeht ist das nicht so dolle.

Hmm.. wie sollte man sonst das Know-How steigern, dass die Firma anbieten kann?

JBeni schrieb:

Wenn ich dem was von Java erzählen würde, der würde mich fragen, warum er nicht gleich PHP nehmen soll.

Mein Kollege hat sich letzhin ein neues Visual Studio besorgt. Er fluchte gottsjämerlich, dass nichtmal der Code geschrieben im Vorgänger kompilierte...

Dann rate ich dringend zu ein paar Erfahrungen in PHP3, PHP 4, PHP 4.3 und PHP 5.
Selbst Microsoft kann das nicht derart verbocken, obwohl die Unterschiede zwischen VC6 und VC 2003 gravierend sind. Positiv in der IDE, zurückhaltend bzgl. des Sourcecodes.

JBeni schrieb:

Ich konnte also mitten in der Projektentwicklung die Version wechseln.

Meinen Compiler übertrage ich ohne Änderungen zwischen GCC 2.95, GCC 3.3, GCC 4.0 und StormC.
Visual C habe ich nicht ausprobiert, da mich Windows nicht so anspricht.

JBeni schrieb:

Java 1.6 hat GARANTIERT ein Schlüsselwort, um Klassen zu verschachteln und alle werden jubeln und sagen 'Java ist die inovativste Sprache der Welt' und diejenigen, die C++ programmieren, werden wieder mal freundlich lächeln und sich einen grinsen.

Hr, braucht es nicht. Gibt es schon seit Java 1.2 (oder wars 1.1?). Das nennt sich innere, anonyme oder Methodenklasse (Klassen kann man direkt in einer Methode definieren. War ziemlich überrascht, als ich das bemerkte).
Java 1.6 wird (wie immer) Erweiterungen der Standardlib haben, der Syntax wird nicht verändert.

Nix inline definiert....

class foo
{
  int x;
  int y;
  /* .. */      
};  // 40 Bytes groß...

class bar
{
  short  Pad;
  foo *  ZeigerAufFoo;             //  4 Bytes groß
  foo    VerschachteltesElement;   // 40 Bytes groß      
};  // 44 Bytes

class snafu
{
  int    Pad;                      // 4 Byte
  foo    SnafuEnthaeltEinFoo;      // 40 Byte
  bar    UndEinBar;                // 44 Byte
}: // 88 Byte

Um auf VerschachteltesElement zuzugreifen, muss nicht teuer referenziert werden:

void blah( void )
{
  bar baz;  // Wobei baz auf dem Stack an Adresse 4711 liegt

  baz.ZeigerAufFoo = new foo();     // Neues Foo anlegen bei 0815 => bei 4713 den Wert 0815 ablegen.
  baz.ZeigerAufFoo->y = 1;          // Stackrelativ an Position 0 lesen (Baz:4711), 2 Aufaddieren (.ZeigerAufFoo:4713), dereferenziere(*():0815), dann 4 aufaddieren(.y:0819), Zuweisung durchführen(=) mit Wert 1
  baz.VerschachteltesElement.y = 1; // Stackrelativ an Position 0 lesen (Baz:4711), 6+4=10 aufaddieren (.Verschachteltes Element.y:4721), Zuweisung durchführen(=) mit Wert 1 ablegen
}

Die eingebetete Klasseninstanz ist also ohne Dereferenzierung erreichbar. Die Additionen (.VerschachteltesElement.y) können vom Compiler zusammengefasst werden, was nicht geht, wenn eine dereferenzierung dazwischen liegt, die bei Java grundsätzlich dazwischen liegt.
Das könnte unser Erstsemesterstudent zum Beispiel als Argument nehmen, dass Java nicht so schnell wie C werden kann, selbst wenn es kompiliert ist, läßt sich das hier nur schwer bzw. gar nicht wegoptimieren.
Die Zeitverzögerung wird bei vielen Problemen nicht groß auffallen, aber es bleibt dabei, dass Java bei jedem Zugriff zwei zusätzliche Takte verbrät, was in Schleifen oder vielen derartigen Zugriffen innerhalb von Schleifen sich schon zu bemerkbaren Sekunden zusammenaddieren kann.

JBeni schrieb:

In C++ habe ich seit 15 Jahren freie Wahl des Verkehrsmittels. Deswegen bekomme ich dann zu hören, da macht ja jeder alles, wie er will - den Sourcecode versteht dann ja kein Mensch mehr.

Du willst sagen, du verstehst den Quellcode eines fremden C++-Programmieres beim ersten hinschauen? Hut ab, aber dafür hast du lange geübt.

Nein. Den Code eines fremden, fähigen Programmierers verstehe ich nicht, da muss ich mich reinarbeiten.
Da die meisten Programmierer aber nicht fähig sind, sehe ich häufig beim ersten hinschauen, die Fehler im Sourcecode.

Ich programmiere seit 1995 C, seit 1999 C++ und davor Assembler.
Wer debuggen will, sollte das in Assembler lernen. Man lernt zwei Dinge:
a) Wie finde ich effizient Fehler
b) es ist effizienter erst zu denken, dann zu programmieren. Selbst wenn man effizient Fehler findet, ist es ein tierischer Aufwand, den man sich in 90% der Fälle hätte sparen können, wenn man nicht einfach programmiert hätte nach dem Motto 'Wird schon passen'.

JBeni schrieb:

schreib' mir eine PM

Funktioniert in diesem Forum nicht.

Wenn Du mir schreiben möchtest, wirst Du meine E-Mail-Adresse sicherlich rausfinden.
Ansonsten: fnfpun@ngebcf.pbz
Rot13 ist Dein Stichwort.

Haskell-Tutorial: Thx.

Xin

Artchi schrieb:

Manuel87! Der JIT von Java compiliert nicht zu Anfang des Programmstart, sondern zur Laufzeit (Just in Time!) entscheidet er, was und vorallem wie er kompiliert. Ein sehr einfaches Beispiel:
switch(i) {
 case 0:
    blabla;
    break;
 case 1:
    blabla;
    break;
}
So, wenn der JIT an die gezeigte Stelle kommt, führt er diese normal aus. Er merkt sich aber wie das Ergebnis war. Z.B. das case 1 eingetreten ist. D.h. case 1 wird wahrscheinlich öffters als case 0 betroffen sein. Beim nächsten Durchlauf dieser Stelle wird er das ganze in Maschinencode kompilieren, aber mit dem UNterschied, das case 1 vor case 0 geschoben wird. Weil so brauch die CPU weniger Vergleiche machen, da case 1 wahrscheinlich öffters bei dem switch zutreffen wird.

Das ist jetzt so einfach mal von mir und meiner Vorstellung des JIT. Wenn das Java nicht machen würde, wäre Java noch langsamer. :p

Ich habe keine Ahnung, was die JVM alles macht, aber wenn sie das macht, was Du hier grade vorschlägst, dann sollten wir Java erst recht nicht ernst nehmen.

void * SwitchTable[] { CASE_0, CASE_1 };

   goto SwitchTable[i];

CASE_0:
   blabla;
   goto EXIT;

CASE_1:
   blabla;

EXIT:
   ...

Hast Du eine Vorstellung, wieviel Zeit es kostet, erstmal rumzuraten, was ich dann kompilieren könnte, nur um ein popliges If-zu sparen?
Switch ist schneller, weil es eben nicht durch x-Fälle durchgehen muss, deswegen darfst Du auch kein case 3 && j == 5: angeben.
Ob das da oben von einem C-Compiler akzeptiert wird, weiß ich nicht. Das ist nicht mein üblicher Programmierstil, jedenfalls nicht in C. Das vielleicht am Rande...

Artchi schrieb:

Jetzt sagen sicherlich die Java-Fans: Ätsch! Wir werden dadurch C++ einholen.

Da sage ich nur: Ätsch! Für C++ gibts das heute auch schon, wenn auch nicht zur Laufzeit beim Endanwender. Aber das PGO (Profile Guided Optimazation) vom VisualC++ 2005 Compiler macht genau das beim Entwickler! Vorgehensweise:
Laut Microsoft hat das neukompilieren ihres SQL Servers 2005 allein nur durch die neue PGO-Funktion den Server im Schnitt 20-30% schneller gemacht!

Was hat C++.NET mit C++ zu tun?
Da kann ich auch gleich Java nehmen... <kopfschüttel>

Was das Neukompiliern von SQL-Server angeht, so sage ich Dir, dass das vor allem darauf hinweist, dass von den Programmierern, die die ursprüngliche Version von SQL Server 2005 geschrieben, keine mal seinen Verstand beim Programmieren benutzt hat. Wenn man einer Maschine soviel Phantasie einbauen kann, dass sie sich Gedanken darüber machen kann, welcher Fall häufiger eintritt, dann waren die Programmierer ziemlich hohl, weil die sollten das wissen, bevor sie anfangen zu programmieren.

Artchi

Der PGO ist meines Wissens für natives C++ und nicht C++/CLI!

Ich weiß nicht was alle auf diese Laufzeitoptimierung rumhacken? Naja... Und das switch-Case-Beispiel war nur ein Beispiel, ob es ein JIT oder PGO wirklich macht, weiß ich nicht. Es war nur ein einfaches Beispiel, wie ich es mir vorstelle. Und selbst wenn es wirklich so ist, fänd ich es toll und nicht schlecht. Denn 30% Performance-Gewinn ist mir egal wo die herkommen, hauptsache ich hab die.

Was hat Bjarne Stroustrup mal geschrieben? "Es geht nicht darum seine 5 coolsten Zeilen Code zu schreiben!" Aber hier reden viele, als ob sie die coolsten Zeilen code schreiben wollen. Hobby-Coder können das gut und gerne machen, da hat man die Zeit, aber nicht im harten berufsleben.

Manuel87 sagt mir schon alles: Jahrgang 87. Als ich Schüler war, hab ich auch nur coole Sachen programmiert.