Unterschiede C++/C#
-
Annakin schrieb:
Oder einfach ein Lib die Funktionen fürs Multithreading zur Verfügung stellt?
Ist der Gedanke so abwegig?
Nein, ist er nicht. Gibt es ja auch. Boost und so. Allerdings ist das maximal eine Hilflösung mit dem Resultat, dass man in seinem Programm 5 Bibliotheken von anderen nutzt, die alle andere Ansätze diesbezüglich haben. Sowas führt dann natürlich zu Problemen.
-
Aber ist das heute denn anders?
Der ein benutzt die MFC´s, der andere irgendwelche Linux eigene Libs.
Wenn Microsoft sagen würde ich erweitere die MFC um Funktionen fürs Multithreading, würde das wahrscheinlich dazu führen das alle die Visual C++ benutzen, was sehr viele sind, die gleiche Lib fürs Multithreading nutzen würden.
-
Nur mal so... Die MFC haben schon Multithreading-Funktionalität und ich glaube nicht, dass sich an denen noch großartig was ändern wird.
-
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?