Frage zu Prozessoren mit mehreren Kernen

[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.

[clue]

Danke Euch beiden! Dann sind meine Fragen damit geklärt. Ich schätze durch amd64 wird die Welt sanft auf 64 bit "migriert". Vielleicht werden in 10 Jahren gar keine i386er Programme mehr benutzt, geschweige denn hergestellt. Wird ja auch mal Zeit, die alten Zöpfe abzuschneiden.

[cirrussc]

Wird ja auch mal Zeit, die alten Zöpfe abzuschneiden.

Wie gesagt, die alten Wurzelzöpfe ( ) sind gerade bei dieser Arch. weiterhin vorhanden, im Gegensatz zum IA64, Mips, Sparc 64

[Dragorf]

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.

Kommt die größere Paketgröße nicht daher, dass die Zeiger in 64bit-Programmen doppelt so groß sind?

[armin]

Kommt die größere Paketgröße nicht daher, dass die Zeiger in 64bit-Programmen doppelt so groß sind?

Ehm, ne. Die Pointergröße ist nur zur Laufzeit relevant.

[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...

Jetzt isses ja soweit, kuckst du hier: http://www.heise.de/newsticker/Preise-f ... ung/122014
Hmm, wie purzeln kommt mir das allerdings nicht vor. Wie auch, die sind eh schon sehr preiswert. *g

ciao, storm

[MoonKid]

Jo, der Thread ist alt, aber genau mein Thema! Das Thema hat sich ja seither auch weiterentwickelt.

Da wäre meine Eingangsfrage mal, wie scharf der Kernel (Debian unstable) mitlerweile optimiert ist für mehr Kerne? Laut ps -eLf | tail -n+2 | wc -l hab ich hier 498 Threads, die aber sicher nicht alle aktiv sind.

Ist der Kernel/Scheduler so weit entwickelt, dass er zich SingleThread-Anwendungen die nicht rechenintensiv sind besser auf vier, als auf zwei Kerne verteilen kann?

Also lieber ein Quad als ein Dual Core heutzutage?

btw: Is ne Art Office PC. Nix rechenintensives dabei. Keine Games oder so. Also die CPU würde ich grundsätzlich mit einer relativ niedrigen Frequenz kaufen.

Und ohne jetzt n neuen Thread dafür aufzumachen: Kann den Firefox/Gecko mitlerweile was mit mehreren Kernen anfangen. FF ist nämlich tatsächlich bei mir die langsamste Anwendung, obwohl ich natürlich weiß, dass das mehr ein Speicherproblem sein dürfte.

[tegula]

Firefox scheint Mehrkernprozessoren zu unterstützen [1].

FF ist nämlich tatsächlich bei mir die langsamste Anwendung, obwohl ich natürlich weiß, dass das mehr ein Speicherproblem sein dürfte.

Wie sieht denn die Speicherauslastung bei dir aus, wenn Firefox langsam wird?

Code: Alles auswählen

free -m 

Maßnahmen um Firefox zu beschleunigen:
=> Adblocker benutzen (z.B Add-on ublock Origin)
=> Javascipt nur bei Bedarf aktivieren (z.B Add-on Noscript)
=> Flash entweder gar nicht installieren oder nur bei Bedarf aktivieren (z.B Add-On Flashblock)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=516752#c15

[Lord_Carlos]

Ich glaube bei FF hat jeder Tab sein eigenen Thread, aber ob ein Tab auch mehrere CPU benutzten kann weis ich nicht.
Video gucken sollte sich auf mehrere Threads verteilen.

Aber wenn man mit dem PC sowieso nichts rechenintensives macht, ist das dann nicht fast egal? Gibt es ueberhaupt noch 2 kerner? i3?

Bei viel Firefox und Buero Anwendungen wuerde ich auf jeden fall eine SSD kaufen. Gerade wenn man ein Browser mit mehreren gespeicherten Tabs oeffnet ist das nett.

[Paddie]

Aber wenn man mit dem PC sowieso nichts rechenintensives macht, ist das dann nicht fast egal? Gibt es ueberhaupt noch 2 kerner? i3?

es gibt noch i3 und i5 mit 2 Kernen und Hyperthreading (iirc aber nicht alle).

Bei viel Firefox und Buero Anwendungen wuerde ich auf jeden fall eine SSD kaufen. Gerade wenn man ein Browser mit mehreren gespeicherten Tabs oeffnet ist das nett.

Ich würde mir eigentlich immer eine SSD kaufen...je nach Platzbedarf als einzige Platte oder für Daten dann noch eine normale Platte dazu.

[MoonKid]

Firefox ist schon beim Start auf einem frisch gebooteten System langsam. Das liegt nicht am RAM (da ist immer genug Platz), sondern wohl mehr am Umgang mit SWAP und der daran beteiligten HDD.

Habe aber auch auf einem relativ alten Netbook letztens ne SDD installiert und das System neu aufgesetzt. Keine Änderung - was beim Netbook aber auch an der CPU liegen könnte.

Ich denke eine SDD hilft bei Firefox kaum. Mozilla sollte hier einfach mal mehr Ressourcen in die Performance-Optimierung stecken. Das Ding ist so groß und verkorkst, da blickt keiner mehr durch. Da gibt es sicher viele Optimierungspunkte, nur müssen diese durch aufwendige Messungen und Tests erstmal gefunden werden. Solche bitte-refreshen-sie-ihr-profil-Tips von Mozilla um die Geschwindigkeit zu erhöhen, sind ein Armutszeugnis.

Der aktuelle Opera flutsch übrigens ganz schön. Im Grunde existiert aber keine im FOSS-Sinn ideologisch vertretbare Alternative zu FF. Oder?

[tegula]

[...]
Der aktuelle Opera flutsch übrigens ganz schön. Im Grunde existiert aber keine im FOSS-Sinn ideologisch vertretbare Alternative zu FF. Oder?

Normales Bedienkonzept:

• chromium
• midori
• netsurf

Ungewöhnliches Bedienkonzept:

• surf
  uzbl

Überlick:
https://wiki.ubuntuusers.de/Internetanw ... Webbrowser
https://wiki.debian.org/WebBrowsers

[DeletedUserReAsG]

Ein SSD (Neutrum) hilft bei FF kaum? Gut, wenn man den Unterschied von ca. 10s (HDD) zu ~0.5s (SSD) beim Starten „kaum“ nennen mag …

[MoonKid]

Bei mir macht die SDD keinen fühlbaren Unterschied - obwohl es das theoretisch tun sollte.

chromium ist Google - absolutes nogo, schon aus Sicherheitsgründen, auch wenn der Code offen ist.
midori ist ein Mozilla Clone/Aufsatz/Whatever - im Kern ein Firefox.

Den Rest zieh ich mir mal rein.

[hikaru]

midori ist ein Mozilla Clone/Aufsatz/Whatever - im Kern ein Firefox.

Wie kommst du zu dieser Aussage?

[MoonKid]

midori ist ein Mozilla Clone/Aufsatz/Whatever - im Kern ein Firefox.

Wie kommst du zu dieser Aussage?

Du hast Recht - veraltet. Das galt noch, als Firefox selbst noch WebKit nutze und nicht Gecko.