Intel - Wann gibt es echte 64-Bitter von Intel? [Archiv]

StefanV

2007-09-24, 16:57:02

Wohl erst mit Nehalem...

PS: gleich wird wohl rumgebasht werden, bevor das der Fall ist, sollte die c't 20/07 zu Rate gezogen werden, das Prozessorgeflüster...

Ach!? Woran merkst du das denn? :|
Kauf dir mal 'ne aktuelle c't und lies dir u.A. das Prozessorgeflüster an, 'oben rechts' war was...

nemesiz

2007-09-24, 16:59:19

Lol, sag ma, aus wellem Busch kommst du denn?

http://de.wikipedia.org/wiki/IA-64 haben wir wohl ganz verschlafen oder?

64Bit von Intel gibts schon seit Urzeiten, keiner wollte es, keiner unterstützte es (ich rede hier von dem Bereich für Otto, den Normalverbraucher).

Nach Jahren kam dann mal AMD auf die tolle die das ganze Aufzugreifen und tam tam, jeder wollte es (frag mich ja wie AMD das anstellte).

Brauchen tuts aber heute noch kaum einer wirklich (von den Ottos) und wirklich nutzen (hallo Software) tuts auch keiner bzw auch keine Soft.

Am lustigsten fand ich immer die Aussagen, AMD ist soooo viel weiter wie Intel, deswegen gibts AMD mit 64bit aber Intel kommt damit nicht hinterher.

LOL, lag eher daran dass Intel wohl recht hatte dass man es zu diesem Zeitpunkt einfach nicht braucht.. aber.. der Markt bestimmt eben.

PS: die Frage sollte eher lauten wann AMD mal reine 64bitter rausbringt ;-)

Gast

2007-09-24, 17:02:53

Kauf dir mal 'ne aktuelle c't und lies dir u.A. das Prozessorgeflüster an, 'oben rechts' war was...

hier? http://www.heise.de/ct/07/20/019/default.shtml

Coda

2007-09-24, 17:07:44

Core 2 Duo und die letzten Pentium 4 sind "echte" 64-Bit-Prozessoren (was auch immer "echt" bedeuten soll).

StefanV

2007-09-24, 17:08:33

Gast

2007-09-24, 17:10:08

@nemesiz
Nee, so ganz unrecht hat der Gast nicht, denn es gibt beim aktuellen C2D durchaus Unterschiede zwischen dem 32bit und 64bit Modus, denn im 64bit Modus sind nicht alle Einheiten des Prozessors aktiv/nutzbar, was besonders auf diverse Performancesteigernde Einheiten zutrifft.

@Gast
Ja, das ist ein Part, ein anderer Teil steht im großen Barcelona Artikel drin.

na mir gings nur darum klarzustellen dass intel scho laaaange 64bittig unterwegs ist. des wissen nur manche garnicht. klar, nen 32bit modus kannst da knicken aber schon IA64 hatte das gleiche problem wie die aktuellen 64bit mode cpus... s gibt kaum software.

Coda

2007-09-24, 17:10:31

Nee, so ganz unrecht hat der Gast nicht, denn es gibt beim aktuellen C2D durchaus Unterschiede zwischen dem 32bit und 64bit Modus, denn im 64bit Modus sind nicht alle Einheiten des Prozessors aktiv/nutzbar, was besonders auf diverse Performancesteigernde Einheiten zutrifft.
Das einzige was nicht funktioniert ist ein Teil des Instruction-Decoding. Das wird aber durch die verringerten Speicherzugriffe im 64-Bit-Modus mehr als ausgeglichen.

Nach der Logik wäre Core 2 Duo ein "echter" 64-Bit-Prozessor wenn er einfach keine Macro-Op-Fusion hätte oder was? Blödsinn da.

PHuV

2007-09-24, 17:13:14

