Frage zu Prozessoren mit mehreren Kernen

[ruwen]

Ich hab' jetzt mal gelesen, dass Triple-Core "schwachsinn" sei, weil Anwendungen entweder auf Dual oder auf Quadcore optimiert sein. Stimmt das?
Ich kann mir nicht vorstellen, das Software auf eine bestimmte Anzahl von Kernen optimiert ist... entweder Single oder Multikern optimierung... aber spezielle optimierung auf Quadcore??

Man kann in manchen Sprachen die Anzahl der Cores auslesen und dann dem entsprechend optimieren. In meinem jugendlichen Leichtsinn vermute ich mal, dass man eher allgemein auf mehrere Cores optimiert (8 Threads können auch von einem Core abgearbeitet werden, nur dass dann etwas Scheduling-Overhead entsteht). Und selbst wenn deine Anwendung nicht optimiert ist, überleg mal was normalerweise noch so alles nebenbei läuft. Schwachsinn würde ich es deshalb nicht nennen.

[storm]

Der Aufpreis auf den P2 wird es mit Sicherheit wert sein diesen zu kaufen statt einem kastrierten Prozessor, wie den Kuma. Sind ja noch 5 Tage.

Was ist daran kastriert!? Nix. Man bestellt einen Dual Core und bekommt einen Dual Core, außer dass noch zwei Kerne da drin rumlungern. Außerdem hat das Teil noch 2MB L3, der neue wird das in dieser Ausführung nicht haben, und nichts ist besser als reichlich Cache (außer: noch mehr Cache). Die restlichen Nachteile seh ich aber auch.
Zum weiteren Verstricken in der Thematik: der Phenom II ist eine komplett neue Fertigung, inkl. neuer Strukturgröße, d.h. man kann als early adaptor auch fein aufs Gesicht fallen, weil das Ding Kinderkrankheiten hat. Wie das TLB-Problem des B2-Stepping.
Und so sitzt der Threadstarter weiter mit seinem beginnenden Haltungsschaden am Schleppi und wartet. Aber die paar Tage kriegt er auch noch rum (Bei den Online-Händlern könnten die Preise möglicherweise schon vor dem offiziellen Termin nachgeben).

ciao, storm

[joshlukas]

Mit kastriert meinte ich, dass es sich um einen Quadcore handelt, der auf einen Dualcore "kastriert" wurde. Freilich wird der Kuma als ein Dualcore verkauft und wenn Du den kaufst bekommst Du auch einen Dualcore. Die Nebenerscheinungen sind eben die höhere TDP, die verglichen mit älteren Dualcores wie dem X2 Brisbane - der zwar noch in µ.65 gefertigt wird - welcher eine TDP von 45W aufweist einfach zu hoch ist. Selbst der etwas höhere Performancegewinn des Kuma bei gleicher Taktung resultiert nicht in einer besseren Leistung/Watt. Darum würde ich bei einem neuen System einen X2 mit Brisbane Kern, dem Kuma vorziehen. Wie auch immer. Darum geht es hier im Thread nicht.
Derzeit täte ich entweder einen X2 4850e für rund €50 kaufen, wenn es günstig sein soll, oder zum Phenom X4 9850 Black Edition (€140) gegriffen, oder diesen Monat noch warten, sparen und den P2 940 kaufen.
Der Phenom 2 ist übrigens keine Neuentwicklung. Wie Du schon sagst, die Strukturgröße wurde geschrumpft und einige Optimierungen am Memorycontroller etc. wurden durchgeführt. Von Kinderkrankheiten wird man da garnichts mitbekommen. Siehe auch Shanghai, den es bereits zu kaufen gibt. Ist die selbe CPU. Sowohl der Shanghai, als auch der P2 basieren auf dem Phenom 1.

[tobb]

@joshlukas: Sparen hilft nichts, ich bin ein armer Student und habe gerade kein Einkommen
Wie schnell sinken den Prozessorpreise? Meint ihr so ein Phenom II X2 940 ist in einem halben Jahr für 150€ zu kriegen oder kann ich das gleich vergessen?
Wenn nein, hol ich mir lieber jetzt den schnellsten Phenom I...

