Reicht das für den FS10? :-)

[jeypee]

Original geschrieben von Vogelgerippe
Wolt ihr jetzschon ein neuen computer kaufen für den flugtsimulator 2010? würd ich nicht tun weil mann gar nicht weis was der brauch und so und mein bruder hat gesag das wo die graffikarte´egal ist aber arbeitspeicher superwichtihg.
schön blöd wer jetz nen computer kauft für den neuen fs!

Grafikkarte unwichtig?? Das glaube ich jetzt mal nicht, da der FSX für Windows Vista und DX10 optimiert sein soll, ist eine Grafikkarte sehr wohl wichtig, eine die DX10 beherrscht (gibts aber noch nicht). Zumindest wenn man nicht auf die "neuen" Grafikeffekte verzichten will.

Ich würde mir wünschen, dass auch aktuelle Grafikkarten noch eine gute Darstellung bieten. Vor allem was Beleuchtungs und Oberflächeneffekte angeht können derzeitige Karten bereits Erstaunliches, was nicht ansatzweise im FS2004 zu sehen ist. Man vergleiche nur mal aktuelle Shooter, basierend auf DX9.0c und Shader 3.0.

Und da ich auf den FSX Screenshots nichts ausergewöhnliches entdecken kann, was so nicht in vollem Umfang auch mit DX9 funktionieren würde, meine ich das ist nur wieder eine clevere Strategie von MS um der FS-Fanschaft das neue Windows Vista und DX10 raufzudrücken.
Lieber sollte MS mal zusehen, dass der FSX weg kommt von der CPU-Last und mehr Power aus den immer besser werdenden Grafikkarten schöpft.

[alfora]

Original geschrieben von jeypee
Und da ich auf den FSX Screenshots nichts ausergewöhnliches entdecken kann, was so nicht in vollem Umfang auch mit DX9 funktionieren würde, meine ich das ist nur wieder eine clevere Strategie von MS um der FS-Fanschaft das neue Windows Vista und DX10 raufzudrücken.

Wenn das die Strategie war, dann ist sie zumindest ab heute in die Hose gegangen. Windows Vista kommt nicht vor Jänner 2007 auf den Markt.

http://www.heise.de/newsticker/meldung/71116

Außer natürlich, dass Microsoft mit dem Erscheinungstermin "Holiday 2006" für den FSX eigentlich Weihnachten 2006 meint. Dann ginge es sich wieder aus. Aber dann wäre es erst recht sehr voreilig, JETZT einen neuen PC für den FSX zusammenstellen zu wollen.

[TurboTutone]

Original geschrieben von jeypee
Lieber sollte MS mal zusehen, dass der FSX weg kommt von der CPU-Last und mehr Power aus den immer besser werdenden Grafikkarten schöpft.

(Flug-)Simulationen sind grundsätzlich CPU-lastig, das ist kein Fehler der Programmierer. Eine Ausnutzung von Shader3.0 und allgemein Grafikeffekten (HDRR etc....) wäre auch für den FS10 wünschenswert, trotzdem müssen in einer Flusimulation in erster Linie Flugmodelle, Wetter, AI-Traffic etc. berechnet werden, und das ist halt Angelegenheit des Prozessors.
Eine Unterstützung von Dual-Core CPUs, vielleicht in Hinblick auf ein etwas realistischeres Flugmodell welches vom 2.Kern berechnet werden könnte, fände ich mal eine super Sache, da ist noch viel Raum für Optimierungen

[flightsim-at]

Ja, Dualcore-Unterstützung wäre echt eine enorme Optimierung für den FS.

Gerade beim FS würde sich das anbieten, da sich das Programm leicht in Prozesse unterteilen lässt.

z.b. Wetter, AI, Flugzeuge oder Terrainberechnung.

Doch leider geht das Gerücht um, dass auch der FS10 nicht von Dualcore profitieren wird. Das ist mir völlig unverständlich.

[Ben Voigt]

Original geschrieben von flightsim-at
Doch leider geht das Gerücht um, dass auch der FS10 nicht von Dualcore profitieren wird. Das ist mir völlig unverständlich.

das wäre in der tat mehr als bescheuert - aber warten wir mal ab

