Unterschiede C++/C#
-
Walli schrieb:
Nur mal so... Die MFC haben schon Multithreading-Funktionalität und ich glaube nicht, dass sich an denen noch großartig was ändern wird.
Ich kenne nicht alle Funktionen der MFC. Wenn die Funtionalität jetzt schon da ist, dann ist letztenendes die Mutlithreading Fähigkeit für C++ gegeben.
-
Die MFC stirbt aus. boost bietet aber mittlerweile recht schöne Klassen dafür, die auch auf verschiedenen Plattformen zum Einsatz kommen können.
-
Die Multicore-CPUs werden den Spielen keinen großen Performance-Zuwachs geben können. Was läuft denn parallel in einem Thread ab bzw. was ist denn prädestiniert dafür? Bisher ist das doch nur die Hintergrundmusik. Alles andere, wie 3D-Grafik, Logic, Player-Controlling usw. läuft in einem Thread ab. Die 3D-Grafik könnte man in einem separaten Thread auslagern, aber da muß man sich wirklich erstmal ein Synchronisationskonzept überlegen. Ich könnte da jetzt keines aus dem Stehgreif herzaubern. Denn immerhin ist die Grafik von der Game-Situation, und somit von den Aktionen des Spielers, der NPCs, Natur usw. abhängig. Das wird sehr schwierig alles in Threads auszulagern.
Intel hat deshalb mit renomierten Spieleentwicklern gesprochen wegen ihrer Multicore-Strategie. Fazit: keiner der Entwickler würde in nächster Zeit die Multicores unterstützen/ausnutzen können. Die sind froh wenn se Lösungen für die Dualcores hinbekommen. Bzw. mit dem Hyperthreading vom P4 hat man schon mal anfangen können.
-
ein honk schrieb:
Glaube ich nicht, da C++ binärer Code ist, während Java interpretierter Code ist.
Mit Java Grafikprogramme schreiben .. ne nie im Leben, immerhin benutzt das einen JIT-Compiler. Völlig unmöglich mit einem
JIT-Compiler Grafikprogramme halbwegs benutzbar zu machen, sagt einem doch schon der Hausverstand. Mehr Argumente
braucht man auch schon nicht mehr gegen Java, den wer weitere sucht hat noch immer nicht verstanden, dass man in C++ native
Programme schreibt. Hoffe ihr versteht jetzt warum Java C++ nie das Wasser reichen wird, der JIT-Compiler ist schuld.Hem, was hat der JIT mit grafik zu tun? Einfach sagen das JIT und Grafik nicht zusammen passen, kann ja jeder. Ich programmiere auf Arbeit viel mit Grafik wo auch der Benutzer mit dieser interagieren kann. Alles kein Problem.
-
ein honk schrieb:
Hem, was hat der JIT mit grafik zu tun? Einfach sagen das JIT und Grafik nicht zusammen passen, kann ja jeder. Ich programmiere auf Arbeit viel mit Grafik wo auch der Benutzer mit dieser interagieren kann. Alles kein Problem.
Und ich dachte, ich spar mir die [ironie] Tags ..
-
Annakin schrieb:
Ich kenne nicht alle Funktionen der MFC. Wenn die Funtionalität jetzt schon da ist, dann ist letztenendes die Mutlithreading Fähigkeit für C++ gegeben.
irgendeine beknackte windows-lib ist dafür sicher kein maßstab.
aber wie schon gesagt gibt es ja boost...
-
Artchi schrieb:
Die Multicore-CPUs werden den Spielen keinen großen Performance-Zuwachs geben können. Was läuft denn parallel in einem Thread ab bzw. was ist denn prädestiniert dafür? Bisher ist das doch nur die Hintergrundmusik. Alles andere, wie 3D-Grafik, Logic, Player-Controlling usw. läuft in einem Thread ab. Die 3D-Grafik könnte man in einem separaten Thread auslagern, aber da muß man sich wirklich erstmal ein Synchronisationskonzept überlegen. Ich könnte da jetzt keines aus dem Stehgreif herzaubern. Denn immerhin ist die Grafik von der Game-Situation, und somit von den Aktionen des Spielers, der NPCs, Natur usw. abhängig. Das wird sehr schwierig alles in Threads auszulagern.
Intel hat deshalb mit renomierten Spieleentwicklern gesprochen wegen ihrer Multicore-Strategie. Fazit: keiner der Entwickler würde in nächster Zeit die Multicores unterstützen/ausnutzen können. Die sind froh wenn se Lösungen für die Dualcores hinbekommen. Bzw. mit dem Hyperthreading vom P4 hat man schon mal anfangen können.
Die Spieleentwickler werden schon Lösungen dafür finden. Letztendlich kommen Mehrkernprozessoren und wenn die da sind, dann ist der im Nachteil, der sie nicht ausnutzt. Und im Nachteil will ja nun keiner sein.
Ich weiß auch gar nicht, warum die immer nur Semantisch unterschiedliche Bereichein andere Threads auslagern wollen. Man kann doch auch auf anderer Ebene parallelisieren. Stell dir ein Echtzeitstrategiespiel mit ein paar tausend Einheiten vor. Das heißt für mich, dass an dieser Stelle ein paar tausend mal das Gleiche gemacht werden muss. Hört sich IMHO nach einer super Stelle für Parallelisierung an. Und solche Massen an gleichartigen Dingen findet man doch in Spielen überall.
Naja, mag sein, dass ich da eine sehr naive Herangehensweise habe. Ich habe da keine wirkliche Erfahrung. Zumindest sehe ich zu Multithreading keine Alternative. Der Kurs der Hardwarehersteller steht diesbezüglich AFAIK fest und ist auch einheitlich: AMD geht den gleichen Weg.
-
maximAL schrieb:
Annakin schrieb:
Ich kenne nicht alle Funktionen der MFC. Wenn die Funtionalität jetzt schon da ist, dann ist letztenendes die Mutlithreading Fähigkeit für C++ gegeben.
irgendeine beknackte windows-lib ist dafür sicher kein maßstab.
aber wie schon gesagt gibt es ja boost...Du hast den Dialog mit Gregor@home nicht verfolgt.
Gregor hatte argumentiert das es kein Multithreading unter C++ gibt.
Ich hatte daraufhin geantwortet das es Libs gibt oder geben wird die genau dieses machen.
Um einen Maßstab ging es mir dabei nicht.
-
maximAL schrieb:
Annakin schrieb:
Ich kenne nicht alle Funktionen der MFC. Wenn die Funtionalität jetzt schon da ist, dann ist letztenendes die Mutlithreading Fähigkeit für C++ gegeben.
irgendeine beknackte windows-lib ist dafür sicher kein maßstab.
aber wie schon gesagt gibt es ja boost...Ja, der eine hält dies für den Standard, der andere das. Du kannst ja auch Qt statt MFC nutzen. Dann hast du keine Windows-Bibliothek, sondern bist plattformübergreifend und hast dir trotzdem eine andere Lösung als Boost ins Haus geholt. Das Problem ist aber eben, dass nur der Standard der Standard ist. Solange der keine entsprechende Lösung bietet, gibt es von allerlei Leuten allerlei Lösungen, die sicherlich nicht alle ganz einfach unter einen Hut zu bringen sind.
-
Artchi schrieb:
Die Multicore-CPUs werden den Spielen keinen großen Performance-Zuwachs geben können. Was läuft denn parallel in einem Thread ab bzw. was ist denn prädestiniert dafür? Bisher ist das doch nur die Hintergrundmusik. Alles andere, wie 3D-Grafik, Logic, Player-Controlling usw. läuft in einem Thread ab. Die 3D-Grafik könnte man in einem separaten Thread auslagern, aber da muß man sich wirklich erstmal ein Synchronisationskonzept überlegen. Ich könnte da jetzt keines aus dem Stehgreif herzaubern. Denn immerhin ist die Grafik von der Game-Situation, und somit von den Aktionen des Spielers, der NPCs, Natur usw. abhängig. Das wird sehr schwierig alles in Threads auszulagern.
Intel hat deshalb mit renomierten Spieleentwicklern gesprochen wegen ihrer Multicore-Strategie. Fazit: keiner der Entwickler würde in nächster Zeit die Multicores unterstützen/ausnutzen können. Die sind froh wenn se Lösungen für die Dualcores hinbekommen. Bzw. mit dem Hyperthreading vom P4 hat man schon mal anfangen können.
Mittel bis langfristig werden sich die Spieleprogrammierer da Gedanken machen müssen. Prozessoren mit nur einem Kern werden über kurz oder lang an ihre (physkalischen) Grenzen stossen.
Die einzige Möglichkeit dann noch mehr Leistung herauszuholen sind Multiprozessoren-CPU und damit Multithreading.
Es sei denn man erfindet ein komplett andere Technik (mit Licht z.B.), aber das ist Zukunftsmusik.
Und um immer mehr Geschwindigkeit geht es ja letzten endes bei CPU´s.
Die Spieleprogrammierer werden diese Technik schon nutzen.
-
Annakin schrieb:
Gregor hatte argumentiert das es kein Multithreading unter C++ gibt.
Nein. Ich hatte argumentiert, dass Multithreading von der Sprache ansich nicht unterstützt wird. Das heißt nicht, dass es unmöglich ist. Du kannst auch mit Assembler objektorientiert programmieren. Es ist nur nicht so praktikabel.
Natürlich kannst du irgendwelche externen Bibliotheken nutzen. Die ersetzen eine sprachliche Unterstützung für das Multithreading aber nicht bzw. nur sehr bescheiden.
-
Gregor@Home schrieb:
Annakin schrieb:
Gregor hatte argumentiert das es kein Multithreading unter C++ gibt.
Nein. Ich hatte argumentiert, dass Multithreading von der Sprache ansich nicht unterstützt wird. Das heißt nicht, dass es unmöglich ist. Du kannst auch mit Assembler objektorientiert programmieren. Es ist nur nicht so praktikabel.
Natürlich kannst du irgendwelche externen Bibliotheken nutzen. Die ersetzen eine sprachliche Unterstützung für das Multithreading aber nicht bzw. nur sehr bescheiden.
Na ja, wenn du das so siehst hast du mit java auch keine sprachliche Unterstützung für Multithreading.
es gibt eine klasse die das Multithreading unterstützt, was in etwa das Java gegestück zur lib ist.
-
Mal ne andere sache hat jemand mal einen Link für Qt (Windows)?
In der Linksammlung ist keiner vorhanden.
-
Annakin schrieb:
Mal ne andere sache hat jemand mal einen Link für Qt (Windows)?
http://www.trolltech.com/products/qt/windows.html
Für Windows muß man aber AFAIK eine Lizenz kaufen; eine Open-Source-Variante wird es erst mit der Version 4 geben.
Moritz
-
Annakin schrieb:
Na ja, wenn du das so siehst hast du mit java auch keine sprachliche Unterstützung für Multithreading.
es gibt eine klasse die das Multithreading unterstützt, was in etwa das Java gegestück zur lib ist.Red nicht so viel, wenn du keine Ahnung hast.
Es gibt in Java zum Beispiel das synchronized-Schlüsselwort, um zum Beispiel anzugeben, dass in der Abarbeitung einer Methode kein anderer Thread aktiv werden darf.
-
Ja ok. aber dann schießt sich der java code sowieso ins out. Hattet natürlich recht hab keine ahnung von java und virtual maschine... aber mann kann ja nicht alles können... naja warum ich so begeistert bin von inline + template in kombination?? hab ich glaub ich schon erklärt und wärst nicht glaub der glaubts halt eben nicht... nicht mein problem. Aber er sollte nicht dumm reden (supercodes) denn wie gesagt gibt es so "Supercodes" Hab mich angefangen für sowas zu interessieren wie ich auf flipcode gestöbert hab...
Ja ok. Ich gebe zu an asm templates hab ich nicht gedacht... aber die sind glaub ich recht schwer zu verwenden da ist c++ glaub ich doch die schnellere wahl und es kommt im endeffekt auf genau dieselbe leistung in dem beispiel.
cu Manuelh87 (antwort ist wahrscheinlich eh nichtmehr aktuell)
-
Wie kann etwas schneller als Assembler sein, wenn es in selbiges übersetzt wird?
-
Manuelh87 schrieb:
Ja ok. aber dann schießt sich der java code sowieso ins out. Hattet natürlich recht hab keine ahnung von java und virtual maschine... aber mann kann ja nicht alles können... naja warum ich so begeistert bin von inline + template in kombination?? hab ich glaub ich schon erklärt und wärst nicht glaub der glaubts halt eben nicht... nicht mein problem. Aber er sollte nicht dumm reden (supercodes) denn wie gesagt gibt es so "Supercodes" Hab mich angefangen für sowas zu interessieren wie ich auf flipcode gestöbert hab...
oh junge...
1. man braucht kein inline schlüsselwort damit der compiler inlined, in c++ hält sich der compiler eh nur selten and as schlüsselwort und inlined da was passt. genau dasselbe kannst du in jeder sprache machen, gejittet oder nicht ist da völlig egal. Java kann das auch.
ein weiterer punkt ist, dass java nicht so sehr auf templates angewiesen ist wie c++! in java programmiert man ja leicht anders...
ch hab schon codes gesehen wo mithilfe von templates und inline der compiler von c++ dazu gebracht wurde code zu erstellen der !besser! ist als die gleiche funktion in asm.
Und das ist ja das absolute nonplusultra deiner kommentare
wenn der ASM-programmierer gut ist, dann kann der c++ compiler einpacken! Der Compiler tut ja auch nichts anderes als C++ code in ASM zu übersetzen, dh er kann maximal ein gleich schnell erreichen, wenn der ASM-programmierer keinen fehler macht.Und dann noch zu deinem kommentar" c++ ist meiner mienung nach noch ne etage tiefer als java.".
Den kann man auch in die Tonne kloppen! Der jitter zieht extrem viele vorteile aus dieser höheren Ebene, da er den Code beim laufen betrachtet, er kann also auch etwas mehr über den groben zusammenhang herausbekommen als der C++ compiler, und damit auch größere optimierungen betreiben(der c++ compiler macht fast nur mikro optimierungen)
-
Ist doch klar Maschienencode ist schneller als Assembler, weil der Assemblercode muss er noch assembliert werden :p
Es gibt in Spiele doch auch andere Dinge die man in nen Thread verlagern kann, z.B. das Laden von Leveln damit man keine Ladepausen mehr hat, oder das aus- und einlagern von (nicht) benötigten Daten.
Ich frage mich immer weshalb viele C++ Programmierer sich angepisst fühlen, wenn sie sich anhören müssen, dass Java teilweise fast genauso schnell wie ein c++ programm ist, ist doch super
Mir persönlich liegt Java auch nicht so, aber deswegen muss man die Leistungen doch nicht schlecht reden.
Meint ihr es gibt irgendwanneinmal ne Plattform deren Maschienencode Java Byte Code sein wird?
-
[quote="Gregor@Home"]
Annakin schrieb:
Red nicht so viel, wenn du keine Ahnung hast.
Es gibt in Java zum Beispiel das synchronized-Schlüsselwort, um zum Beispiel anzugeben, dass in der Abarbeitung einer Methode kein anderer Thread aktiv werden darf.Bis zu dieser Bemerkung hatte ich angenommen mit dir kann man vernünftig reden.
Moonlight hatte recht dein Ton läßt zu wünschen übrig.
Wenn man den Ton nicht waren kann sollte man sich nicht äußern.Bist ein toller Typ Gregor