Ne andere Frage:
Laut Wikipedia gibt es einige der Phenom in zwei ausführungen: http://de.wikipedia.org/wiki/Liste_der_ ... oren#Agena
Z.B. gibt es den Phenom X4 9850 einmal mit TDP 125W und einmal mit 95W. 95W ist doch besser, oder?
Leider gibt es bei alternate.de oder bei hardwareversand.de nur die 125W Version...

[joshlukas]

Das ist schwer zu sagen wie sich die Preise genau entwickeln werden. Kann mir gut vorstellen, dass die Preise für den kommenden 920 und 940 P2 in einem halben Jahr unter €200 fallen, zumal der Agena auslaufen soll und im April/Mai weitere Phenom 2 CPUs folgen werden. Intel wird mit dem i5 und i7 weiter Druck auf AMD ausüben... schwer zu sagen wie sich das entwickelt. Wenn Du dringend einen neuen Prozessor brauchst, dann hole Dir einen Phenom1 Quad, oder einen günstigen Dualcore. Dazu ein aktuelles Mainboard und Du kannst in einem halben Jahr, oder ein Jahr später upgraden, denn die AM3 CPUs werden auch in viele AM2+ Boards laufen.


Gruß,

Josh

[tobb]

Könnte es evtl. passieren, dass die Preise für die AMD Phenom I wieder steigen.... im Moment sind die kriminell gündtig und ich überlege mir ob ich mir nicht schnell einfach den AMD Phenom X4 9950 sichern soll...

[Leonidas]

Man kann in manchen Sprachen die Anzahl der Cores auslesen und dann dem entsprechend optimieren. In meinem jugendlichen Leichtsinn vermute ich mal, dass man eher allgemein auf mehrere Cores optimiert (8 Threads können auch von einem Core abgearbeitet werden, nur dass dann etwas Scheduling-Overhead entsteht). Und selbst wenn deine Anwendung nicht optimiert ist, überleg mal was normalerweise noch so alles nebenbei läuft. Schwachsinn würde ich es deshalb nicht nennen.

Die Anzahl der CPUs auslesen ist ja keine Sache, das kannst du mit ``grep -c ^processor < /proc/cpuinfo`` ganz trivial haben. Nichts sonderlich anderes ist eben Multicore: mehrere CPUs die auf einem Baustein sitzen und sich einige Hardware teilen. Jede dieser CPUs kann nun genau einen Thread laufen lassen, was aber recht selten genau so ausgelastet ist, da oft ein Kernel dazwischenhängt und ein Userland, das auch einige Threads hat. Somit braucht es einen Scheduler der Threads verteilt. Optimalerweise ist der Scheduler ausreichend schlau, dass da eine möglichst hohe Auslastung erreicht wird. Hier erreichen wir das erste Problem: Skalierbarkeit. Viele Betriebssysteme sind nicht sonderlich für große Anzahlen von CPUs gedacht, so dass das hinzufügen von weiteren CPUs nur wenig zur Performanceverbesserung beiträgt. Ich meine mich zu erinnern, dass bei SMP-Betrieb, also genau das was Multicores auf x86 machen FreeBSD bis zu 8 CPUs davon profitiert und danach lohnt es sich nicht weitere Kerne/CPUs hinzuzufügen. Weiter geht es dann mit NUMA.

Nun, jetzt nehmen wir an wir haben einen Dualcore, so wie ich in meinem Laptop. Habe hier nicht so wahnsinnig viel offen, also das wären dann laut ``ps -eLf | tail -n+2 | wc -l`` 101 Threads. Viele Applikationen nutzen nur einen Thread, einige nutzen mehrere. Die Anzahl der Threads besagt wie viele CPUs diese einzelne Applikation im Optimalfall ausreizen könnte. Bei 1 Thread kann die Applikation, sollte sie 100% Rechenzeit benötigen eine CPU komplett auslasten, also das gesamte System auf maximal 50%. Mit den anderen 50% kann ich dann machen was ich will. Ein intelligenter Scheduler schiebt dann den einen Thread auf eine CPU und die anderen, die nicht viel machen auf die andere CPU. Eine Applikation mit nur einem Thread zu machen ist ganz einfach: man nutzt einfach so viel Rechenleistung wie man braucht und das OS kümmert sich darum, so viel Rechenleistung wie im Moment beschaffbar ist, dem Thread zur Verfügung zu stellen.