Was ist mit den Itanium 1/2-Prozessoren (http://de.wikipedia.org/wiki/Intel_Itanium_2), daß sind auch 64-bitter durch und durch? Gibts halt nur für den Server-Bereich.

StefanV

2007-09-24, 17:15:41

Was ist mit den Itanium 1/2-Prozessoren (http://de.wikipedia.org/wiki/Intel_Itanium_2), daß sind auch 64-bitter durch und durch? Gibts halt nur für den Server-Bereich.
i860 und i960 auch, AFAIK...

Gast

2007-09-24, 17:17:06

denn es gibt beim aktuellen C2D durchaus Unterschiede zwischen dem 32bit und 64bit Modus, denn im 64bit Modus sind nicht alle Einheiten des Prozessors aktiv/nutzbar, was besonders auf diverse Performancesteigernde Einheiten zutrifft.

Wirkt sich jedoch nicht aus.
http://www.xbitlabs.com/articles/cpu/display/core2duo-64bit.html

Okay, nächste Frage. Diese ist ja nun geklärt!

HOT

2007-09-24, 17:26:21

Alle AMD64 CPUs von Intel und AMD sind echte 64Bitter. Dass es Flaschenhälse gibt, tut da nichts zur Sache.

Wishnu

2007-09-24, 17:50:59

64Bit von Intel gibts schon seit Urzeiten, keiner wollte es, keiner unterstützte es (ich rede hier von dem Bereich für Otto, den Normalverbraucher).

Nach Jahren kam dann mal AMD auf die tolle die das ganze Aufzugreifen und tam tam, jeder wollte es (frag mich ja wie AMD das anstellte).

Wenn ich mich recht erinnere, hatten MIPS und DEC ja bereits Anfang der 90er-Jahre 64bitter im Programm. Itanium debütierte allerdings erst ~2001.

IA64 konnte zwar auch 32bit-x86-Code verarbeiten, jedoch nicht sonderlich schnell. Und wer wollte schon quasi exklusiv auf eine inkompatible Architektur umschwenken?

Vorteil der AMD-Lösung war/ist ja, dass man auch weiterhin unter 32bit hohe Perfomance erhielt und 64bit als Gimmick mit einsacken kann. Und da Intel den Zug verschlafen hatte, musste eben AMD ran (so langsam machen 64bit-System ja auch Sinn). Und spätestens beim Vista-Nachfolger sind dann 4GB für das flüssige Arbeiten mit Notepad ein Muß *schwarzseh*. :)

BlackBirdSR

2007-09-24, 18:45:59

Die erwähnten Intel und AMD CPUs sind alles reine 64Bit-CPUs. Punkt Aus!

Gast

2007-09-24, 18:52:37

so 64bitig, wie z.b. ein powerpc, der von anfang an als (also Anfang der 90iger) 64bit cpu ausgelegt wurde? x86 ist ja im Gegenzug immer erweitert worden (Erweiterung).

The PowerPC Architecture Specification, released in 1993, is a 64-bit specification with a 32-bit subset.
http://www.ibm.com/developerworks/library/l-ppc/

Coda

2007-09-24, 19:11:38

Ja.

Avalox

2007-09-24, 19:46:33

AMD und Intel sind in dem Punkt identisch...

Nein, sind sie nicht.

Intels Ansatz hat seine Probleme. AMD ist dort besser.

Unter 64bit nimmt die Opcode Länge zu, die Intel Dekoder können nicht mehr optimal beaufschlagt werden. Diesen Engpass hat AMD nicht.
Zudem Intels MacroOp Fusion nicht im 64Bit Modus funktioniert. Kostet der Core Architektur ordentlich Performance im 64Bit Mode.

Intel Core2 hat zwei Integerer Multiplizierer, aber nur einer von denen ist in der Lage 64Bit Operationen auszuführen. Der Core2 L1 Cache ist zudem zu klein designt für 64Bit Instruktionen.

Andreas Stiller attestiert damit dem Core2 strukturelle 64Bit Schwächen.
Tatsächlich bensht Intel den Core2 dann auch nur im 32Bit Mode, obwohl für Server heute kaum noch von Bedeutung.

nein der Core2 ist ein besserer 32Bit, als 64Bit Prozessor Kern.

AMD hat diese Probleme nicht.

Coda

2007-09-24, 19:55:20

Unter 64bit nimmt die Opcode Länge zu, die Intel Dekoder können nicht mehr optimal beaufschlagt werden. Diesen Engpass hat AMD nicht.
Stimmt nicht. Das Problem hat AMD genauso.

Kostet der Core Architektur ordentlich Performance im 64Bit Mode.
Hab ich noch nirgends gesehen. Core 2 ist in 64 bit meistens schneller als im 32-Bit-Modus.

Intel Core2 hat zwei Integerer Multiplizierer, aber nur einer von denen ist in der Lage 64Bit Operationen auszuführen.
Erstmal: Quelle?
Zweitens: AMD hat erst gar keine zwei. Zudem braucht man die 64-Bit-Multiplikation fast ausschließlich für Adressoperationen. Das muss kein Bottleneck sein. Es ist ja nicht so, dass man die 32-Bit-Multiplikation in 64-Bit-Code nicht einsetzen könnte. Arithmetik ist dort nämlich zu 99% auch nur 32-Bit.

Der Core2 L1 Cache ist zudem zu klein designt für 64Bit Instruktionen.
x86-64-Code ist im Durchschnitt 10-15% größer. Das ist doch lächerlich.

Avalox

2007-09-24, 20:05:47

Stimmt nicht. Das Problem hat AMD genauso.

ne. Eigentlich nicht. Der K10 geht dort deutlich breiter (32Bit) als K8 oder Core2 (16Bit) zu werke.

Hab ich noch nirgends gesehen. Core 2 ist in 64 bit meistens schneller als im 32-Bit-Modus.

Sehe dir mal Intels Spec Ergebnisse an. Alle Tests sind im 32Bit Modus ausgeführt. Warum wohl?

Erstmal: Quelle?

c't 20/07, Seite 174, "Parade der Quadrigen"

" Core2...2 Multiplizierer .. Davon allerdings beherrscht nur derjenige am Port 0 auch 64Bit Operationen und der ist dabei in seiner Latenzzeit auch noch um einen Takt langsamer als der vom Operon (K10)." Übrigens letzterer auch 128bit in einem Durchgang beherrscht.

x86-64-Code ist im Durchschnitt 10-15% größer. Das ist doch lächerlich.

Opcode Länge nach Analyse (selbe Quelle oben)

Durchschnitt Opcode Länge im 32Bit Mode 2,2 Byte. Im 64Bit Mode 4,3 bis 4,7 Byte. Also schon erheblich grösser und L1 Cache des Core2 damit zu klein.

Coda

2007-09-24, 20:07:51

Aber auch erst bei K10. An dem Punkt definiert sich sicher keine "64-Bit-Architektur".

Zudem wurde das primär aufgebohrt um den Durchsatz ihrer 128-Bit-Vektoreinheiten zu gewährleisten und hat gar nichts mit 64 bit zu tun.

Gast

2007-09-24, 20:12:12

Warum wurde mein Post gelöscht, in dem ich darauf hinweise, das das hier ein reiner Intel /Core2 Bashfred ist?

Coda

2007-09-24, 20:24:25

Sehe dir mal Intels Spec Ergebnisse an. Alle Tests sind im 32Bit Modus ausgeführt. Warum wohl?
Jeder 32- vs. 64-Bit-Benchmark den ich von C2D gesehen hab sagt dass es keinen starken Einbruch gibt.

Spec ist eh komisch, da kann auch der Intel-Compiler unter 64-Bit noch nicht darauf "optimiert" sein.

" Core2...2 Multiplizierer .. Davon allerdings beherrscht nur derjenige am Port 0 auch 64Bit Operationen und der ist dabei in seiner Latenzzeit auch noch um einen Takt langsamer als der vom Operon (K10)."
Wie gesagt sehe ich da keinen großen Bottleneck. 64-Bit-Multiplikationen sind äußerst selten.

Übrigens letzterer auch 128bit in einem Durchgang beherrscht.
Es gibt keine 128-Bit-Integer-Multiplikation im x86 Befehlssatz.

Durchschnitt Opcode Länge im 32Bit Mode 2,2 Byte. Im 64Bit Mode 4,3 bis 4,7 Byte. Also schon erheblich grösser und L1 Cache des Core2 damit zu klein.
Völliger Blödsinn. Das REX-Präfix wird nur in den Befehlen vergeben die es benötigen und belegt dann nur 1 Byte. Selbst wenn jede Instruction eins hätte wären wir nach der Statistik dann bei 3,2 Byte. AMD gab beim K8-Release 10-15% an. Denen glaube ich das schon. Außerdem würde ich das auch so abschätzen.

Die C'T ist schon lange nicht mehr so verlässlich wie sie einmal war.

Avalox

2007-09-24, 20:27:53

Aber auch erst bei K10. An dem Punkt definiert sich sicher keine "64-Bit-Architektur".

Na ja. Auch der Opcode des SSE Codes wird immer grösser. Nee, nee so optimal ist der Core2 nicht auf die Zukunft hin designt. Musste halt schnell gehen damals...

Coda

2007-09-24, 20:30:48

Auch der Opcode des SSE Codes wird immer grösser.
Bitte was? Meinst du "Die Opcodes"? Nein, die werden in einer Architektur die eine bestimmte SSE-Version unterstützt sicher nicht auf einmal größer.

Nee, nee so optimal ist der Core2 nicht auf die Zukunft hin designt.
Das Ding schlägt sich in jedem nicht-synthetischen 64-Bit-Integer-Benchmark besser als ein K10. Da geh ich mit dir jede Wette ein.

Avalox

2007-09-24, 20:33:40

Völliger Blödsinn. Das REX-Präfix wird nur in den Befehlen vergeben die es benötigen und belegt dann nur 1 Byte. Selbst wenn jede Instruction eins hätte wären wir nach der Statistik dann bei 3,2 Byte.

c't hat die Spec CPU200 Suite genommen (mit Intels 9.1 Compiler)

Intel geht auf dieses Thema wohl sogar auf die dadurch im 64Bit Mode beim Core2 unvermeidlichen Wartezyklen (Front End Starvation) im Software Optimierungs Guide gezielt ein. Eben dass man dagegen eh nichts machen kann und es "nur" bei schnellen SSEx Code Auswirkungen hätte.

Coda

2007-09-24, 20:34:14

c't hat die Spec CPU200 Suite genommen (mit Intels 9.1 Compiler)
Es kann aber nicht stimmen. Es ist technisch nicht möglich. REX belegt 1 Byte und wird lange nicht bei jeder Instruction gesetzt. KA was die da für Mist gemacht haben.

Eben dass man dagegen eh nichts machen kann und es "nur" bei schnellen SSEx Code Auswirkungen hätte.
Und das hat nichts mit 64-Bit zu tun.

Avalox

2007-09-24, 20:34:53

Bitte was? Meinst du "Die Opcodes"? Nein, die werden in einer Architektur die eine bestimmte SSE-Version unterstützt sicher nicht auf einmal größer.

Nein SSE Opcode ist als solchen grösser und wird immer mehr benutzt. Das führt zu grösseren allgemeinen Opcode. Im 32Bit, wie im 64Bit Mode. Nicht gut für den Core2.

Tesseract

2007-09-24, 20:35:02

Intels Ansatz hat seine Probleme. AMD ist dort besser.
[...]
nein der Core2 ist ein besserer 32Bit, als 64Bit Prozessor Kern.

die bit-tiefe ist aber kein performancerating. es sind beides "vollständige" 64 bit CPUs, selbst wenn der core 2 unter 64bit nur 10% seiner 32 bit performance hätte.

du sagst ja auch nicht der p4 war ein 16 bit prozessor weil netburst scheiße ist oder?

mir scheint es, als wüssten manche nichtmal was 64 bit überhaupt bedeutet. o_O

Coda

2007-09-24, 20:35:56

Nein SSE Opcode ist als solchen grösser und wird immer mehr benutzt.
Das hat immer noch nichts mit 64-Bit zu tun. Was willst du also sagen?

Ein Opcode ist übrigens ein einziger Befehl. Deine Nomenklatur stimmt nicht.

Avalox

2007-09-24, 20:40:49

es sind beides "vollständige" 64 bit CPUs,

habe ich auch nicht behauptet. Ich habe nur dagegen gesprochen, dass "AMD und Intel sind in dem Punkt identisch..." sind.
Sind sie nicht. AMD macht es besser unter 64Bit als Intel. Der Core2 ist ein besserer 32Bit Prozessor, als 64Bit Prozessor. Mehr nicht.

Das hat immer noch nichts mit 64-Bit zu tun. Was willst du also sagen?

Das, dass Problem, was der Core2 schon immer bei SSE Befehlen hatte, natürlich auch für 64Bit Befehle gilt, nicht aber für 32Bit Befehle.
Kurzum, der Core2 L1 Cache ist zu klein für einen modernen (64Bit) Prozessor. Wirkt sich bei 64Bit Code (modern) eben stärker aus, als bei 32Bit Code (von vorgestern).

Coda

2007-09-24, 20:44:37

Sind sie nicht. AMD macht es besser unter 64Bit als Intel.
Nein. Sie machen es mit SSE-Code besser als Intel. Mit Integer-Instructions ist das auch unter 64-Bit bei Core 2 niemals ein Bottleneck.

Der Core2 ist ein besserer 32Bit Prozessor, als 64Bit Prozessor. Mehr nicht.
Ist er nicht. Der 64-Bit-Modus ist genauso performant.

Kurzum, der Core2 L1 Cache ist zu klein für einen modernen Prozessor. Wirkt sich bei 64Bit Code (modern) eben stärker aus, als bei 32Bit Code (von vorgestern).
Der Intel-Cache hat dafür eine viel höhere Assoziativität. Das kannst du einfach nicht über einen Kamm scheren. Würde er nicht reichen, hätte Core 2 nicht diese Performance.

BlackBirdSR

2007-09-24, 21:03:20

Wir reden hier von Unterschieden von 10% Leistung.
Wer weiss, wie viel mehr Performance der K8 in 64Bit Applikationen erreichen könnte, wenn er nicht dies und jenes Problem hätte, von dem wir nichts wissen?

Macht ihn das zu einer besseren 32Bit CPU? Nahezu alle benchmarks die ich gesehen habe, zeigen auch beim Core2 einen Performancezuwachs. Es gibt Ausnahmen, die gibt es aber auch bei AMD. Interessanterweise gewinnt meist der P4 beim höchsten Zuwachs.. ist also der P4 die beste 64Bit CPU? Ganz ehrlich... das ist alles BS.

Nach Definition wie alle anderen 64Bit CPUs auch definiert werden, sind K8/10 und Core2/Prescott reine 64Bit CPUs. WIe die Implementation auf Ebene der µArchitektur aussieht ist irrelevant und ein ganz anderes Gebiet.

Sicherlich hat Core2 hier und da ein paar Probleme. Das liegt aber daran, dass die in Israel sicher nicht darauf vorbereitet waren. Who Cares? Core2 ist auch dann schneller, wenn er langsamer wird.. das zählt.
Er ist schneller als jeder P4, obwohl dieser am Meisten nutzen aus einer gegebenen 64Bit-Applikaion ziehen kann.

Also µArchitektur und ISA bitte trennen. Ja zu verbesserungswürdigen Sachen in K10 und Core2, Nein! zu "bessere 32Bit CPU als 64Bit CPU. Es gibt unter AMD und Intels modernen CPUs keine 32Bit CPUs mehr.

Avalox

2007-09-24, 21:04:41

Der Intel-Cache hat dafür eine viel höhere Assoziativität. Das kannst du einfach nicht über einen Kamm scheren.

Das denke ich aber auch. Die Cache Strategien unterscheiden sich ja schon durchaus. L2 z.B. Der Barcelona hat ja z.B. nun 32 Prefetcher und auch spekulative Stack Tracker. (? letztere hat der Core2 wohl auch, aber eben in seiner 2 x 2Kern Variante nur 16 Prefetcher)

Ist dort schon ziemlich unterschiedlich.

Avalox

2007-09-24, 21:14:18

Nein! zu "bessere 32Bit CPU als 64Bit CPU. .

Nein? Ich denke schon.

Ich denke auch, dass Intels in letzte Sekunde "umgefummelte" eigene x86 64Bit Erweiterung als Altlast in den Intel Kernen schlummert. Anders lassen sich solche seit dem Merom mitgeschleppten Eigenheiten kaum erklären.

Coda

2007-09-24, 21:34:04

Welche Eigenheiten denn?

Avalox

2007-09-24, 21:51:07

Welche Eigenheiten denn?

Ich zitiere mal wortwörtlich:

Core2 unter 64Bit
"Der Nachschub aus dem Instruktionscache reicht nicht aus,
die Makro-Op-Fusion läuft nicht und die Micro-Op-Fusion für Gleitkomma auch nicht wirklich.
Diese funktioniert nämlich nicht für SSE Befehle, die unter 64Bit üblicherweise satt der FPU Befehle
verwendet werden. Und dann kann von den beiden Integer Multiplizieren auch nur einer 64Bit Berechnungen
durchführen und ist dabei auch noch langsamer als derjenige des Opterons. Die L1 Caches sind für längere
Instruktionen bei 64Bit sowie die grösseren Pointer auch etwas zu klein.
"

Core2 in 64Bit.

StefanV

2007-09-24, 21:58:17

Achja, der C2D hat ja nur 32k L1 Cache, oder??

Gast

2007-09-24, 22:05:34

@Avalox
*gähn*. Schau ein paar Postings weiter vorher. Es gibt keine Performancenachteile in 64 bit. Und jetzt hör bitte auf diese Unwahrheiten verbreiten zu wollen.

Zudem ist es reichlich behämmert anzunehmen, das jede Architektur gleichermaßen von Optimierungen profitiert. Was unter 32 bit gut ist, muss es unter 64 bit nicht umbedingt und natürlich auch umgekehrt.

Thunderhit

2007-09-24, 22:09:25

2x32k L1 Cache

Gast

2007-09-24, 22:12:50

Achja, der C2D hat ja nur 32k L1 Cache, oder??
2*32K Data
2*32K Code

Avalox

2007-09-24, 22:17:58

Schau ein paar Postings weiter vorher. Es gibt keine Performancenachteile in 64 bit. Und jetzt hör bitte auf diese Unwahrheiten verbreiten zu wollen..

Es ist richtig grosser Quatsch was du schreibst. Fakt ist, dass die aufgeführten Details handfeste Nachteile des Core2 unter 64Bit sind. Es sind Fakten.

Ein Benchmark dagegen ist kein Fakt. Ein Benchmark ist eine momentane und sehr spezielle Erhebung einer bestimmten Situation und kann beim nächsten Test ganz anders aussehen.

Ich frage mich nur, weshalb Intel z.B die Spec Suite nur unter 32Bit testet?
Eigentlich frage ich mich nicht, denn die c't hat die Spec Werte unter 64Bit schön unparteiisch ermittelt und es dürfte klar sein, was der Antrieb ist von Intel nur unter 32Bit zu testen.
So ist es natürlich auch ein Performance Nachteil, eben nicht alle Vorteile von AMD64 zu erschließen. Es sind keine Welten, es ist nur unsäglich unelegant.

Coda

2007-09-24, 22:21:05

Es ist richtig grosser Quatsch was du schreibst. Fakt ist, dass die aufgeführten Details handfeste Nachteile des Core2 unter 64Bit sind. Es sind Fakten.
Spielt keine Rolle weil die 64-Bit-Performance durch die gesunkenen Speicherzugriffe trotzdem im Durchschnitt mindestens gleich gut ist.

http://www.xbitlabs.com/articles/cpu/display/core2duo-64bit_6.html
Wo ist da das Problem? Da sind einige verschiedene Workloads dabei.

Das CT-Zitat ist für den Arsch. Da ist einiges falsch ausgelegt worden.

Gast

2007-09-24, 22:21:18

Es ist richtig grosser Quatsch was du schreibst. Fakt ist, dass die aufgeführten Details handfeste Nachteile des Core2 unter 64Bit sind. Es sind Fakten.

Ja, das trifft vorallem auf deine Aussagen zu. In der Praxis ist von deinen aufgeführten (und nicht vorhandenen) "Nachteilen" nix zu sehen!

Du scheinst auch nicht gerade bewandert in diesem Thema zu sein. Du kannst nicht einfach von 32 auf 64 bit schließen.

Bokill

2007-09-24, 22:22:53

amd hat ja echte 64bit cpus. die intel sind ja eigentlich noch 32bit cpus, die auf 64bit erweitert sind. merkt man man auch, da die amds mehr von 64bit profitieren.

wann hat auch intel echte 64 bit cpus? Kennst du den Itanium? Offenbar nicht ...

Wenn du allerdings x86-64 meinst, ja und was machts aus, wenn Intel einen Hauch weniger dabei skaliert?

Zu wenige nutzen 64 Bit Windows, zu wenige nutzen Linux, oder Solaris 10, als dass dabei das "Ende der Welt" droht.

Was nutzt AMD im 64 Bit Bereich ein dezentes "Boden gut machen", wenn im 32 Bit Massengeschäft die Core 2-Familie meistensteils mehr oder weniger deutlich vorne liegt und mit dem Penryn abermals die Messlatte höher gelegt wird?

Jedenfalls ist der 64 Bit Betrieb bei der Core 2-Familie wesentlich wettbewerbsfähiger, als bei dem Itanium die 32 Bit x86-Unterstützung.

MFG Bobo(2007)

Avalox

2007-09-24, 22:29:13

In der Praxis ist von deinen aufgeführten (und nicht vorhandenen) "Nachteilen" nix zu sehen!

Was ist schon Praxis?

Kennst du 429.mcf? Berechnungen zur Chromo-Quantendynamik.
Dort ist der Core2 mit der 32Bit Version doppelt so schnell, wie mit der 64Bit Version. Mal als Beispiel.

403.gcc ist als 32Bit Version gar drei mal schneller, als als 64Bit Version auf dem Core2.

BlackBirdSR

2007-09-24, 23:26:41

Was ist schon Praxis?

Kennst du 429.mcf? Berechnungen zur Chromo-Quantendynamik.
Dort ist der Core2 mit der 32Bit Version doppelt so schnell, wie mit der 64Bit Version. Mal als Beispiel.

403.gcc ist als 32Bit Version gar drei mal schneller, als als 64Bit Version auf dem Core2.

Hast du Links oder Beispielewerte? Ich habe die Datenbank mal durchforstet und für 403.gcc bei 3GHz zeigen sich 10 gegenüber 11.3 für die 32Bit Version. Nicht unbedingt doppelt so schnell....

Coda

2007-09-24, 23:30:42

Ist auch hochgradiger Bullshit. 3x so schnell kann auf keinen Fall sein.

Avalox

2007-09-24, 23:32:10

Hast du Links oder Beispielewerte? Ich habe die Datenbank mal durchforstet und für 403.gcc bei 3GHz zeigen sich 10 gegenüber 11.3 für die 32Bit Version. Nicht unbedingt doppelt so schnell....

Die c't hat getestet. Dabei "Base" Compilate, durchgängig ohne Smart Heap Library und auch mal ohne Intel Compiler.

Coda

2007-09-24, 23:35:09

3x so langsam ist unmöglich, deshalb ist der ganze Benchmark als Müll zu betrachten.

Sorry, falls ich mich wiederhole, aber das tut schon weh. Haben sie vergessen beim 64-Bit-Kompilat die Optimierungen anzuschalten oder was? Dazu würde die angeblich doppelt so hohe Code-Density passen.

Avalox

2007-09-24, 23:36:19

Ist auch hochgradiger Bullshit. 3x so schnell kann auf keinen Fall sein.

Bin mir sicher, wenn man direkt auf die Core2 64Bit Strukturschwäche hin programmiert, bekommt man noch um Grössenordnungen beeindruckendere Ergebnisse hin. Sind halt dann nur noch sehr eingeschränkt Praxis tauglich.

Coda

2007-09-24, 23:38:24

Nein. In der Größenordnung ist das nichtmal dann möglich. Da ist definitiv was schief gelaufen.

Und wie Hellhorse schon angedeutet hat sieht die SPEC-Datenbank ganz anders aus. Vor allem ist GCC hochgradig Speicher- und Integer-lastig. Da wird Core 2 in 64-Bit ganz ganz sicher nicht 3x so langsam sein. Die c't sollte echt mal ihr Hirn einschalten bevor sie so nen Dreck abdrucken.

Avalox

2007-09-24, 23:48:28

und Integer-lastig. Da wird Core 2 in 64-Bit ganz ganz sicher n

Die Intel Integer Spec Werte sind im Test ohne SmartHeap eh alle mächtig abgesackt und bei weiten nicht mit den von Intel selbst präsentierten Ergebnissen zu vergleichen. Die SpecSuite ist ja wohl der Benchmark an dem am meisten rum optimiert wird. Man sollte schon "gleich" messen und nicht mit irgend welchen Datenbank Werten vergleichen.

Coda

2007-09-24, 23:50:12

403.gcc misst einen ganz normale GCC-Durchlauf beim Kompilieren von Sourcecode mit Optimierung für die K8-Architektur.

Und nein, da ist ein 64-Bit-GCC ganz ganz sicher immer noch nicht 3x langsamer als ein 32-Bit-GCC. Da kannst du mir erzählen was du willst. Da würden schon lange die Linux-Kernel-Entwickler aber sowas von einen Aufstand gemacht haben, das kannst du mir glauben.

Deshalb: Benchmark = Müll. Und der ganze Artikel gleich mit. Allein die angebliche doppelte Code-Density ist schon lächerlich genug, aber das macht das Fass echt voll.

misterh

2007-09-25, 00:11:39

@ Avalox

Die Wahrheit zu lesen tut weh oder? :)

