Das deutsche Python-Forum

Okay, Python ist nicht an eine CPU gebunden (Wenn ich drüber nachdenke, wieso sollte es?) - ein simples Testprogramm wechselt bei mir zwischen den zwei Kernen hin und her.

Noch offtopic'er: weil threads unter Java so viel nützlicher sind hat Sun ja sowas entwickelt: mit 8x8 Threads in Hardware

b.esser-wisser hat geschrieben:Okay, Python ist nicht an eine CPU gebunden (Wenn ich drüber nachdenke, wieso sollte es?) - ein simples Testprogramm wechselt bei mir zwischen den zwei Kernen hin und her.

Das ist wahrscheinlich dein Betriebssystem, dass versucht, die Prozessoren gleichmaessig auszulasten wg. der Hitze. Trotzdem benutzt Python nur einen Kern gleichzeitig, und darum geht es hier ja.

@Rebecca: nur ein Kern auf einmal war klar -- mir war nicht klar, dass trotzdem mehrere Kerne genutzt werden (z.B. sind dann einige Stromspar-mechanismen dahin)

Was den fuer Stromspar-Mechanismen? Ich war immer davon ausgegangen, dass die Kerne wegen der Waerme gewechselt werden, damit weniger gelueftet werden muss. Das spart schon Strom.

@b.esser-wisser: Dieser Frage schließe ich mich an: Welche Stromsparmechanismen meinst Du? Ich glaube nämlich nicht, dass da tatsächlich irgendetwas „dahin“ ist.

Z.B. Cool 'n' quiet, d.h. bei meinem Phenom II werden die Kerne im Leerlauf einzeln von 3100MHz bei 1,35V auf 800MHz bei 1,0V, runtergetaktet.
edit:
Oder auch einfach die ACPI-geschichten

@b.esser-wisser: Die automatische Anpassung der Frequenz an die Last ist nun kein Hexenwerk und schon lange üblich (egal, was die Hersteller für tolle Namen dafür erfinden). Nur warum sollte das „dahin“ sein, wenn das System Prozesse auf alle verfügbaren Kerne verteilt?

@lunar: Naja statt nur einen Kern auf hoher Taktfrequenz zu halten, werden dann halt `n` Kerne auf hoher Taktfrequenz gehalten, obwohl nur einer davon immer kurz rennt und wirklich etwas tut.

Ich meine, dass hier unnötig einzelne kerne 'aufgeweckt' werden, statt nur einen auf Vollast laufen zu lassen, im Prinzip wie hier, bei lesswatts.org. erklärt - ich finde nur auf die schnelle nichts konkreteres.

@BlackJack: Diese Behauptung ist nicht schlüssig, sondern eigentlich ziemlich unsinnig. Ein Kern läuft nur und ausschließlich dann mit hoher Taktfrequenz, wenn er tatsächlich etwas tut. Hat ein Kern nichts zu tun, weil es zum gegenwärtigen Zeitpunkt keine rechenwilligen Prozesse gibt, die diesen Kern zugewiesen werden könnten, so läuft der Kern nicht mit hoher Taktfrequenz (wieso sollte er auch?), sondern geht in einen Schlafzustand (welchen, hängt von Hardware und System ab).

Auch die Annahme, nur einen Kern mit hoher Frequenz laufen zu lassen, wäre sinnvoller, ist nicht begründet, denn die anstehenden rechenwilligen Prozesse und die Prozessorzeit, welche diese beanspruchen, wird ja nicht weniger, wenn man sie liegen lässt. Lässt man nur einen Kern mit hoher Taktfrequenz laufen, so wird eben mehr Zeit zur Abarbeitung der anstehenden Prozesse benötigt, der Kern muss also wesentlich länger in Zustand hoher Taktfrequenz laufen.

Verteilt man dagegen die anstehenden Prozesse auf alle Kerne, so werden zwar alle Kerne hochgetaktet, aber eben für einen wesentlich kürzeren Zeitraum, da ja mehr Prozesse gleichzeitig ausgeführt werden. Danach können alle Kerne gemeinsam wieder in einen Schlafzustand wechseln, oder zumindest in niedrigere Taktfrequenzen. Letztlich führt das dazu, dass die Kerne insgesamt mehr Zeit in niedrigen Taktfrequenzen oder im Schlafzustand befinden, weil anfallende Prozesse eben parallel und somit schneller ausgeführt werden.

@b.esser-wisser: Ich weiß nicht, was Du gelesen hast, aber die Behauptung, es wäre besser, nur einen Kern auf Volllast laufen zu lassen, anstatt mehrere Kerne aufzuwecken, steht jedenfalls nicht ich dem von Dir verlinkten Artikel.

@lunar: Wenn es zum Beispiel zwei Kerne gibt, die immer abwechselnd 100 Bytecodes ausführen, dann laufen letztendlich beide und keiner hat genug Zeit sich zwischenzeitlich mal "schlafen" zu legen. Das es nichts mehr zu tun gibt, wird ja dadurch erkannt, dass ein Prozessor eine gewisse Zeit in der Idle-Schleife steckt und der Scheduler halbwegs sicher sein kann, dass der Prozess/Thread *wirklich* nichts mehr zu tun hat. Denn ständiges Taktfrequenzwechseln ist auch nicht "kostenlos" zu haben. Kann natürlich auch passieren, dass man in das gegenteilige Problem rennt -- dass die 100 Bytecodes nicht lang genug sind um den Scheduler zu veranlassen die Taktfrequenz hoch zu setzen. Dann dauert es auf mehreren Kernen länger als wenn es nur auf einem, dafür aber mit Volldampf laufen würde.

Das mit dem parallel Ausführen geht ja mit CPython Bytecode nicht. Also hat man entweder für eine Zeit lang einen Kern beschäftigt, oder für die gleiche Zeit mehrere Kerne. Das sollte doch dann auch mehr Strom verbrauchen.

@BlackJack: Speziell für CPython ist das sicherlich richtig, so dass es nicht sehr effizient ist, CPython-Prozesse auf mehrere Kerne zu verteilten. CPython ist allerdings aufgrund seiner exzessiven Sperre sicherlich nicht der Maßstab für Mehrkernsysteme. In den meisten anderen Fällen können verschiedene Prozesse tatsächlich auch echt parallel laufen, in welchem Fall es effizienter ist, diese auf alle verfügbaren Kerne zu verteilen.

Die Behauptung, die Verteilung von Prozessen auf mehrere Kerne wäre nicht sinnvoll, gilt zwar für CPython, aber für Prozesse im Allgemeinen ist das Gegenteil korrekt. CPython hat aufgrund des GIL spezielle Eigenschaften, aber der Scheduler des Systems kann einzelnen Programmen keine Sonderbehandlung angedeihen lassen.

BlackJack hat geschrieben:@lunar: Wenn es zum Beispiel zwei Kerne gibt, die immer abwechselnd 100 Bytecodes ausführen, dann laufen letztendlich beide und keiner hat genug Zeit sich zwischenzeitlich mal "schlafen" zu legen.

Meine jetzige Betriebssystem-/Hardware-Kombination macht das uebrigens nicht, da laeuft der Prozess die ganze Zeit auf einem Kern. :K Meine vorherige Betriebssystem-/Hardware-Kombination hat die Kerne gewechselt, aber da lagen Zeitraeume von mehreren Sekunden dazwischen (ich weiss es nicht mehr so genau, 10s vielleicht?), also schon genug Zeit zum schlafen legen/aufwecken.