Nun, jetzt nehmen wir uns eine weitere Applikation vor, etwa eine kleine GUI-Anwendung. Diese Anwendung berechnet irgendwelche komplexen Sachen im Hintergrund. Da die Berechnung den Thread so lange blokiert bis sie fertig würde würde es scheinen, dass die Anwendung hängt, weil sie auch nicht mehr dazu kommt ihr Fenster neu zu zeichnen und auf Usereingaben zu reagieren. Daher lagert man die Berechnung in einen separaten Thread aus. Auf einer Maschine mit 2 CPUs könnte nun der Scheduler entscheiden den Berechnungsthread auf die eine CPU zu tun und den GUI-Thread auf eine andere. Oder auch nicht, das ist ihm überlassen. Somit laufen die Threads eben real parallel. Zumindest theoretisch, da es ja noch die 101 Threads gibt, die zwischendrin auch ausgeführt werden wollen. Auf einer 1 CPU Maschine läuft das eben so ab, das dann einfach 103 Threads in irgendeiner Reihenfolge irgendwie lange bestimmte Zeitscheiben abbekommen und dann der nächste Thread läuft (Preemptive Multitasking nennt man das). Nun ist der Berechnungsthread aber immer noch nur ein einzelner Thread und kann damit nur eine CPU auslasten. Der andere Thread, der GUI-Thread verbraucht kaum Ressourcen. Somit wird die Anwendung durch Zugabe weiterer Prozessoren kaum messbar schneller.

Die Schwierigkeit besteht also darin die Berechnung auf mehrere Threads aufzuteilen. Das ist einfach wenn das Problem parallelisierbar ist (wie etwa Kompilation von C-Quelltext mit GCC, wo man einzelne Quelldateien parallel zueinandern zu Objektcode verarbeiten kann und dann erst das Ergebnis zusammenlinkt) aber schwerer wenn man für eine Berechnung die Ergebnisse einer anderen Berechnung braucht, wie das bei vielen Sachen der Fall ist, wie etwa die Größe der Mails in einem IMAP-Ordner zu bestimmen oder tausend anderen Problemen. Ein weiteres Problem ist Datenaustausch zwischen Threads. Mehrere Threads greifen auf den gleichen Speicher zu, aber wenn man zwei Threads startet, diese eine Speicherzelle auslesen und dann erstmal der eine in die Speicherzelle schreibt und dann der andere in die selbe Zelle schreibt gehen Ergebnisse verloren und Race-Conditions entstehen. Da nutzt man dann häufig Locking, wobei dann der Schreibzugriff durch bestimmte Flags zu bestimmten Zeiten blokiert wird. Dabei kann es dann auch vorkommen, dass bestimmte Locks nie aufgehoben werden und Deadlocks entstehen. Wenn man es richtig macht, und das Problem passt, kann man nahezu 100% Auslastung erreichen. Multithreading is hard, let's go shopping!

Um den Entwicklern zu helfen gibt es nun Bibliotheken die Dinge vereinfachen wie etwa OpenMP, Thread Building Blocks oder Boost.Thread und wo genau geschaut wurde dass die Dinge die sie bieten wirklich fehlerfrei sind und keine Race-Conditions oder Deadlocks haben. Parallel dazu gibt es einen Trend zu funktionalen Sprachen mit immutablen Datenstrukturen, also Datenstrukturen die sich nicht ändern können, statt alte zu ändern werden neue, geänderte Datenstrukturen frisch erstellt. Klingt aufwendig, ist es aber gar nicht mal so; durch einige intelligente Optimierungstricks kann man da halbwegs brauchbare Performance rausholen und für den Programmierer ist es einfacher korrekten Code zu schreiben. Solche Kandidaten wären etwa Erlang (ejabberd, der Jabber-Server des Debianforums ist in Erlang und kann wirklich viele user auf einmal handhaben), Scala wie es der Name schon impliziert oder Clojure. Die Sprachen gehen da Teils noch weiter und kümmern sich gar nicht um Threads sondern eher um Tasks, die dann irgendwie von der Runtime auf Threads abgebildet werden und dann von der Runtime parallelisiert werden.