[Offtopic]
wie siehts bezüglich dual core bei x-plane aus? ist dort was in planung?
[/Offtopic]

MfG ben

[alfora]

Was ich überhaupt nicht verstehe ist, wie es eigentlich möglich ist, dass eine moderne Applikation auf einem modernen Betriebssystem KEINE Mehrfach-CPUs unterstützt.

Multitasking gibt's schon seit Jahrzehnten. Threads nicht ganz so lange aber auch schon eine geraume Zeit. Das heißt, es gibt schon seit vielen Jahren die Möglichkeit, in einem Programm Threads zu verwenden.

Der Compiler und die Laufzeitumgebung (Libraries und Betriebssystem) sollen sich doch bitte selbst um die Verteilung der Threads auf die vorhandenen CPUs kümmern.

[fs-simul]

Original geschrieben von alfora
Was ich überhaupt nicht verstehe ist, wie es eigentlich möglich ist, dass eine moderne Applikation auf einem modernen Betriebssystem KEINE Mehrfach-CPUs unterstützt.

Weil das nicht so einfach ist wie es oberflaechlich betrachtet aussieht.
Das faengt an bei der 3D Schnittstelle die dafuer nicht ausgelegt ist. Alle Daten die zur Grafikkarte ueber die DirektX Schnittstelle gehen muessen beispielsweise erst in einem Thread gesammelt werden. Und innerhalb des Programmes ist es nicht damit getan alle moeglichen Aufgaben auf Threads zu verteilen. Das kostet auch entsprechenden Verwaltungsaufwand der kontraproduktiv waere wenn der Gewinn durch die sich tatsaechlich parallelisierbare Arbeit zu gering ausfallen wuerde. Um parallel arbeiten zu koennen muss diese auch unabhaengig voneinander sein und dort wo es Synchronisationspunkte gibt oder Daten ausgetauscht werden muessen darf es keine groesseren Wartezeiten geben. Wenn ein Thread zu lange auf das Ergebniss eines anderen warten muss ist der durch das parallele arbeiten gewonnene Zeitvorteil schnell dahin. Auch das gegenseitige blockieren von Threads X wartet auf Y, Y auf Z und Z auf X (Deadlock) muss zuverlaessig verhindert werden. Um all dies muss sich der Entwickler kuemmern wenn sein Programm fehlerfrei laufen und entsprechend gut skalieren soll. Manche Algorithmen lassen sich grundsaetzlich nicht parallelisieren. Bei anderen muss man erst aufwendig entsprechende Abhaengigkeiten entkoppeln. Das setzt entsprechendes Know-How beim Entwickler vorraus welches oft nicht vorhanden ist. Hinzu kommt das die meisten Entwicklungs und Debuggingtools noch nicht fuer Fehlersuche und Optimierungen fuer parallel arbeitende Programme ausgelegt sind.
Am einfachsten ist es wenn es keine Abhangigkeiten gibt was in einigen Anwendungsgebieten bspw. beim Rendering, wo eine CPU z.B. die geraden Zeilen und eine andere die ungeraden Zeilen rendern kann, der Fall ist. Dort sind die Programme schon lange multiprozessorfahig und skalieren auch nahezu 100 Prozent mit der Anzahl der CPUs.
Beim FS ist die Sache wesentlich komplizierter obwohl dort sicherlich auch einiges Parallelisierungspotential drin steckt. Aber vermutlich muessten dazu auch viele Sachen von Grund auf neu programmiert werden.
Bis sich Multiprozessorunterstuetzung auf breiter Flaeche in Programmen durchgesetzt hat hast du vermutlich schon 6 oder mehr Prozessoren in deinem Rechner und dann bringen auch schon geringe Skalierungsraten einen signifikanten Gewinn.

[alfora]

Ich habe das Gefühl, Deine Antwort geht an meiner Frage vorbei.

Ich setze jetzt einmal voraus, dass Programmierer nicht grundlos Threads einsetzen sondern dort, wo sie einen Sinn haben. Es geht ja auch nicht um eine fast 100%ige Skalierbarkeit (so wie es bei komplett unabhängigen Aufgaben, wie dem Rendering, möglich ist) sondern um eine Aufteilung der Rechneraufgaben. Typischerweise wird das User Interface in einem Thread behandelt und die Business Logik in einem zweiten.

