Ich versteh nicht wie WinXP das Multitasking managed ...

[Corpsman]

Hei Leutz,

Also generell weis ich schon was multitastking ist.

Aber.

Ich hab hier nen Intel 6800 Core Duo, also ein 2 Prozessor system. Ansich alles schön.

Nu ist mir klar das eine Verdopplung der Prozessoren <> Doppelte Geschwindigkeit ist.

Und daher rechne ich auch nicht damit das meine Programme dopppelt so schnell ablaufen.

Was mich nun aber doch verwundert:

Da starte ich den neuen Winrar, und entpacke. Man sieht im Tastkmanager auch das er eine CPU komplett Belegt.

Alles schön und gut ich starte meinen Flugsimulator für meinen Modellhubschrauber ( der ist recht alt und braucht nur eine CPU )

Was passiert das Ruckelt wie verrückt, obwohl laut Taskmanager die 2. CPU nix zu tun hat.

Das finde ich dann schon merkwürdig. Also bin ich mal hergegangen und habe im Prozessmanager das Betriebsystem dazu gezwungen meinen Simulator auf die zweite CPU zu legen. Ein Wunder, das Programm läuft wieder 1a.

Ansich toll ich hab die lösung des Problems. Aber warum bekommt win das nicht selbst hin ?

Kriegt der Windows Kernel das nicht hin die Prozesse so auf zu teilen das beide CPU's ausgelastet sind ?

Das müste dem Betriebsystem doch klar sein, das wenn eine CPU keucht und die andere sich langweilt , das man dann Prozesse auf die andere CPU auslagert ...

Naja, was haltet ihr davon, gibts da Lösungen ?

oder mus ich mir nu ein Programm schreiben mit dem ich die Prozesse selbst auf die CPUs verteilen mus ?

Die auslastung der einzelnen CPUs kann ich ja dank TClockEX schon auslesen ...

Bevor jemand fragt, ich nutze WinXP Pro Service Pack2

Corpsman

[Namenloser]

Ich hab oft das andere Problem. Ein Programm, das sehr viel Rechenleistung benötigt, wird dann immer zwischen den Kernen hin und hergeschoben, und belastet auf jedem der vier Kerne 25% Last statt auf einem 100%. Das dumme ist, dass das herumschieben auch Performance zu kosten scheint, denn immer wenn ich den Prozess per Taskmanager auf einen Kern zwinge läuft es schneller/ruckelfreier/besser. :roll:

[Corpsman]

@NamenLozer

Naja, speziell für dein Problem gibts hier im Forum irgendwo ein Programm das das löst.

Da hat mal jemand ein Frweeware teil gemacht, mit dem man schon form start angeben konnte welche CPU das gestartete Programm bekommen soll.

Mir fällt grad nur der name nicht mehr ein ...

[Lossy eX]

Ich denke das Problem liegt an den Programmen. Viele Programme benutzen QueryPerformanceCounter um Animationen etc. flüssig zu gestalten. Timebased Movement etc. ABER diese Methode ließt eine Tickvariable der CPU aus. Nur Dumm jede CPU hat einen eigenen Wert. Dieser Wert kann innerhalb der CPUs varrieren. Das bedeutet, wenn Windows das Programm auf eine andere CPU schaufelt, dann kann es sein, dass die verstrichene Zeit sogar negativ wird! Und dann ist es vollkommen klar, dass die Bewegung abgehackt ist, da der Zeitwert immer hin und her springt. Man kann aber auch Glück haben und es läuft ohne Probleme.

Für diesen Zweck gab es von AMD ein Programm namens "Dual Core Optimizer". Der sorgt dafür, dass die Tickvariablen angeglichen werden. Dann sollten die Programme vernünftig laufen und von Intel wird es so etwas auch geben denke ich.

