Dualcore Problem
 

Hab eine Frage.Ich habe nen AMD64 Dual Core Processor 4400+ und nen Abit AN832X Sli motherbord.Wen ich nun spiele zocke merke ich das nur der Eine prozessor auf 90 bis 100 Prozent läuft und der andere nur auf 3 Prozent.Da kann doch dan was nicht stimmen wenn dan das Spiel ruckelt obwohl der andere Prozessor noch loker 80 prozent mehr schafft.Ich habe 1.5 Gb ram daran könnte es nicht liegen.Apic ist bei mir aktiviert kann mir vielleicht jemand helfen die Fehlerquelle zu finden?
Gruß Florian

Hier nochmal das Bild dazu
http://img81.imageshack.us/img81/1540/problem9ip.jpg
Kann das irgenwie mit dem Flusi zusammenhängen, dass er Dualcore nicht unterstützt?

Öhm. Hatte ich nicht schon auf diese Frage geantwortet? :-)

>Kann das irgenwie mit dem Flusi zusammenhängen,
>dass er Dualcore nicht unterstützt?

Genau.

Jo hattest du schon habe ich nur in beiden Foren gepostet gehabt oder existiert der Bereich Hardware in beiden als der selbe?
Gruß Florian

Wenigstens wird FSX DualCore unterstützen (in welcher Form auch immer...)

Es gibt bis jetzt kaum Programme, welche den Dual Core wirklich miteinbinden!

Man merkt lediglich einen Performanceschub, wenn viele Programme gleichzeitig laufen.

Denke, wenn Vista kommt, wird diese Technik erst ordentlich einzubinden sein!

OK super Danke für deine Antwort ich hoffe auch sehr das der Neue FS dualcore unterstützt.Sonst hätte ich ein wirklich großes Problem,da ich sonst zu wenig Rechenpower habe.
Gruß Florian

Oops... hoffentlich tut er das...kann aber fast nicht anders sein...:confused:

Nun ja. Es hat eigentlich gar nichts mit dem Betriebssystem zu tun. Um in der Dosenecke zu bleiben: Windows NT 4 unterstützte bereits Mehrprozessor-Systeme. Für den Privatkonsumenten war es auch vollkommen uninteressant, da nicht bezahlbar.

Wie dem auch sei: Es bedarf für den Entwickler mehr als nur einen Schalter im Compiler umzulegen. Und er selbst ist dafür verantwortlich, welche Teile in seinem Programm "Mehrkerntauglich" sind und eben von dieser Umgebung im Ablauf profitieren.

Von daher: Warten auf FSX. Vista lohnt ja nicht wirklich - quält sich eh von einer Verzögerung zur nächsten.

Zu Vista:

Im Prinzip hast du natürlich recht. Natürlich wird der zweite Kern in den in früheren und aktuellen Microsoft Betriebssystemen mit eingebunden . Ich finde aber, ebenfalls als ein Besitzer eines Dualcores, dass diese Technik in Windows XP nur schwer zum tragen kommt.
Über die Win64bit Variante kann ich an dieser Stelle nichts sagen, ob diese ohne viel Aufwand besser damit läuft.
Ich musste viel Zeit investieren, Systempatches installieren etc., verschiedene Einstellungen durchprobieren, um letztlich einen wirklichen Unterschied zu meinem alten SingleCore-Cpu festzustellen zu können.

Mein Gedankengang ging auch eher dahin, dass Vista fähig ist, diese Technik, die ja warscheinlich in ein bis zwei Jahren Standard sein sollte, noch besser einzubinden. Man hörte ja unabhängig von der Mehrfach Cpu-Technik, dass Vista besonders für 3D Anwendungen eine verbesserte Performance liefern soll. Wenn es sich dabei nicht, um einen billigen und hintergrundlosen Werbespruch gehalten haben soll, wäre FSX in Verbindung zu Vista sicherlich empfehlenswert.

Quelle: http://www.gamespot.com/features/6143883/p-5.html

Wie gesagt, dies war nur ein Gedankenspiel. Lasse mich natürlich gerne des Besseren belehren.

Sorry Doppelpost

Eine Anwendung muss nicht für Dual-Core Prozessoren geschrieben sein, um von Dual-Core profitieren zu können, wenn die genutzen Bibiliotheken Dual-Core nutzen können.

Zudem gibt es durchaus Ansätze ala "Compilerschalter" die (wie gut auch immer) funktionieren. Leider weiss ich aber nicht, ob sich sowas auf dem komerziellen Markt findet.

Aber klar ist: Wenn alle Bibliotheken, das Betriebssystem UND die Anwendung selbst speziell darauf hin getrimmt wurden, dann bringt es natürlich am allermeisten.