Heutige Programme nutzen selten Threads dermaßen extensiv eben weil es komplexer ist und viele Probleme nicht trivial parallelisierbar sind. Momentan machen sich hauptsächlich die Autoren von rechenintensiven Programmen gedanken darüber, aber wenn etwa 12-Kernsysteme normal sein werden ist es natürlich nicht so toll wenn da zum beispiel ein Officeprogramm den Rechner nur maximal 1/12 auslasten kann wenn man genug Hardware hat um eine Berechnung in einer umfangreichen Tabellenkalkulation mal eben 12 mal schneller auszuführen. Fun fact: einige der an das NIST eingesendeten SHA Nachfolge-Kandidaten sind zwar rechenintensiver als SHA aber schneller, da die Autoren Algorithmen nutzen die besser parallelisierbar sind.

[tobb]

Vielen Dank für diesen ausführlichen Beitrag.

Deswegen habe ich auch lange überlegt, ob ich mir lieber einen Dual-Core statt einen Quad-Core holen soll. Allerdings ist es ja egal, wenn sowohl der Dual-Core, als auch der Quad-Core pro Kern 3GHz hat oder so... dann ist ist jedem Fall der Quad besser, weil auch beim unoptimierter Software,(die nur einen Thread verwendet) der Dual Core nicht schneller sein kann...

Trotzdem noch die Frage:
Könnte es evtl. passieren, dass die Preise für die AMD Phenom I wieder steigen.... im Moment sind die kriminell gündtig und ich überlege mir ob ich mir nicht schnell einfach den AMD Phenom X4 9950 sichern soll...

[cirrussc]

Könnte es evtl. passieren, dass die Preise für die AMD Phenom I wieder steigen.... im Moment sind die kriminell gündtig und ich überlege mir ob ich mir nicht schnell einfach den AMD Phenom X4 9950 sichern soll...

Du, das kann niemand vorher sagen. Möglich ist es, die RAM Preise fallen IMO momentan auch nicht weiter oder steigen sogar (hab das etwas aus den Augen verloren).
Aber da bald die neuen CPU's kommen, denk ich, werden die alten nicht teurer.

@Leonidas schön verständliche Erklärung

[storm]

Trotzdem noch die Frage:
Könnte es evtl. passieren, dass die Preise für die AMD Phenom I wieder steigen.... im Moment sind die kriminell gündtig und ich überlege mir ob ich mir nicht schnell einfach den AMD Phenom X4 9950 sichern soll...

Steigen ist eher unwahrscheinlich, aber nicht ausgeschlossen. Hoch gehen könnte der Preis wenn auch der Dollar wieder zulegt, was im Moment aber eher nicht so aussieht. Ein Fallen des Preises im Zug der Einführung des Phenom 2 ist auch möglich, muss aber nicht sein. Bei den K9 ist auch kein größerer Knick im Preisverlauf zu finden, als der K10 in den Handel kam. Ist zB hier zu sehen:
Athlon 64 X2 4800: http://www.heise.de/preisvergleich/?phi ... 2&age=2000
Phenom X4 9550: http://www.heise.de/preisvergleich/?phi ... 2&age=2000
Du solltest dir vllt. nicht so viel den Kopf über die Preise zerbrechen, +/- 10% sind doch wurscht und ganz schnell durch höhere Versandkosten beim falschen Shop aufgefressen.

ciao, storm

[123456]

@Leonidas schön verständliche Erklärung

Ja, finde ich auch.
Applllaaauuuuussssss. (Kermit, the frog)

[clue]

Ich habe auch vor, mir irgendwann dieses Jahr einen P2 o.ä. zu holen. Zur Zeit benutze ich noch meinen 7 Jahre alten XP 1800+ (der unter Etch i386 wirklich sehr schnell und flüssig arbeitet). Was mich aber interessieren würde, ist, welche Linux-Version ich dann bräuchte, und inwiefern diese Linux-Version dann auch meinen Mehrkerner ausnützen würde (also ob und inwiefern irgendwelche Anwendungen, KDE und der Kernel dafür optimiert wären).

[Leonidas]

Wenn es um den Kernel geht: jeder Kernel der SMP unterstützt ist ok. KDE ist ja sowieso für Mehrkern optimiert, da KDE ja auch mehreren Prozessen besteht die ja automatisch auf mehrere CPUs verteilt werden wenn es nötig wird.

Und zu meiner Zeit hieß P2 noch Pentium 2, der heutzutage gar nicht mehr so einfach beschaffbar ist. Geschichte wiederholt sich eben immer wieder