Alternativ könnte man auch GetTickCount benutzen. Das ist ein Wert aus dem inneren von Windows und der ist nicht von der CPU abhängig. Lohnt sich aber von der Genauigkeit her auch nur wenn man nicht gerade 100-200 fps hat.

Corpsman: Windows weist deine Anwendung immer wieder eine andere CPU zu. Und bisher funktioniert das eigentlich recht gut. Wenn du mehr als eine CPU gleichzeitig benutzen möchtest wirst du um Thread nicht herum kommen.

NamenLozer: Das wechseln zwischen den CPU kostet so gut wie keine Zeit. Also das ist etwas worüber ich mir keine Gedanken machen würde. Ich denke es ist auch so etwas ähnliches wie oben beschrieben.

PS: Ich persönlich halte das expliziete Zuweisen einer Anwenung an eine CPU für nicht so gut. Wenn zwei Anwendungen auf die gleiche Idee kommen, dann laufen beide Anwendungen auf einer CPU und die restlichen 3 CPU eines Quadcoresystem langweilen sich. Was dann keine Steigerung sondern eine Performancehalbierung wäre.

[hathor]

Zitat:

Zitat von Lossy eX

NamenLozer: Das wechseln zwischen den CPU kostet so gut wie keine Zeit...

10 msec sind für Dich KEINE Zeit?

[SaFu]

Da gab es mal einen Bericht in der Ct wie man das Optimieren kann müsste so 2 bis 2,5 Monate her sein. Da ging es genau um dieses Problem

[TeronG]

Zitat:

Zitat von Corpsman

@NamenLozer

Naja, speziell für dein Problem gibts hier im Forum irgendwo ein Programm das das löst.

Da hat mal jemand ein Frweeware teil gemacht, mit dem man schon form start angeben konnte welche CPU das gestartete Programm bekommen soll.

Mir fällt grad nur der name nicht mehr ein ...

Multicore launcher

[Lossy eX]

hathor: 10 Millisekunden sind für mich keine Zeit. ;) Für einen Switch ist das aber in jedem Fall eine ganze Menge. Mich würde interessieren wo du diesen Wert her hast?

Denn ich muss gestehen. Ich weiß nicht wie lange Windows für einen Wechsel braucht. Aber ich persönlich finde 10 Millisekunden dafür schon ein bisschen arg viel. Selbst wenn das Programm dadurch einen vollkommen jungfreulichen Cache vorgesetzt bekommt. Also so recht kann ich diesen Wert nicht glauben. Aber ich lasse mich gerne eines Besseren belehren!

10 Millisekunden kommen meiner Meinung nach dem gleich was ein Thread rechnen darf bevor der Scheduler einen anderen Thread ran lässt. Wobei ich das aber auch schon fast etwas viel finde.

Hier auf diesem System kann ich da leider nichts realistisch ausprobieren. Denn das ist ein Single Core P4 mit HT. Da erzeugen 2 Threads des Firefox jeweils ca 250-500 Context Wechsel pro Sekunde. Allerdings läuft eben das in diesem Prozessor auf Hardwareebene ab und verlässt den einen physischen Kern ja eben nicht. Werde aber zu hause mal was testen.

[Namenloser]

Zitat:

Zitat von Lossy eX

Ich denke das Problem liegt an den Programmen. Viele Programme benutzen QueryPerformanceCounter um Animationen etc. flüssig zu gestalten. Timebased Movement etc. ABER diese Methode ließt eine Tickvariable der CPU aus. Nur Dumm jede CPU hat einen eigenen Wert. Dieser Wert kann innerhalb der CPUs varrieren. Das bedeutet, wenn Windows das Programm auf eine andere CPU schaufelt, dann kann es sein, dass die verstrichene Zeit sogar negativ wird! Und dann ist es vollkommen klar, dass die Bewegung abgehackt ist, da der Zeitwert immer hin und her springt.

Ah, das kann natürlich sein. Ich hatte auch meistens Probleme mit ruckeligen Animationen und Bewegungen.

