Dualcore Problem

[bvl]

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.

[fs-simul]

Original geschrieben von bvl
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.

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.

[bvl]

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.

[Karsten Krispin]

Original geschrieben von bvl
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.

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

[bvl]

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.

[Karsten Krispin]

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

[bvl]

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!