cirrussc, ub13:

[clue]

Danke!

Und welche Linux-Architektur soll ich dann installieren? amd64 oder ia64, oder doch lieber bei i386 bleiben? Wo liegt denn der Unterschied zwischen ihnen?

[cirrussc]

P2

Wieso denn Pentium 2? Da behalt besser den XP, oder meinst du was anderes?

[tobb]

Es geht hier um den AMD Phenom II (AMD P2)...

[cirrussc]

Hach, kann man die paar Buchstaben nicht ausschreiben

[Leonidas]

Und welche Linux-Architektur soll ich dann installieren? amd64 oder ia64, oder doch lieber bei i386 bleiben? Wo liegt denn der Unterschied zwischen ihnen?

Du mischst da zwei, vielleicht sogar drei Sachen zusammen. Eine Architektur ist ja im Groben das, was ein Prozessor so an Machienencode versteht und was er Hardwaremäßig so kann. Nun muss ich ein wenig zurückgreifen, zum guten oder eigentlich eher schlechten aber billigen und halbwegs kompatiblen 8086 zurück. Der hat eine ganze Menge Befehle die er so versteht und kann maximal 16 Bit große Datenhäppchen in seinen Registern (das sind so kleine Speicherbereiche im Prozessor) arbeiten. Das heißt also dass der als 16-Bit-Prozessor gezählt wird. Der RAM ist inSpeicherzellen aufgeteilt die von Null bis zu einer großen Zahl linear adressiert sind. Nun ist die größte Zahl die der Prozessor halten kann also 2 hoch 16 und das führt dazu dass er maximal 64 KB Speicher adressieren kann. Mit einigen Recht ätzenden Tricks konnte man das auf 1 MB erweitern, aber das war dann aber auch zu wenig war. Also entwickelte Intel 1986 eine kompatible Erweiterung das 8086 (eigentlich des 80286, der der Nachfolger des 80186, die im großen und ganzen zum 8086 recht ähnlich waren) und nannte sie passenderweise 80386. Dabei wurden die Registerlängen verdoppelt (Register AX wurde zu EAX erweitert, BX zu EBX etc) und konnte nun 2 hoch 32 Zellen adressieren, was zu den inzwischen recht bekannten 4 GB RAM-Limit führt. Diese Architektur heißt IA-32 und wurde (mit Windows 95, das das erste brauchbare 32-Bit Windows-System war) immens populär: IBM baute solche CPUs, AMD baut sie bis heute, auch Citrix und Transmeta haben mal kompatible CPUs produziert. Wie du aber jedem beliebigen Mediamarkt-Prospekt entnehmen kannst sind heutzutage Rechner mit mehr als 4 GB RAM recht billig zu bekommen. Also gibt es zwei Möglichkeiten: entweder wie beim 8086 auf Trickserei zurückgreifen oder einen Nachfolger von IA-32 entwickeln. Solche Trickserei für IA-32-Prozessoren nennt sich PAE und wird von vielen Systemen unterstützt, so dass du zwar mehr als 4 GB Speicher nutzen kannst, aber jeder Prozess nur maximal 4 GB bekommen kann (angenommen du hast 8 GB RAM dann kannst du zwei Prozesse starten die jeweils 4 GB verbrauchen aber nicht einen der 6 GB verbraucht).

Fun Fact: Auch Windows unterstützt PAE, aber hauptsächlich auf den Server-Versionen seiner Betriebssysteme. Je teurer, desto mehr wird durch PAE freigeschaltet obwohl es natürlich eine künstliche Beschränkung ist, denn PAE bietet 64 GB. In Vista etwa kann manchmal nur 3,120 MB als verfügbar dargestellt was Leute mit mehr als 4 GB verwundert hat, so dass es in Vista Service Pack 1 4,096 MB anzeigt, obwohl es immer noch nur 3,120 MB sind.