Aber allen Programmen schon beim Start einen Kern zuzuweisen kanns ja auch nicht sein. Denn dann hätte man ja wieder besagtes Problem, dass 3 rechenintensive Anwendungen auf einem kern laufen und die andern Däumchen drehen. Dafür habe ich mir eigentlich keinen Quadcore gekauft!

Was ich nicht verstehe, ist, wieso der Kernel nicht schlau genug ist einen prozess, der einen Kern zu 100% auslasten würde, eben auch genau auf einen Kern zu legen. Ganz egal wie groß oder klein der Overhead beim Verschieben ist, es kann logischerweise nie so schnell sein wie wie wenn der Prozess auf einem Kern bleibt.Mehr als 100%/Anzahl der Kerne kann ein Prozess die CPU doch sowieso nicht auslasten, und das Problem mit dem PerformanceCounter fiele dann auch weg. Wo soll da der Nachteil sein?

Gerade fällt mir ein, dass die Gif-Animationen im Firefox auch ab und zu (z.B. gerade eben) ruckeln. Vermute ich richtig, dass hier auch wieder der PerformanceCounter Schuld ist?


@fuknersascha:
Afair gab es in dem Artikel der c't aber keine Lösungs-/Optimierungsansätze. Oder gab es noch einen weiteren Artikel, den ich nicht gelesen habe?

[Lossy eX]

NamenLozer: Als Erstes eine kleine Richtigstellung. ;) Du sagst etwas von Prozess. Aber das ist nur bedingt richtig. Ein Prozess hat immer mindestens einen Thread. Und dieser Thread führt Code aus. Ein Prozess kann auch problemlos mehrere Threads haben und somit kann ein Prozess auch locker ein System mit 8 oder 16 Prozessoren komplett auslasten.

Der Scheduler sorgen dafür, dass alle Programme gleich behandelt werden. Natürlich gemäß ihrer Priorität. Und wenn der einem Thread beim Start eine CPU zuweisen würde dann könnte man das nicht mehr gewährleisten. Denn niemand kann wissen ob ein Thread nicht zufällig irgendwann mal was größeres berechnen will. Und das wäre den anderen Threads gegenüber nicht fair, wenn die zufällig auf der gleichen CPU liegen würden. Und somit wechseln die halt immer dahin wo gerade Rechenleistung frei ist. Und dann ist der Overhead beim Verschieben alle mal kleiner als wenn sie warten müssten. Zu mal der Scheduler auch nicht weiß wie viel der Thread gerade rechnen will. Egal ob es Millisekunden oder Minuten sind. Er ist darauf ausgelegt den Thread so schnell wie möglich wieder auszuführen. Nichts desto trotz. Wenn man Overhead vermeiden kann ist es immer schneller als wie mit dem Overhead.

Auf einer Seite gabs auch Kommentare und dort wurde auch das Thema Abwärme mit erwähnt. Wenn du ein Programm auf einem QuadCore an einen Kern bindest und dieses Programm 100% Last verursacht würde eine ziemlich ungleichmäßige Wärmeverteilung innerhalb des Prozessors entstehen. Also wärend ein Kern richtig viel Hitze erzeugt wären die Anderen nahezu kalt. Keine Ahnung ob das auch ein technischer Grund ist um die Leistung gleichmäßig zu verteilen. Aktuell hat NVidia bei einigen ihren Grafikchips (vornehmlich Notbooks) ein Problem da durch Wärmeschwankungen die Lebensdauer erheblich verkürzt werden kann. Artikel auf Heise.

Firfox und Gifs. Gifs sind nicht wirklich prikelnd weswegen ich da auch keine flüssigen Animation erwarten würde. Und ich denke da wäre ein Timer sinnvoller als eine Lösung über den Performance Counter. Und Timer sind normale Windowsbotschaften. Wenn da etwas anderes ein bisschen länger braucht, dann entsteht so schnell eine Verzögerung.