Ich gebe Dir auch vollkommen recht, dass sich manche Algorithmen nicht oder nur schwer parallelisieren lassen und dass sich Programmierer mit den Abhängigkeiten beschäftigen müssen.

Ein Flugsimulator gehört aber nicht zu diesen Algorithmen. Dort bietet sich die Aufteilung in Simulation und Graphikdarstellung ja geradzu an. Zwischen diesen beiden Teilen gibt es nur EINE Schreib-Lese-Abhängigkeit: die Simulation berechnet die neue Position und Fluglage und die Graphikdarstellung übernimmt sie, um die Sicht nach draußen zu berechnen.

Die Eingabe der Steuerbefehle, die Panels, der AI-Traffic, die ATC usw. sind alles Dinge, die auch in Threads abgebildet werden können. Auch hier liegen nur einfache Schreib-Lese-Abhängigkeiten vor. Aber bei allen bisher aufgezählten Threads muss NIE ein Thread auf den anderen warten. Es muss nur der jeweilige Schreibvorgang atomar erfolgen. Das Lesen wartet aber nie darauf sondern nimmt den Wert, der gerade da ist.

Ich will aber jetzt gar nicht auf eine Implementierung des Flugsimulators mit Threads eingehen. Mir geht es nach wie vor darum, wieso kann das Betriebssystem nicht diese schon vorhandenenThreads automatisch auf die CPUs aufteilen?

[fs-simul]

Original geschrieben von alfora

Ich will aber jetzt gar nicht auf eine Implementierung des Flugsimulators mit Threads eingehen. Mir geht es nach wie vor darum, wieso kann das Betriebssystem nicht diese schon vorhandenenThreads automatisch auf die CPUs aufteilen?

Also das Betriebsystem macht da ueberhaupt keine Probleme. Es ist in der Lage die einzelnen Threads auf die vorhandenen Prozessoren aufzuteilen und tut dies auch. Es liegt einzig und allein an der Anwendung die Aufgabe in entsprechenden Threads aufzuteilen. Die Problematik dabei hatte ich versucht zu erleutern.

[alfora]

Die Problematik dahinter ist mir klar. Ich versuche nur, die Aussage

Doch leider geht das Gerücht um, dass auch der FS10 nicht von Dualcore profitieren wird.

zu interpretieren.

Die bekannten Fakten, die Du ja auch so schön erklärt hast, sind ja:

* Threads werden vom OS unterstützt und auf vorhandene CPUs aufgeteilt
* Wenn Threads kommunizieren müssen, dann kann es keine Leistungssteigerung um 100% geben, wenn man statt einer jetzt zwei CPUs hat. Nur bei voneinander komplett unabhängigen Threads würde man eine Verdoppelung der Rechengeschwindigkeit erhalten.
* Diese Kommunikation und Synchronisation von Threads hat auch bei Single-CPUs Einfluss auf die Rechengeschwindigkeit. Das muss in jedem Fall bei der Programmierung berücksichtigt werden, egal ob MultiCore, Multiprozessor oder Single-CPU.

Soweit, so gut. Jetzt starte ich den FS9 an und sehe im Taskmanager 17 Threads. Es sind also genügend Threads da, die das Betriebssystem auf die CPUs aufteilen kann, oder nicht?

Möglichkeit A: Die Threads des FS9 sind so dumm programmiert und müssen so häufig miteinander kommunizieren und aufeinander warten, dass keine Leistungssteigerung bei MultiCores zu erwarten ist.

Möglichkeit B: Die Threads sind gut programmiert und können gut auf MultiCores aufgeteilt werden. Es gibt daher eine gute Leistungssteigerung von typischerweise 140%-170%.

Wenn ich jetzt versuche, die Aussage von ganz oben zu interpretieren, dann passt nur Möglichkeit A dazu. Dann weiß ich aber noch immer nicht, warum ich extra für MultiCores programmieren müsste. Ich muss ja schon bei Single-CPUs auf die Qualität meiner Threads achten, damit dort nicht zuviel Rechenleistung durch unnötige Kommunikation verbraten wird.