Also gut, die andere Lösung wäre ein Nachfolger von IA-32 zu machen. Genau das hatte sich Intel überlegt und etwas komplett neues, nicht mehr zum 8086 oder zum 80386 kompatibles gemacht: IA-64. Dabei wurden viele Dinge neu designt, moderner (8086 hat schon 1978 niemanden vom Hocker gerissen) und ohne historische Altlasten. Es gibt zwei CPU-Familien die die Architektur IA-64 haben: Itanium und Itanium 2. Sind beide recht teuer und hauptsächlich auf Servern zu finden. Das Problem war, dass IA-64 eben nicht mehr kompatibel war und IA-32 Programme nicht einfach ausführen kann sondern aufwendig und daher langsam emulieren musste. Schlecht wenn man gerade auf einen Markt will, auf dem Windows dominiert. Microsoft hat zwar ein IA-64-Windows herausgegeben, aber der große Vorteil von Windows, die unmengen von 32-Bit Windows-Programmen war dahin, weil diese überaus zäh liefen (Vergleichbar mit QEMU).

Also hat sich AMD in zwischenzeit etwas anderes überlegt und eine Alternative zu IA-64 vorgestellt: AMD64, das die üblichen IA-32 CPUs um einen weiteren Modus erweitert hat, bei dem die Register nochmal verdoppelt sind, also aus 32 Bit wird 64 Bit (aus EAX wird RAX, EBX, wird RBX und es kommt noch eine Reihe weiterer Register dazu, womit mehr Daten im Prozessor gehalten werden können und weniger langsame Speicherzugriffe nötig sind), gleichzeitig dazu ist es aber dennoch möglich normale IA-32-Programme mit 32-Bit genauso schnell auszuführen. Auf diesen Kompatibilitätsvorteil sind dann alle aufgesprungen (auch Intel, das die Technik anfangs EM64T nannte und nun Intel 64, generell ist es auch als x86_64 bekannt, also x86 mit 64-Bit Erweiterungen und im Marketing-Sprech von Sun und Microsoft als x64, was, wie wir nun wissen eigentlich unpassend ist), Windows für IA-64 wurde abgesetzt und inzwischen kann man kaum Prozessoren von Intel oder AMD kaufen die x86_64 nicht unterstützen.

Also, der große Vorteil ist nun, dass man einfach 2 hoch 64 Speicherzellen adressieren kann, was für eine Zeitlang reichen sollte. Nachteil ist aber auch, dass die Adressen nun auch doppelt so lang sind und wenn man sie im RAM abspeichert (macht man in C ganz häufig mit Pointern) dann brauchen sie doppelt so viel Platz und mehr Zeit um von der CPU ausgelesen zu werden (da jede Speicherzelle 8 Byte lang ist müssen nun 8 statt wie früher 4 Zellen ausgelesen werden um eine x86_64-Adresse in den Speicher zu bekommen). Parallel gibt es aber den Vorteil dass man mehr Register zur Verfügung hat und gewisse Berechnungen, vor allem wennes um kryptografie geht, wesentlich schneller ablaufen.

Also mit einer handelsüblichen CPU hast du nur die Wahl i386 (x86) oder amd64 (x86_64). Unter Windows wird davon abgeraten, da es kaum Vorteile bringt außer man hat eben Software die entweder von den schnelleren Berechnungen profitiert oder vom größeren Speicher und da viel Software sowieso noch 32-bittig ist. Unter Linux ist es recht simpel ein 64-Bit-only-System zu haben, aber wenn man keine Software nutzt die davon profitiert, dann bringt es außer mehr Speicherverbrauch in der Regel keine großen Vorteile. Persönlich habe ich amd64, einfach so, weil ich es wollte; kann mich nicht beschweren - wäre aber mit i386 ähnlich.

Unter Debian hat amd64 einen Vorteil: Da Debian i386 für 486-Prozessoren kompiliert ist, nutzt es keine moderneren Features als die, die bei 486 dabei sind. Also kein MMX, SSE, SSE2 etc., diese sind aber bei allen amd64-CPUs dabei, also werden sie auch genutzt. Ob das ein großer Vorteil ist ist schwer zu sagen, da musst du die Gentoo-Leute fragen, die alles hochoptimiert kompilieren

[rendegast]

Da Debian i386 für 486-Prozessoren kompiliert ist, nutzt es keine moderneren Features als die, die bei 486 dabei sind. Also kein MMX, SSE, SSE2 etc.,

Für die Nutzung dieser Feature muß doch die Kette
kernel <-> lib(c) <-> programm
stimmen.

Code: Alles auswählen

# mplayer
MPlayer 1.0rc2-4.3.2-DFSG-free (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) 64 Processor 3000+ (Family: 15, Model: 4, Stepping: 8)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
...