lass einfach jetzt sein und gut ist es.

Avalox

2007-09-25, 00:21:32

lass einfach jetzt sein und gut ist es.

Ich sehe überhaupt keinen Widerspruch. Ich sehe nur unterschiedliche Compilate. Welche dort getestet wurden.

Einmal mit dem Anspruch eben schnellst möglichen Code zu erzeugen, dort werden entsprechende Librarys und Einstellungen verwendet.

Im anderen Fall eben möglichst vergleichbaren Code zu erzeugen. Was ich für die Aufgabe eines CPU Vergleichs auch für den durchaus richtigen Ansatz erachte.

Ich weiss auch nicht, weshalb die Opcode Länge so kategorisch abgelehnt wird? Wird gleich mehrmals erwähnt. Empfinde ich als extrem beachtenswerte Feststellung.

BlackBirdSR

2007-09-25, 00:22:34

@ Avalox

Die Wahrheit zu lesen tut weh oder? :)

lass einfach jetzt sein und gut ist es.

Spar dir solche Posts, sonst kannst du das mitschreiben hier "lassen"
Es ist noch gar nicht beweisen, wer recht hat und wer nicht. Bis zu 5 bytes im 64Bit Modus sind durchaus möglich, aber sehr selten. Der Durschnitt sollte weit darunter liegen.
Es bleibt interessant was die c`t hier getestet hat, und warum die Werte so extrem abweichen sollen.

Spec ohne alle Optimierungen zu testen ist übrigens brandgefährlich, da sich das Bild somit noch mehr verzerrt. Es wird dann plötzlich unüberschaubar, inwiefern der Code noch "optimal" ist, und nicht zusätzliche Probleme entstehen. Als würde man 3dmark ohne sämtliche normale Optimierungen der Treiber für Routinen und Shader testen, und daraufhin Vergleiche anstellen.

Nochmal: Core2 ist sicherlich nicht optimal, und es gibt viel zu verbessern. Man merkt auch, dass Intels Team nicht unbedingt darauf vorberitet war AMDs Konzept zu übernehmen. Die eingesetzen Technologien und Prinzipien sind ja schon älter als die CPU, und man hatte entweder keine Zeit oder Expertise diese mit AMD64 in Einklang zu bringen. Prescott ging es ja nicht viel anders.
Dieser profitiert allerdings überproportional von vielen 64Bit-Versionen, verliert manchmal aber auch stark. Trotzdem ist es von allen CPUs die mit der geringsten Menge an zwischengespeichertem Code!

Coda

2007-09-25, 00:29:19

Ich weiss auch nicht, weshalb die Opcode Länge so kategorisch abgelehnt wird? Wird gleich mehrmals erwähnt. Empfinde ich als extrem beachtenswerte Feststellung.
Wenn es Debug-Code ohne Optimierungen ist, wird jeder Zugriff auf eine Variable mit einem Speicherzugriff ausgeführt, d.h. es werden beträchtliche mengen an Load- und Store-Ops eingeführt die jeweils 3 Bytes mehr haben als im 32-Bit-Modus.

Das ist aber absoluter Blödsinn damit irgendwas zu vergleichen, weil niemand so Code ausliefert. x86-64-Code ist im Durchschnitt sicher nicht 2x so groß und GCC ist mit 64-Bit kompiliert auch ganz sicher nicht 3x so langsam.

Und falls das so ist, dann liegt es am Kompilat und ist auf einem anderen x86-64-Prozessor auch nicht anders.

SavageX

2007-09-25, 07:55:45

Deshalb: Benchmark = Müll. Und der ganze Artikel gleich mit.

Einspruch. Die vom Artikel genannten Einschränkungen im 64bit-Betrieb scheinen nunmal Fakt zu sein - dem Design merkt man es an, dass 64bit eher drangetackert worden sind. Ist ja auch lediglich die erste Iteration der Core-Architektur mit 64bit-Unterstützung.

Ob diese Einschränkungen jetzt tatsächlich schwer wiegen steht auf einem anderen Blatt.

HOT

2007-09-25, 08:24:00

Man muss immer sehen, unter welchen Gesichtspunkten die c't den Prozessor getestet hat, es handelt sich ja um Server bezogene Benchmarks und hier sind 32Bit Kompilate schonmal per se purer Schwachsinn, da absolut nicht mehr praxisbezogen. Von daher musste die c't ja so handeln, um einigermassen brauchbare Ergebnisse zu bekommen - Intels empfohlene Benchmarkkonfiguration jedenfalls ist als CPU Leistungsvergleich absolut 100% unbrauchbar und dienen wirklich lediglich dazu, die CPUs besonders gut darstehen zu lassen. Man hat die Intel CPUs ja auch mit Intel optimiertem Compiler getestet, aber eben nur in 64Bit und ohne SH.

Na jo, ich frage mich schon, ob die Benchmarks, die demnächst auf dem K10 laufen werden, auf XP32 gemacht werden... am liebsten wäre mir, wenn sowohl XP32 als auch Vista64 getestet würden, denn nur so würde man ein echtes Bild über die Performance bekommen. Generell sollte man in Zeiten, in denen 4GB RAM langsam zum Standard werden, auch 64Bit OSe mittesten. Ich nutze Vista64 schon lange und habe auch 4GB RAM, der mit 32Bit nicht sinnvoll einsetzbar ist. Ich befürchte, dass die Testreihen demnächst nur wenig Aussagekraft haben werden, wenn der K10 auf den Markt kommt...

Gast

2007-09-25, 11:09:48

am liebsten wäre mir, wenn sowohl XP32 als auch Vista64 getestet würden
Mir wäre der Vergleich XP32 zu XP64 lieber.

Meinetwegen auch zusätlich noch Vista32 und Vista64.

Bokill

2007-09-25, 12:54:38

Selbst Sun setzt mitunter 32 Bit Programme und Code ein, wenn es sinnvoll nutzbar bei 64 Bit Systemumgebungen erscheint.

Die Power-Prozessoren-, UltraSPARCs ermöglichen nach wie vor auch den Betrieb von 32 Bit Software. Man sollte das in der Beurteilung der x86-64 Core 2-Kerne berücksichtigen.

Zum einen freut es mich als AMD K8-Nutzer, wenn AMD offenbar von Grund auf den CPU-Kern auf 64 Bit ausgerichtet hat, aber ich kann verstehen, dass Intel nach wie vor in Teilen auf 32 Bit auch in der Microarchitektur setzt. 32 Bit dominieren nach wie vor und kommen auch in der Blade und Serverwelt nach wie vor vor, auch wenn dort 64 Bit Betriebssysteme häufiger eingesetzt werden.

MFG Bobo(2007)

PHuV

2007-09-25, 13:09:09

Warum stellen wir nicht einfach mal gewisse Dinge nach?

Was ist schon Praxis?

Kennst du 429.mcf? Berechnungen zur Chromo-Quantendynamik.
Dort ist der Core2 mit der 32Bit Version doppelt so schnell, wie mit der 64Bit Version. Mal als Beispiel.

403.gcc ist als 32Bit Version gar drei mal schneller, als als 64Bit Version auf dem Core2.

Ich habe auch schon 64-Bit-Portierungen gemacht, und wenn die Performance so gewaltig in einigen Sachen so derartig abgesackt wäre, hätte ich das bemerkt. Von dem her kann ich mir diesen Abfall der Werte auch nur mit einem Bedienungsfehler erklären.

Machen wir den Test, nehmen wir ein beliebiges 64-Bit-Linux, und booten damit auf einem Core2 und auch einem AMD X2, und dann komplieren wir mal mit gcc und messen die Ergebnisse des Programmes.

Gast

2007-09-25, 14:30:40

mrt

2007-09-25, 20:31:50

Intel wollte das nicht, sie hielten IA-64 für den besseren Ansatz. Heute wissen wir, dass das nicht stimmt.

@Topic
Welch blöde Frage eigentlich? C2D ist eine echte 64Bit CPU, da gibts nichts halbes...

BlackBirdSR

2007-09-26, 02:49:26

" Core2...2 Multiplizierer .. Davon allerdings beherrscht nur derjenige am Port 0 auch 64Bit Operationen und der ist dabei in seiner Latenzzeit auch noch um einen Takt langsamer als der vom Operon (K10)." Übrigens letzterer auch 128bit in einem Durchgang beherrscht.

Ein 128Bit IMUL in der ALU halte ich für ein Gerücht. Die ALUs im K8/10 sind auch nur 64Bit breit.
Was die IMUL mit 5 Takten Latenz frisst, gleicht Core2 durch den höheren Takt z.B aus.

PS: Alles was ich finden konnte (auch in den Intel Docs,) spricht von einer ALU mit MUL-Fähigkeiten. Andreas gibt nicht zufällig an, wo er das mit der 2. ALU die IMUL kann gefunden hat? Eventuell wurde hier Einheit mit Port vertauscht?
Core2 kann durch Port 0 64Bit Multiplikationen ausführen, nicht aber durch Port1, wo die FMUL angeschlossen ist.
Ich muss also davon ausgehen, dass die c`t hier fehlerhaft abgelesen hat, oder es blöd geschrieben ist