Java ist schneller als C++!
-
Optimizer schrieb:
Jester schrieb:
rapso schrieb:
wie praktikabel linux/bsd/etc. mit den source packeten ist?
du hast wieder mal nix gelesen und haust nur blinde drauf, gell? Kannst Du bitte bitte mal aufhören davon auszugehen, dass ich irgendwie völlig beschränkt bin? Oder kompilierst Du tatsächlich die Anwendung vor jeder Benutzung, um sie auch auf die aktuelle Systemauslastung hin zu optimieren (z.B. größe vs. geschwindigkeit). wie ist das bei dir bei der arbeit, legt ihr auch die sourcen bei? wie praktikabel ist das?
Diese Optimierungsmöglichkeiten halte ich für übertrieben theoretisch.
mag sein, aber das war ja nicht rapsos Argument.
ah, hast du grad mal nen link zu so einem C++ JIT Compiler?
-
Jester schrieb:
rapso schrieb:
wie praktikabel linux/bsd/etc. mit den source packeten ist?
du hast wieder mal nix gelesen und haust nur blinde drauf, gell?
doch ich hab's gelesen (jedenfalls 4seiten zurueck) und hab gesagt dass sowas in der art gemacht wird. genau wie es JIT gibt die sowas machen beim ersten start, also vor dem start, dem system entsprechend neu bauen. manche JIT lassen einen profilelauf rennen und beim zweiten start wird dann die system angepasste version gebaut.
Kannst Du bitte bitte mal aufhören davon auszugehen, dass ich irgendwie völlig beschränkt bin?
sehr gerne.
Oder kompilierst Du tatsächlich die Anwendung vor jeder Benutzung, um sie auch auf die aktuelle Systemauslastung hin zu optimieren (z.B. größe vs. geschwindigkeit).
nein, das waere voellig "beschraenkt". die laufleistung haengt bei den allermeisten programmen von den daten ab, nicht so sehr von compilierflags. wenn ich photoshop neu compilieren wuerde, weil ich mir ein icon ansehen will, aber weil mein system gerade speichermaessig ausgelastet ist, ich alles neu bauen muss um es mir dann in 1.5 statt 1.6mb anzusehen, waere das recht sinnfrei.
deswegen, erst profilen, dann optimieren, ergo: pgo. entsprechend gehoeren daten zum profilen und optimieren dazu.
wie ist das bei dir bei der arbeit, legt ihr auch die sourcen bei? wie praktikabel ist das?
wir haben builds fuer die gelaeufigsten systeme. diese bauen ueber nacht durch. alles in allem sind es ca 10 8-core server + ca 100 distributed clients die ca 3stunden bauen, wobei das production builds sind, die sind entsprechend nicht bis zum ende optimiert, da es noch keine finalen daten gibt.
mit finalen daten benutzen wir halt pgo, und das fuer verschiedene systeme und verschiedene teile eines builds. du wuerdest es nicht glauben wieviele permutationen wir haben.
aber wenn du es wissen willst, wie praktikabel es ist das optimale programm zu bauen, versuch gerne mal: http://www.coyotegulch.com/products/acovea/
ich glaube dann kommt jeder zu dem schluss...
-
Was macht ihr mit den vielen Permutationen dann? Werden die tatsächlich alle ausgeliefert und für den Kunden die jeweils passendste gewählt, oder nehmt ihr die, die im Durchschnitt über die Systeme die beste Performance liefert?
-
Jester schrieb:
ah, hast du grad mal nen link zu so einem C++ JIT Compiler?
Du kannst zum Beispiel den VC++ Zwischencode erzeugen lassen (auch wenn du bei Standard C++ bleibst).
-
Echt, wie geht das denn? PGO weiß ich, wie's mit dem VC funktioniert, aber wo finde ich den Zwischencode? Oder meinst Du das via C++/CLI?
-
Ja, du musst aber nicht die Spracherweiterungen nutzen. Du kannst Standard C++ zu .Net Zwischencode compilieren, der Schalter dafür ist /clr:pure.
Die Klassen sind dann natürlich nicht von anderen .Net-Sprachen aus nutzbar, sondern wie üblich nur von anderen VC++-Projekten aus. Du hast halt den Vorteil (oder Nachteil) der JIT-Compilierung. Die meisten Optimierungen werden auch auf den Zwischencode angewendet.
-
man kann zum Beispiel keine Klasse exportieren, die Member hat, deren Typ nicht exportiert ist, auch wenn dieser Member gar nicht Teil der öffentlichen Schnittstelle ist
Klar geht das, man muss nur die dummen Warnings ignorieren die VC dann absetzt.
Man kann das sogar machen WENN das Member Teil der öffentlichen Schnittstelle ist, bloss kann es dann sein dass man das Client Programm nichtmehr linken kann.
-
man muss nur die dummen Warnings ignorieren die VC dann absetzt.
bloss kann es dann sein dass man das Client Programm nichtmehr linken kann
Ich weiß nicht, ob du das verstehen kannst, aber das sind beides statements, die tiefstes Mistrauen in mir wecken?!
-
Jester schrieb:
ah, hast du grad mal nen link zu so einem C++ JIT Compiler?
http://llvm.org/
Ist zwar glaub ich eher auf die Kompilierung des Bytecodes zu herkömmlichen Programmdateien ausgerichtet, allerdings gibt es auch JIT Compiler für die gängigsten Prozessoren. Das C/C++ Frontend ist ein angepasster GCC. Ich hab keine praktischen Erfahrungen in der Verwendung.
-
Optimizer schrieb:
man muss nur die dummen Warnings ignorieren die VC dann absetzt.
bloss kann es dann sein dass man das Client Programm nichtmehr linken kann
Ich weiß nicht, ob du das verstehen kannst, aber das sind beides statements, die tiefstes Mistrauen in mir wecken?!
Ich weiss nicht ob du das verstehen kannst, aber mir wäre es lieb wenn du erklären könntest WAS genau jetzt dein Misstrauen weckt.
BTW: ich wollte nur feststellen dass deine Aussage "geht nicht" so einfach nicht stimmt. Ob man es machen mag ist jedermanns eigene Sache. Ich sehe es in vielen Fällen als unproblematisch an.
-
hustbaer schrieb:
Optimizer schrieb:
man muss nur die dummen Warnings ignorieren die VC dann absetzt.
bloss kann es dann sein dass man das Client Programm nichtmehr linken kann
Ich weiß nicht, ob du das verstehen kannst, aber das sind beides statements, die tiefstes Mistrauen in mir wecken?!
Ich weiss nicht ob du das verstehen kannst, aber mir wäre es lieb wenn du erklären könntest WAS genau jetzt dein Misstrauen weckt.
Ach ich weiß nicht, vielleicht der Ratschlag, Compilerwarnungen zu ignorieren oder "es kann sein, dass irgendwas nicht geht". Auf sowas baue ich kein Software-Projekt auf. Im übrigen steht in der MSDN ganz genau drin, unter welchen Umständen eine Klasse nicht geshared werden kann, ohne Datenkorruption zu riskieren. Da erscheint der Rat, die Warnungen zu ignorieren wie Hohn. Wenn ich mich nicht darauf verlassen kann, dass es funktioniert, dann ist es nutzlos.
-
Jester schrieb:
Was macht ihr mit den vielen Permutationen dann? Werden die tatsächlich alle ausgeliefert und für den Kunden die jeweils passendste gewählt, oder nehmt ihr die, die im Durchschnitt über die Systeme die beste Performance liefert?
dann wird eben die software anstatt auf einer DVD auf 100 davon ausgeliefert. bei der installation startet erstmal eine analyseprogramm, welches die umgebung testet und am ende sagt: 'zur abschliessenden installation legen sie bitte die CD 76 ein'. naja, tolle c++ welt. ich finds ja immer sagenhaft, mit welchen 'argumenten' c++-fanboys ihren liebling schönreden.
Optimizer schrieb:
Du kannst zum Beispiel den VC++ Zwischencode erzeugen lassen (auch wenn du bei Standard C++ bleibst).
das konnte schon der vc 1.52 (für 16bit windoofs). das nannte sich P-code. für was das gut war, oder ob's überhaupt jemand verwendet hat, weiss ich aber nicht.
-
fricky, bis jetzt hatte ich eine hohe meinung von dir, aber:
[...]für 16bit windoofs[...]
muss doch nicht sein, oder?
-
Optimizer schrieb:
hustbaer schrieb:
Optimizer schrieb:
man muss nur die dummen Warnings ignorieren die VC dann absetzt.
bloss kann es dann sein dass man das Client Programm nichtmehr linken kann
Ich weiß nicht, ob du das verstehen kannst, aber das sind beides statements, die tiefstes Mistrauen in mir wecken?!
Ich weiss nicht ob du das verstehen kannst, aber mir wäre es lieb wenn du erklären könntest WAS genau jetzt dein Misstrauen weckt.
Ach ich weiß nicht, vielleicht der Ratschlag, Compilerwarnungen zu ignorieren oder "es kann sein, dass irgendwas nicht geht". Auf sowas baue ich kein Software-Projekt auf. Im übrigen steht in der MSDN ganz genau drin, unter welchen Umständen eine Klasse nicht geshared werden kann, ohne Datenkorruption zu riskieren. Da erscheint der Rat, die Warnungen zu ignorieren wie Hohn. Wenn ich mich nicht darauf verlassen kann, dass es funktioniert, dann ist es nutzlos.
Hör mal auf mir hier Sachen zu unterstellen die ich nie gesagt habe.
Was Datenkorruption angeht - das hat genau nix mit den Warnings C4251 und C4275 zu tun. Aber hallo, Newsflash: die Möglichkeit hast du bei "dllexport" Klasse IMMER sobald die Implementierung in der DLL sich geändert hat. Sobald zu z.B. sizeof(T) veränderst .... boom.
Also musst du nun ganz aufhören C++ Klassen aus DLLs zu exportieren, weil alles andere wäre ja höchst unprofessionell und keine Basis auf der man Projekte aufbauen kann.Also laber mich mal bitte nicht voll mit so halb-schlauen Aussagen die komplett an dem vorbeigehen was ich gesagt habe bzw. meine Aussagen verzerren.
Die Möglichkeit von Datenkorruption/-verlust hat NICHTS mit den hier diskutierten Warnings zu tun. Und dass ein Programm mal nicht linkt ist ja wohl echt nicht die Tragik.
-
Jester schrieb:
Was macht ihr mit den vielen Permutationen dann? Werden die tatsächlich alle ausgeliefert und für den Kunden die jeweils passendste gewählt, oder nehmt ihr die, die im Durchschnitt über die Systeme die beste Performance liefert?
Je nachdem wovon und fuer welche plattform liefern wir die permutationen aus.
einfaches beispiel ist 32/64bit/Konsolen D3D9/D3d10
komplexeres beispiel waeren shader, ShaderModel 2a, SM2b, SM3, PS3, X360 und das wie du gesagt hast "Oder kompilierst Du tatsächlich die Anwendung vor jeder Benutzung, um sie auch auf die aktuelle Systemauslastung hin zu optimieren", nur sind die binaries schon fertig compiliert, fuer die anwendungsfaelle angepasst.
die komplexitaet dabei ist so hoch, dass es fuer viele Parameter kein deterministisches vorgehen gibt, bei manchen gibt es nichtmal ne naehrung, sondern man probiert n-permutationen durch und schnappt sich die beste, obwohl die ganze Umgebung komplett transparent ist.
Und wie ich schon sagte, kann man viele optimierungen nicht ohne die finale Testumgebung machen, denn manche Shaderbinaries muessen von der statischen analyse her schlechter sein um am ende schneller zu werden.
-
hör mal auf mir hier Sachen zu unterstellen die ich nie gesagt habe.
Was denn? Bist du nicht der Meinung, dass mann diese "dummen Warnungen" ignorieren sollte? Ich habe gesagt, dass mich dieser Ratschlag mistrauisch macht und jetzt heißt es, ich unterstelle dir, irgendwelche Sachen gesagt zu haben... vielleicht solltest du dich stattdessen einfach deutlicher ausdrücken.
hustbaer schrieb:
Was Datenkorruption angeht - das hat genau nix mit den Warnings C4251 und C4275 zu tun.
Diese Behauptung ist ziemlich strange, in der MSDN dreht sich bei der Beschreibung dieser warning alles um Datenkorruption. Von daher halte ich es nicht für abwegig, diesen Zusammenhang hergestellt zu haben.
Aber hallo, Newsflash: die Möglichkeit hast du bei "dllexport" Klasse IMMER sobald die Implementierung in der DLL sich geändert hat.
Es ist nicht immer offensichtlich wann sich die Implementierung einer Klasse ändert. Es geht darum, dass es von Anfang an unter bestimmten Umständen nicht sicher ist, wofür diese Warnings gedacht sind. Es ändert sich ganz leicht das Layout von Datenstrukturen, stellt mal _SECURE_SCL=0 ein, plötzlich ist sizeof(vector) und sizeof(vector::iterator) unterschiedlich. Amsonsten kann es passieren, dass wenn man zum Beispiel eine Klasse, die einen vector enthält, shared, und der Clientcode Instanzen davon kopiert, Daten korrumpiert werden, wenn das Layout von vector nicht gleich ist. So ein Problem muss man umgehen, indem man die Implementierung in eine abgeleitete Klasse verlagert, welche man nicht shared, oder nur einen Pointer auf den vector speichert, so dass die gesamte Implementierung des vectors auf die DLL begrenzt ist und das Layout der Klasse im Speicher gleich bleibt. Das sind unangenehme workarounds und DAS ist nicht gut. Nichts anderes habe ich auszusetzen gehabt. Diese Warnungen sind nicht "dumm", sondern total berechtigt und nicht ohne Grund Level 1.
Also musst du nun ganz aufhören C++ Klassen aus DLLs zu exportieren, weil alles andere wäre ja höchst unprofessionell und keine Basis auf der man Projekte aufbauen kann.
Sorry, es wird jetzt langsam total lächerlich. Ich weiß nicht, wo du diese verzerrte Aussage jetzt genau hergenommen hast, von mir stammt sie nicht. Ich habe gesagt, dass man unter bestimmten Umständen Datenkorruption riskiert und diese Umstände sind eine Spur häufiger vorhanden als angenehm. Es reichen verschiedene Compiler- und Linkereinstellungen völlig aus und es reicht aus, wenn sie sich auf Implementierungsdetails einer Klasse beziehen. Wenn man sie unbedacht einsetzt, dafür sind diese Warnungen gedacht. Du hast empfohlen, sie zu ignorieren und dagegen setze ich mich heftig zur Wehr.
Also laber mich mal bitte nicht voll mit so halb-schlauen Aussagen die komplett an dem vorbeigehen was ich gesagt habe bzw. meine Aussagen verzerren.
Das ist dir ja jetzt zum Glück überhaupt nicht passiert.
Die Möglichkeit von Datenkorruption/-verlust hat NICHTS mit den hier diskutierten Warnings zu tun.
Das ist eine Wiederholung deiner unbewiesenen Behauptung von oben.
Kann ich nur erwidern.
-
Ich finde jede Programmiersprache hat seine Stärken und seine Schwächen. Java verwendet im Gegensatz zur Programmiersprache C++ die Hotspot-Technik, mit dem sich Quelltexte schneller in Bytecodes übersetzen lassen. Unter Hotspot versteht man, dass nur die komplexen Anweisungsblöcke kompiliert werden, also die heißesten Stellen; daher auch der Name. Die restlichen Anweisungen werden interpretiert, also Zeile für Zeil, bei jeder Ausführung, neu übersetzt. Das ist auch einer der Gründe, warum Java schneller arbeitet als früher. Dies bedeutet aber nicht das C++ nicht so schnell arbeitet wie Java, weil C++ nur die Kompilier-Variante kennt.
Java ist zwar eine moderne Programmiersprache, da sie eine rein objektorientierte Programmiersprache ist. Aber, es bietet nicht das, was C++ bietet. Zum Beispiel verzichtet Java auf Zeiger, das stärkste Werkzeug. Einige Java-Programmier denken, dass Referenzen sicherer sind als Zeiger. Ich finde man sollte Zeiger nicht mit Referenzen gleichsetzen. Zeiger speichern im Gegensatz zu Referenzen die Speicheradressen. Referenzen sind nichts anderes als Aliasnamen, die für eine andere Variable oder anderes Objekt stehen.
C++ finde ich besser als Java, weil man damit richtige ausführbare Dateien erzeugen kann. Um Java Programme ausführen zu können, muss man die virtuelle Maschine starten, das nichts weiter ist als ein Programm, indem alle Anweisungen definiert sind und sie nur darauf warten durch den Bytecode aufgerufen zu werden.
Zwar ist es mit der virtuellen Maschine nett gemeint, da man Quelltexte nicht für jedes System neu übersetzen muss, aber ich finde C++-Programme sind viel kompakter und gehen mit Speicheressourcen viel sparsamer um, als ein Java-Programm in Kombination mit der virtuellen Maschine.
-
Referenzen sind nichts anderes als Aliasnamen, die für eine andere Variable oder anderes Objekt stehen.
Ich glaube nicht, dass das auch auf Javareferenzen zutrifft, nicht umsonst gibt es in C++/CLI eigene Objektzeiger, welche die Referenzen von C# darstellen sollen. Ich glaube Javas Referenzen sind näher an C++ Zeigern, als an C++ Referenzen, man kann halt nur keine Zeigerarithmetik mit ihnen betreiben und somit auf ungültige Addressen(außer null) zugreifen.
aber ich finde C++-Programme sind viel kompakter
Wirklich? C++ Programme kommen doch üblicherweise mit viel mehr Libs u.s.w.
Ich finde es irgendwie lustig, wie so eine Diskussion immer noch soo viele Seiten haben kann.
-
stefan2008 schrieb:
Ich finde jede Programmiersprache hat seine Stärken und seine Schwächen. Java verwendet im Gegensatz zur Programmiersprache C++ die Hotspot-Technik, mit dem sich Quelltexte schneller in Bytecodes übersetzen lassen.
Da verwechselst du was. Hotspot hat mit Quelltext in Bytecode übersetzen nichts zu tun. Das macht der Java-Compiler. Hotspot sorgt in der VM dafür, dass Bytecode in Maschinencode der Zielplattform übersetzt und so schneller ausgeführt wird.
Auch ist es falsch pauschal zu sagen, dass Java Hotspot-Technik benutzt. Das ist nur ein Implementierungsdetail bestimmter Laufzeitumgebungen. Früher wurde z.B. alles interpretiert.Java ist zwar eine moderne Programmiersprache, da sie eine rein objektorientierte Programmiersprache ist.
Java ist auch eine Hybridsprache, zwar ist es nicht so schlimm wie C++, aber primitive Datentypen gibt es hier auch. Vollständig OO sind z.B. Smalltalk und Ruby.
Aber, es bietet nicht das, was C++ bietet. Zum Beispiel verzichtet Java auf Zeiger, das stärkste Werkzeug.
Ein starkes Werkzeug, sich selbst in den Fuß zu schießen.
Einige Java-Programmier denken, dass Referenzen sicherer sind als Zeiger.
Ich hoffe doch, dass das die meisten denken.
Zwar ist es mit der virtuellen Maschine nett gemeint, da man Quelltexte nicht für jedes System neu übersetzen muss, aber ich finde C++-Programme sind viel kompakter und gehen mit Speicheressourcen viel sparsamer um, als ein Java-Programm in Kombination mit der virtuellen Maschine.
Das ist sicherlich richtig, aber Speicher ist billig. Die Vorteile, die mit einer vermeindlich ressourcenhungrigen Laufzeitumgebung erkauft werden, gleichen die Nachteile mehr als aus.
-
stefan2008 schrieb:
...Zum Beispiel verzichtet Java auf Zeiger ...
Nö - es verzichtet nur auf Zeigerarithmetik.
Ansonsten sind Java-Referenzen genau C++-Zeiger - mit ihren Schwächen (können ins Nirvana zeigen, können falsch gecastet werden, ...).
Einzige das Laufen in einer VM lässt einige Effekte dieser Probleme anders aussehen - was aber auch eher nichts mit der Sprache an sich zu tun hat, weil Dich niemand daran hindert, ein C++-Programm in einer VM laufen zu lassen, die sich exakt genauso verhält.Gruß,
Simon2.