MMX und SSE werden da wohl genutzt?
Nun sind bei mir kernel=686, libc6, libc6-i686 und mplayer alles *_i386.deb.
("i386" ist hier wohl eher debian-Syntax für das Repository, denn der Kernel ist ja mit '-march=686' übersetzt)
Da mplayer wohl auch unter dem kernel *-486 laufen würde (wohl ohne die Features),
heißt das doch eher,
daß die Architektur-Stufe (386/486, 586/686) beim kernel eine Begrenzung nach oben ist,
aber bei den Programmen/libc6 eine Kompatibilität nach unten?

[Spasswolf]

Der mplayer hat ja die Sonderfunktione "runtime cpudetection". Irgendwelche libc6 Funktionen werden für mmx/sse nicht benötigt, ich vermute sogar das der Kernel nicht für speziell optimiert sein muss, da das Speichern der mmx/sse Register beim wechseln von Prozessen/Threads nach dem gleichen Mechanismus funktioniert wie bei den fpu Registern (fxsave/fxrstor).

[Leonidas]

Für die Nutzung dieser Feature muß doch die Kette
kernel <-> lib(c) <-> programm
stimmen.

Wieso? Ob die MMX-Register vom Programm benutzt werden, wird ja nicht vom Kernel oder der libc beschränkt. Was der Kernel ggf. beschränkt ist der Zugriff auf die verlängerten 64-Bit Register sowie die zusätzlichen R8 bis R15 die nur im Long Mode verfügbar sind. Was aber nicht geht ist auf MMX oder SSE-Register zugreifen, wenn der Prozessor sie nicht besitzt. Ich schätze dass da eine Machine Exception kommt, habe es aber nicht ausprobiert.

Code: Alles auswählen

# mplayer
MPlayer 1.0rc2-4.3.2-DFSG-free (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) 64 Processor 3000+ (Family: 15, Model: 4, Stepping: 8)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
...

MMX und SSE werden da wohl genutzt?

Bin mir nicht sicher. Das scheinen ja die CPUflags zu sein (``grep ^flags < /proc/cpuinfo`` wo auch bei mir so Sachen wie sse, sse2, mmx, ssse3 etc.) rumschwirren. Ist das der normale MPlayer oder der Debian-Multimedia-MPlayer? Die können ja verschieden optimiert sein und ggf. durch ein paar Tricks verschiedene Binaries oder so, je nach verfügbaren CPU-Erweiterungen nutzen. Oder verschiedene Lib-Versionen oder irgendwelche anderen Möglichkeiten die eben so viele CPU-Features nutzen wie grad verfügbar sind.

Nun sind bei mir kernel=686, libc6, libc6-i686 und mplayer alles *_i386.deb.
("i386" ist hier wohl eher debian-Syntax für das Repository, denn der Kernel ist ja mit '-march=686' übersetzt)
Da mplayer wohl auch unter dem kernel *-486 laufen würde (wohl ohne die Features),
heißt das doch eher,
daß die Architektur-Stufe (386/486, 586/686) beim kernel eine Begrenzung nach oben ist,
aber bei den Programmen/libc6 eine Kompatibilität nach unten?

Erstmal hat GCC zwei Optimierungsoptionen auf bestimmte CPUs plus zahllose Optimierungsflags: -march wählt die minimale CPU-Architektur aus. Heist also dass der Code auf die CPU optimiert ist nur auf dieser Architektur oder auf neueren, kompatiblen läuft. -march=386 tut auf allem ab 368 aufwährts, -march=486 (das von Debian für das i386 Repository benutzt wird) für 486 aufwährts, aber nicht mehr 386. Das war ja die Diskussion bei Etch (oder schon bei Sarge?), dass Debian i386 somit nicht mehr auf 386-CPUs läuft. De zweite Option ist -mcpu, die auf kompatible Weise optimiert, sprich -march=386 -mcpu=486 ist so auf 486 optimiert, dass es auf 386 auch noch tut. Da fallen natürlich Sachen weg, die auf 386 nicht laufen würden und die Optionierungen sind geringer (wenn überhaupt messbar).

