Reicht das für den FS10? :-)
 

Hallo!

ich war eben mal wieder bei NVIDIA gucken was so feines in der Planung ist. Da hab ich die ultimativen Hammer Grafikkarten Verbund für uns gefunden, das QUAD SLI System. Ist ja wirklich der Hammer was da in der Planung ist. Was ich mir nur schwer vorstellen kann, ist wie das komplett in nem PC umgesetzt wird. Ehe CPU & Co. für sowas bereit sind wird doch noch ne Weile vergehen oder was meint ihr?

Hier für alle nochmal der Link zu der ganzen Sache

http://de.slizone.com/object/slizone_quadsli_de.html

Ciao!
Sebastian

SLI ist ja schön und gut - bleibt aber immer noch die frage, INWIEWEIT der fs10 davon profitieren kann/wird. zumindest ist er in der link-liste (noch) nicht gelistet!

keine frage: die SLI-geschichte is inovativ, aber ich fürchte, dass die FS-simmer davon nur wenig "nektar saugen" können!

schade eigentlich!

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! :eek: :eek:

ein richtiges Ass
 

Dein Bruder muss ja ein richtiges Ass sein;
was der so alles weiß !!!! :eek:

Oder hast du ihn nur nicht richtig verstanden ? :heul:

:hallo:
Ned

Ich bin mir relativ sicher, dass der FS10 wieder sehr CPU limitiert ausfallen wird, d.h. ein SLI System wird keinen sehr großen Leistungsschub bringen.

Momentan gibt es wohl noch keine CPU, die ein Quad-SLI richtig ausreizt. Selbst ein standard SLI mit 2 7900GTX GraKas wird durch einen FX60 Prozessor wohl noch ausgebremst. Mal abwarten, wie die neuen Intel Conroes und die AMD CPUs auf Sockel AM2 abgehen;)
Hier sehe ich eher ein Leistungsplus fürn FS10.

Mal abwarten, bis der FSX verfügbar ist. Über Systemanforderungen zu spekulieren ist zwar zu Beginn ganz lustig aber irgendwann wird's fad.

Bei Computern hat es sich noch nie bewährt, "auf Vorrat" zu kaufen.

hi sebastian,

bei sli hast zwar 4 dvi-ausgänge, kannst aber nur einen davon nutzen. also nix da mit zweitem monitor für fsnav. ;)

Momentan sieht es bei SLI (rede vom normalen SLI, also 2 Grafikkarten, nicht von Quad) so aus, dass man bei einer niedrigen Auflösung mit SLI weniger Frames hat als ohne.
Erst ab 1600x1200 macht sich das bemerkbar ...

Liegt glaub ich daran, dass das Aufteilen auf 2 GraKas zusätzliche CPU Rechenzeit benötigt. Je niedriger die Auflösung, desto mehr wird die CPU zum limitierenden Faktor, darum ist SLI eher für sehr grafiklastige Anwendungen mit höchsten Auflösungen und Qualitätseinstellungen sinnvoll.

Die Antwort von Steve Lacey:

http://www.steve-lacey.com/blogarchi...mulato_6.shtml

Grüße

Thomas

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.

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. ;)

(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;)

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.

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

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.

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.

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?

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.

Die Problematik dahinter ist mir klar. Ich versuche nur, die Aussage
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.

Es ist sicher Variante A und Threads haben auch auf einem Single CPU System Vorteile naemlich dann wenn mehrere Sachen einfach "parallel" machen moechte. Die laufen dann aus CPU Sicht nicht wirklich parallel sondern bekommen vom Scheduler entsprechende Zeitscheiben zugewiesen. Das switchen zwischen den Threads erfolgt dann aber so schnell das es aus Sicht des Users praktisch parallel laeuft. Bspw. mochte man in einem GUI Menuefenster nicht unbedingt den weiteren Programmablauf blockieren bis die Eingaben dort abgeschlossen sind. Sie ermoeglichen also auch eine Form der strukturierten Programmierung ohne alles in einer riesigen unuebersichtlichen Schleife reinquetschen zu muessen. Dabei kann die anfallende CPU-Arbeit auch extrem asymetrisch verteilt sein. Ein GUI oder Eingabetread verbraucht vielleicht nur 0.1% CPU Last gegenueber der eingentlichen Rechenaufgabe des Programms folglich ist der Gewinn wenn man ihn parallel auf einer 2. CPU laufen lassen wuerde auch nur entsprechend gering.
Um wirklich Gewinn von Multiprozessorsystemen zu ziehen muss das Programm also Threads schaffen die die Gesamtarbeit auch wirklich moeglichst gut aufteilen.
Und dies bedeutet nichts anderes als zu schauen wo faellt welche Arbeit an und wo gibt es welche Abhaengigkeiten.