Unterschiede C++/C#
-
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
-
Michael E. schrieb:
Wie kann etwas schneller als Assembler sein, wenn es in selbiges übersetzt wird?
Das ist die "normale" Logik die eigentlich jeder nachvollziehen kann, aber hier gibt es ein paar Typen (Gregor) die meinen nur sie haben Ahnung.
-
Meint ihr es gibt irgendwanneinmal ne Plattform deren Maschienencode Java Byte Code sein wird?
Sowas sollte mit FPGAs möglich sein: http://www.jopdesign.com/
-
audacia schrieb:
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
Danke. Ich wollte es mir nur mal anschauen.
-
Annakin schrieb:
Michael E. schrieb:
Wie kann etwas schneller als Assembler sein, wenn es in selbiges übersetzt wird?
Das ist die "normale" Logik die eigentlich jeder nachvollziehen kann, aber hier gibt es ein paar Typen (Gregor) die meinen nur sie haben Ahnung.
Nein, die Logik ist nicht nachvollziehbar, auch wenn sie im Normalfall mit den Beobachtungen aus der Realität übereinstimmt.
1. Mit virtuellen Maschinen kann man im Prinzip bei vorliegender Laufzeitpolymorphie Inlining betreiben. Das heißt du hast die Vorteile von Inlining bei Strukturen, die nicht statisch zur Compilezeit gegeben sind. Soetwas ist eine typische Optimierungsmöglichkeit, die man ohne eine virtuelle Maschine nicht hat. Es gibt also technische Gründe, warum ein Programm mit virtueller Maschine schneller laufen könnte.
2. Viel wichtiger ist allerdings der menschliche Faktor. Programme werden von Menschen geschrieben. das gilt sowohl für Assemblerprogramme, als auch C++- oder Javaprogramme. Das gilt auch für Compiler und virtuelle Maschinen. Solange dieser menschliche Faktor im Spiel ist, kann man sich schonmal von optimalen Ergebnissen verabschieden. Das kann man noch in sehr kleinen, begrenzten Codebereichen erreichen, wenn es etwas komplexer wird, ist Optimalität aber nur eine ganz naive Wunschvorstellung, die oft mit anderen Zielen der Programmierer im Widerspruch steht. Wartbarkeit zum Beispiel. Entsprechend ist eine "Assemblerprogramme sind schneller"-Aussage auch nur eine naive Idealvorstellung, die nichts mit der Realität zu tun hat. Programme, die in Hochsprachen mehrere Millionen Zeilen Code haben, wird man gar nicht mit Assembler realisieren können. Diese Komplexität beherrscht kein Mensch.
Da Compiler, virtuelle Maschinen usw. auch von Menschen geschrieben werden, sind technische Argumente bezüglich der Performanz von Programmen, die in bestimmten Sprachen geschrieben wurden, weiterhin natürlich sehr mit Vorsicht zu genießen. Die meisten dieser Argumente spielen eine so geringe Rolle, dass sie gegenüber dem menschlichen Faktor beim Compiler oder bei der virtuellen Maschine irrelevant werden.
-
Von ARM gibt es bereits Prozessoren die zus. Java-Bytecode verstehen, das Feature nennt sich Jazelle.
-
Annakin schrieb:
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.Jaja, schon gut. Ich will dir ja nichts böses. Du bist die Kompetenz in Person, vor allem, wenn es um Java geht. Das sieht man schon an deiner qualitativ hochwertigen Bemerkung, dass es in Java keinerlei sprachliche Unterstützung für Mutithreading gibt. Hast du mich jetzt wieder lieb?
-
SirLant schrieb:
Meint ihr es gibt irgendwanneinmal ne Plattform deren Maschienencode Java Byte Code sein wird?
JStamp im Embedded-Bereich zum Beispiel:
-
Gregor: Gib's auf. Er ist der dunklen Seite der Macht verfallen und egal wie viele Argumente und Begründungen du noch liefern wirst, Annakin scheint mir äußerst uneinsichtig zu sein. Außerdem lässt er sich ständig über Dinge aus, von denen er keine Ahnung hat, beispielsweise Threading und angebliches Interpretieren von Bytecode in Java.
Warum postest du eigentlich nur noch unregistriert? Hat man dich wegen Ahnungslosigkeit schon gebannt?