Nun, der 686-Kernel läuft nicht auf dem 80386, 80486 oder 80586 (aka Pentium 1, P1) sondern nur ab 80686 (aka Pentium 2, P2) und Debian bietet den Kernel deswegen in einer Spezialvariante an, weil es eben der Code ist, der auf den Systemen mit Abstand am meisten läuft und wo Optimierungen am ehesten noch einen Unterschied machen.

Und nein, es gibt keine Unterscheidung zwischen Begrenzung nach oben oder unten. 686 ist die Mindestvorraussetzung sowohl für den Kernel als auch für die libc als auch für jedes beliebige Programm dass -march=686 kompiliert ist.

[Spasswolf]

Was aber nicht geht ist auf MMX oder SSE-Register zugreifen, wenn der Prozessor sie nicht besitzt. Ich schätze dass da eine Machine Exception kommt, habe es aber nicht ausprobiert.

Laut "Intel Software Developer’s Manual 3A" [1] gibt es eine "Invalid Opcode Exception" (5-35).

[1] http://www.intel.com/products/processor/manuals/

[clue]

Also mit einer handelsüblichen CPU hast du nur die Wahl i386 (x86) oder amd64 (x86_64)

Erstmal: Danke Leonidas. Deine Zusammenfassung ist wirklich super und sollte eventuell Einzug bei Wikipedia halten

Wenn ich Dich jetzt richtig verstehe, dann ist IA64 also nur noch ein Relikt aus einer untergehenden Ära und statt dessen amd64 die Architektur der Wahl (ich meine das zu wählende Installationsimage)? Weißt Du zufällig auch darüber Bescheid, inwiefern die beiden Varianten (i386 & amd64) sich in den Debian-Repos unterscheiden? Soll heißen, inwiefern sind außer dem Kernel noch andere Programme optimiert worden

[cirrussc]

Wenn ich Dich jetzt richtig verstehe, dann ist IA64 also nur noch ein Relikt aus einer untergehenden Ära und statt dessen amd64 die Architektur der Wahl (ich meine das zu wählende Installationsimage)?

Unabhängig davon ob uralt oder hochaktuell, es ist einfach die falsche Arch für einen üblichen Home PC.

Soll heißen, inwiefern sind außer dem Kernel noch andere Programme optimiert worden

Nahezu alle sind anders gebaut.
Deshalb kannst Du kein Paket aus einem amd64 Repo. auf einem 486 Debian installieren.

[Leonidas]

Erstmal: Danke Leonidas. Deine Zusammenfassung ist wirklich super und sollte eventuell Einzug bei Wikipedia halten

Danke. Ich habe allerdings nicht die Nerven so einen Text an die Wikipedia anzupassen; das ist mir ehrlich gesagt, zu viel Aufwand und der nutzen ist, naja.

Wenn ich Dich jetzt richtig verstehe, dann ist IA64 also nur noch ein Relikt aus einer untergehenden Ära und statt dessen amd64 die Architektur der Wahl (ich meine das zu wählende Installationsimage)? Weißt Du zufällig auch darüber Bescheid, inwiefern die beiden Varianten (i386 & amd64) sich in den Debian-Repos unterscheiden? Soll heißen, inwiefern sind außer dem Kernel noch andere Programme optimiert worden

Naja, IA-64 ist vielleicht nicht übel und ein 64-Bit Neuanfang keine per-se schlechte Idee, es ist eben am Markt gescheitert, weil die Migration nicht ganz so trivial wie bei amd64 ist.

Und i386 und amd64 sind, wie cirrussc sagte komplett verschiedene Pakete. Das kannst du dir etwa wie den Unterschied zwischen einer Nintendo 64 CPU (die Architektur dort heißt übrigens MIPS) und der einer XBox 360 CPU (PowerPC, also das was früher in den pre-Intel-Macs war). Eine i386 kann überhaupt keinen amd64 Bit-Code verstehen, weil die Maschienensprache anders ist. Andersrum kann eine amd64-CPU aber i386-Code im Kompatibilitätsmodus ausführen (daher hast du überhaupt die Wahl). Debian i386 läuft auf 80486 und allen neueren Intel/AMD/Transmeta/Citrix-CPUs, Debian amd64 hat komplett verschiedene Pakete (die, wenn du es dir anschaust alle geringfügig größer sind) - eben die Software als 64-Bit Version, die ohne Kompatibilitätsmodus auskommt.