Eine Anwendung muss immer expliziet fuer Multiprozessing geschrieben werden wenn sie davon tatsaechlich profitieren soll.
Mit einem Compilerschalter ist es nicht getan. Wenn es so einfach waere waeren alle Anwendungen schon lange multiprozessingfaehig. Damit bekommt man aber hoechstens eine Anwendung mit mehreren Threads hin die aber trotzdem noch keinen Gewinn bringt weil ein Thread auf den anderen warten muss und der tatsaechliche Rechenaufwand der Threads extrem asymetrisch verteilt ist. Auch der aktuelle FS besteht aus mehreren Threads.
Worauf es ankommt ist die Arbeit moeglichst gleichmaessig zu verteilen. Dazu muss man die Algorithmen auseinander nehmen und schauen wo welche Rechenlast entsteht. Einige Algorithmen lassen sich sowiso schon von der Theorie her niemals parallelisieren. Bei anderen muss man aufwendig die Abhaengigkeiten entkoppeln. Der Skalierungspotential wird deshalb bei den meisten Anwendungen daher auch weit von den moeglichen 100% entfernt sein welches bei einigen speziellen Anwendungen bspw. im Renderingbereich durchaus erreicht wird.
Was den FSX betrifft wuerde ich mir diesbezueglich keine allzu grossen Hoffnungen machen.

Es gibt nicht nur das Multithreading, welches man vom Rechner mit einem Prozessor kennt. Und es GIBT Programmiersprachen mit entsprechenden Compilern, bei denen man automatisch ein von der parallelen Architektur eines Rechners profitieren kann. Ich weiss nur nicht, ob es eine KOMMERZIELLE und KONKURRENZFÄHIGE Lösung gibt.

In der Tat ist man da immer weit von 100% entfernt. Genau 100% schafft man eh nicht, da immer ein - wenn vielleicht auch nur minimaler - Overhead durch die notwendige Kommunikation vorhanden ist.

Ich bin sicher dass Vista dem Trend zur Parallelität Rechnung trägt, und dass auch der FSX diezbezüglich profitiert (frage ist nur wie stark, sicher wird er nicht durch einen zweiten Prozessor / Kern auch doppelt so schnell. Die Sache an sich birgt jedenfalls sehr hohes Parallelisierungspotential.

Hättest Du dafür eine Referenz?
Mich würde das echt interessieren, wie's funktionieren soll! :)

Das müsste ja bedeuten, dass diese Sprache dann, ähnlich den Velocity-Engines für Number-Crunching, zwei auf einander folgende Befehle simultan ausführen kann - und das auch automatisch erkennen kann, was aber wieder ein Widerspruch ist, da der folgende Arbeitschritt von dem vorherigen abhängt. Oder wie darf man sich das vorstellen? Wie soll irgendwas automatisch für Multicores ausgelegt sein (seis durch Compiler-Flags), wenn Du erst durch die Programmierung explizit bestimmst, ob das Programm Multicore fähig sein kann (eine Mainloop für jeden Thread und die Kommunikation darum)?

Grüße,
Karsten

Da muss ich mal in meinen alten Unterlagen aus dem Studium und dort dem Seminar "Parallelrechner" raussuchen... ich schau mal ob ichs noch finde...

Soweit ich weiss basierte das darauf, dass bei bestimmten Vorgängen im Programm ja die Reihenfolge egal sein kann.

Beispiel: Ich muss 2 Dateien aus dem Internet runterladen und konvertieren, danach vergleichen. Dann kann das runterladen und konvertieren unabhängig ablaufen.

Vieles hängt auch an Bibliotheken. Ein Sort-Befehl kann so z.B. für parallel oder normal implementiert werden, und im kompilierten Produkt kann dann stehen

if 1 prozessor then
sortparallel
else
sortnormal
end

währen im Quelltext nur steht:
sort

Aber Bibliotheken waren damals noch nicht mal im Spiel.

Na ok, dann ist das Programm aber doch explizit für Multi-Core/Thread geschrieben. Aus heiterem Himmel fällt jedenfalls keine multithreaded Anwendung. ;)

Grüße,
Karsten

Denken wir mal nicht mit dem Wort multi-threading, sondern ganz allgemein an "parallele Abläufe", es müssen ja nicht Threads im landläufigen Sinne sein.

sortnormal und sortparallel sindsind ja nur mal Pseudocode, stellvertretend für irgendwelche Mikroprogrammme in Zielcode. Wenn du in einer einen bestimmte Quelltext schreibst, dann ist immer die die Frage, wie der Compiler das ganze dann in die Zielsprache übersetzt, die verwendeten Befehle im ! Die Programmiersprache ist ja nur Quellsprache. Maschinencode/Assembler ist dann die Zielsprache, und darin funktioniert das dann nach dem Prinzip wie oben im Pseudocode angegeben, d.h. in deinem Quellcode würdest du nur "sort" schreiben.

Nicht der Quellcode ist parallelisiert, sondern der Zielcode!