Sinn und Unsinn von 64bit

[Dresdenboy]

Original geschrieben von PuckPoltergeist
Das meine ich auch nicht. Sicherlich kann man diese CPUs genauso gut im 32bit-Modus laufen lassen. Wenn man aber die Vorteile der neuen Architektur (mehr Register) nutzen will, ist man zu den 64bit gezwungen. Dass dabei die Nachteile davon nicht mal ansatzweise erwähnt werden, sondern nur hervor gehoben wird, wie toll und schnell das doch ist, das stört mich wirklich. Ich habe bis jetzt noch nirgends einen Bericht oder Test gelesen, wo das wirklich beleuchtet wird. Das Resultat ist dann, dass alle Welt von 64bit schwärmt, obwohl das weitestgehend nutzlos ist.

Da hat sicher jeder unterschiedliche Prioritäten. Und das die Vorteile etwas mehr hervorgekehrt werden, ist doch normal. Intel hat ja auch nicht auf quadratmetergroßen Postern deutlich gemacht, wie schnell der Itanium x86-Code ausführt.

Ich denke auch, daß objektorientierte Apps (wie Firefox) am anfälligsten sind für diesen Speicherverbrauchsnachteil. Aber diese sind zum Glück ja nicht die Einzigen. Ich hatte ja schon woanders erwähnt, daß durch die 32bit-Ausführung der Nachteil gemildert werden kann (braucht dann allerdings extra libs usw.). Dahin kann man ja tunen. Aber ich möchte auf 64bit nicht mehr verzichten. 64bit NTTs in 32bit zu berechnen... *schüttel*

 

[PuckPoltergeist]

Original geschrieben von Dresdenboy
Aber ich möchte auf 64bit nicht mehr verzichten. 64bit NTTs in 32bit zu berechnen... *schüttel*

Naja, wie oft werden 64bit-ints wirklich gebraucht? Ich bin der Meinung, dass sowas doch hauptsächlich Spezialsoftware betrifft. Otto-Normaluser sollte mit seinem Desktop doch eher weniger damit in Berührung kommen. Außerdem sind schon mit MMX seit langem 64bit-Operationen auf ints möglich. Eine dringende Notwendigkeit bei den GPRs bestand da also auch nicht.

 

[Dresdenboy]

Original geschrieben von PuckPoltergeist
Außerdem sind schon mit MMX seit langem 64bit-Operationen auf ints möglich. Eine dringende Notwendigkeit bei den GPRs bestand da also auch nicht.

So trivial ist das nicht. Und mit den 64bit Adds/Shifts/Logikoperationen kann man nicht wirklich viel reißen. Zeitfresser Nr. 1 ist Multiplikation und da ziehe ich die 2 Takte Durchsatz mit MUL einem Stück MMX-Code, welcher mit vielfachen 32bit Muls dieselbe Operation emulieren muss, vor. Es ist so schon langsam genug für die Zielgruppe. Da braucht es keine künstliche Bremsung um Faktor 5-10

 

[rkinet]

Original geschrieben von PuckPoltergeist
Außerdem sind schon mit MMX seit langem 64bit-Operationen auf ints möglich.

Die MMX-Unit ist keine ALU, also arithmetrisch & logisch (Boolean, Shift).
Selbst in Assembler wäre diese Pseudo 64 Bit-Programmierung ein Krampf ohne Ende.

Ein Compiler würde daran völlig verzweifeln und müßte ständig Daten umschaffeln lassen.

Zur Info:
Beim CPU-Core gilt 'Geiz ist geil' nun wirklich nicht, seit Ewigkeiten.
Bei alten 386 wären 64 Bit noch eine große Sache gewesen, heute nicht mehr.

Außerdem:
Vorteil von x86-64 ist auch, daß sowohl kaum speicherplatzfressende Desktop-Entwicklungen möglich wären, als auch Server oder sonstiges bytehungriges Zeug.
Man müßte zwei Designs / Compiler / Workstation Plattformen vorhalten, was ja sichtbar beim Itanium gescheitert ist.
Zukünftig kann man 64 Bit Compiler an viele Käufer absetzten, selbst wenn nur ein Bruchteil davon für wirklich 64 Bit-lastige Aufgaben nötig ist. Nur, die würden sich freuen, wenn sie für einen Primitiv-Compiler $10.000 /Lizenz zahlen müßten, weil alles eben Sonderanfertigung ist.

Also PuckPoltergeist, mal die wirtschaftliche Vernunft einschalten. Nur weil 1 von 100 Anwendungen zukünftig 0,1s länger Daten auslagert, soll Intel den Prescott wegwerfen, den Sossaman einstampfen und die Merom-Schaltpläne löschen ?
Oder AMD einige Millionen A64 aus Kulanz zurücknehmen von den Usern.
Damit dann sich viele Ingenieure darum kümmern, ein Kastrat nach Deinen Wünschen zu entwickeln ?

 

[PuckPoltergeist]

Original geschrieben von Dresdenboy
So trivial ist das nicht. Und mit den 64bit Adds/Shifts/Logikoperationen kann man nicht wirklich viel reißen. Zeitfresser Nr. 1 ist Multiplikation und da ziehe ich die 2 Takte Durchsatz mit MUL einem Stück MMX-Code, welcher mit vielfachen 32bit Muls dieselbe Operation emulieren muss, vor. Es ist so schon langsam genug für die Zielgruppe. Da braucht es keine künstliche Bremsung um Faktor 5-10

Ich hätte jetzt zwar schwören können, dass MMX bzw. spätestens SSE2 die einfache Multiplikation von 64bit-ints ermöglicht, aber offenbar habe ich mich da geirrt. In diesem Fall bringen die 64bit GPRs definitiv einen Vorteil. 8)

Deswegen bleibe ich aber trotzdem bei meiner Behauptung, dass das für die Masse der Anwender nicht wirklich relevant ist.

 

[UeB]

konnte nicht schon 3dnow multiplizieren? genauso wie der intel apklatsch sse?

 

[PuckPoltergeist]

Original geschrieben von UeB
konnte nicht schon 3dnow multiplizieren? genauso wie der intel apklatsch sse?

Ja, aber nur Fließkomma. Ints lassen sich mit MMX und SSE(2) auch multiplizieren, allerdings nur bis 32bit-Werte, und dafür dann mehrere auf einmal (2 bei MMX und SSE sowie 4 bei SSE2). Die Einheiten sind halt vorwiegend auf SIMD ausgelegt, und nicht dafür, große Datentypen zu bearbeiten. Bei float sind zwar 64bit-Berechnungen möglich, aber das ist keine Kunst. Da war i387 schon bei 80bit.

 

[rkinet]

also:
- 32 Bit
- MMX
- 8087 /80387

Aktuelle CPU haben 64 Bit inside
(Prescott-Kern = P4 und Celeron D)
(K8 im A64 & So. 754 Sempron - in eingen Wochen auch Ersatz für XP und einige T-Bred)

wäre da der Thread nicht besser in der Nostalgie-Ecke aufgehoben ?

Macht es irgendeinen 'Sinn', etablierte Mainstream-Technik kontrovers zu diskutieren ?

Ostern haben wir vielleicht Windows XP x64 im Laden und noch die eine oder andere Budget-Linie zusätzlich bei Intel (Celeron F ?!) oder AMD.

 

[Shdow]

das hast du aber schöne gesagt polly!

*rkineteinenkeksgeb*

es wäre toll wenn du sachen die jeder weist für dich behältst
und zwar bitte nicht nur in diesem Thread.



@puckpoltergeist
das mit dem speicher war ja schon immer das problematische an linux. ja ich weis wie langsam das wird hatte mal suse 6.0 und nur 64 MB Ram wenn man dann noch etwas gestartet hat...

 

[rkinet]

Genau, der Speicherbedarf und 32 Bit:

Bei LINUX gehts bis 1 GByte, dann ist das Design am Limit (per Kernel-Patch sollen auch 3 GB gehen)

Bein Windows gehts bis 2 GByte für Applikationen und zzgl. OS.
Da ist bei 2,5 GByte Bestückung sense.

Bei LINUX ist also 64 Bit ab dem nächsten DRAM-Riegel fällig,
bei Windows kommen die User noch gut 18-36 Monate über die Runden.
Dann geht für 32 Bit das Licht bei Neu-PCs eh aus.


(@PuckPoltergeist - nicht noch einmal die alte Nummer mit den 2 GByte je Applikation und in Summe mehr. Das geht nur, wenn das OS auf PAE stünde und den größeren Adressbereich auch verwalten würde. Geht, iat aufwendig und nur teuer erwerbbar)

 

[Shdow]

hat windows 64 bit eigentlich immernoch die 2GB grenze in 64bit anwendungen?

 

[rkinet]

Original geschrieben von Shdow
hat windows 64 bit eigentlich immernoch die 2GB grenze in 64 bit anwendungen? [/B]

2GB Grenze in 32 Bit Anwendungen bei Windows.

Technisch wären wohl auch 4 GByte für eine 32 Bit Anwendung möglich, nur die leidige 'Kompatibilität'. Windows nutzt die oberen 2 GB für das OS und den PCI-Adressraum.

----

Puck im ersten Beitrag:
Meine Gegenfrage dazu: Warum sollte ich Mitte 2005 auf dem Desktop 64bit einsetzen ?
Brauche ich denn die Leistung, die mir AMD64 zusätzlich bringt, wirklich ?

nun - Intel brauch es sichtlich:

Die P4-Produkte für 2005 des großen Chipsatzproduzenten ... 64 Bit only: (ab 3,0 GHz)
32 Bit gibts dann noch bei 1M Prescott (dürfte Mitte 2005 schon Auslaufmodell sein) und eben beim Celeron - oder beim VIA C3.
Viel Spass dann mit 32 Bit only.

----
http://www.theinquirer.net/?article=19968

Intel offiziell zu EM64T im Desktop:

As for EM64T technology, Intel claims there will be benefits both in high quality audio and video processing as well as 3D rendering.

 

[PuckPoltergeist]

Original geschrieben von Shdow
@puckpoltergeist
das mit dem speicher war ja schon immer das problematische an linux. ja ich weis wie langsam das wird hatte mal suse 6.0 und nur 64 MB Ram wenn man dann noch etwas gestartet hat...

Hm, was meinst du? Wenn der physikalische Speicher zu Ende geht, wird jedes OS langsam das liegt in der Natur von Festplattenzugriffen. Bei Linux ist das halt sehr deutlich bemerkbar.
Und 64MB sind halt auch etwas eng, wenn man X und dazu noch ein fettes Desktop Environment (KDE) einsetzen will.

 

[PuckPoltergeist]

Original geschrieben von PuckPoltergeist
Dass das eine Option des gcc ist, scheint dir da wohl entgangen zu sein, genauso wie die Tatsache, dass dafür max. 3 Register genutzt werden können, egal ob x86 oder x86_64. Dass diese Option bis jetzt auch nur bei x86 Anwendung findet, und ansonst nirgendswo anders weißt du offenbar auch nicht. Dazu reden wir hier nur vom Kernel, die andere Software ist davon noch gar nicht betroffen.

Ok, hier habe ich zum Teil Blödsinn geschrieben. Der gcc nutzt bei x86_64 von Haus aus schon die Register zur Parameterübergabe (max. 6), und läßt sich darin auch nicht offiziell beeinflussen. Offenbar frißt er aber trotzdem das -mregparm=X (eigentlich für i386 vergesehen, mit max. 3 Registern), und produziert dann u.U. fehlerhaften Code.

 

[rkinet]

http://www.theinquirer.net/?article=19968

Intel offiziell zu EM64T im Desktop:

As for EM64T technology,
Intel claims there will be benefits both in
high quality audio and video processing as well as 3D rendering.

The chips, which are set to launch next year,
are already sampling to customers,
and the firm is contemplating releasing them in late February of next year.

Original geschrieben von rkinet
Linux nutzt die 8 zusätzlichen Register zur Parameterübergabe, statt Stack. Das ist nicht die geniale Lösung, aber spart zumindest viele zeitraubende Stackoperationen ein.

Original geschrieben von PuckPoltergeist:
Dass das eine Option des gcc ist, scheint dir da wohl entgangen zu sein, genauso wie die Tatsache, dass dafür max. 3 Register genutzt werden können, egal ob x86 oder x86_64. Dass diese Option bis jetzt auch nur bei x86 Anwendung findet, und ansonst nirgendswo anders weißt du offenbar auch nicht. Dazu reden wir hier nur vom Kernel, die andere Software ist davon noch gar nicht betroffen.
Den Rest deines Blödsinns erspar ich mir jetzt hier zu kommentieren. Bevor du hier andere Leute als IT-Universalgenies mit Null Ahnung bezeichnest, solltest du dir vielleicht erstmal an die eigene Nase fassen

http://www.rrze.uni-erlangen.de/dienste/arbeiten-rechnen/hpc/vortraege/SuSE.pdf

Seite 9:
Parameterüber an Funktionen via Register (6 Parameter) vs. Stack(x86)

Es waren 6, nicht 8 oder nur 3.

Aber, genau wie bei den Nicht-Vorteilen von 64 Bit und der grottenfalschen Behauptung zum doppelten RAM-Verbrauch nur wieder die alte Leier von miserable recherchierten Behauptungen und Beleidigungen.

Puck - polter nur weiter so.
Intels EM64T Desktop-Flut bietet sich die nächsten Monate gerade dazu an, Gift und Galle an Blödsinn über 64 Bit zu verbreiten und von AMD über IBM, MS und jetzt Intel alle als unwissend darzustellen.

 

[xray01]

Doppelte Bit-Breite
Wegen seiner 32-Bit-Architektur stößt Windows XP an seine Grenzen. Ein neuer Tempo-Schub ist erst mit 64-Bit zu erwarten.Unser Test zeigt, ob sich der Aufstieg auf Windows XP 64-Bit Edition wirklich lohnt.

Von Klaus Plessner, Oliver Ehm



Micosoft wird schon bald – zweite Jahreshälfte - eine 64-Bit-Ausgabe von Windows XP ins Rennen schicken.

Technisch gesehen klingt das Upgrade erst mal gut: Windows XP mit 64 Bit kann 4000mal so viel Arbeitsspeicher nutzen wie Windows XP mit 32 Bit, also 16 Terabyte statt vier Gigabyte. Theoretisch rechnet XP-64 auch viel schneller, da der Prozessor pro Taktzyklus doppelt so viele Daten verarbeiten kann. Es spricht vieles dafür, einen neuen PC mit 64-Bit-Prozessor auch mit dem neuen Betriebssystem auszustatten.

Doch der Leistungsschub stellt sich nur unter ganz bestimmten Voraussetzungen ein. So läuft Windows XP 64-Bit Edition eben nur auf Rechnern mit einem 64-Bit-Prozessor – auf Pentium- oder AMD-32- Plattformen verweigert das Betriebssystem den Dienst. Die volle Leistung des 64-Bit-XPs kommt außerdem nur bei mehr als vier Gigabyte RAM zum Vorschein; viele moderne PCs verkraften aber höchstens zwei Gigabyte.

So gelesen, aber auch laut Microsoft wird die volle Leistung bei 4 Gb ereicht.

Vielleicht ist auch der Titel des Beitrags (Sinn oder Unsinn) nicht ganz korrekt. Sinn macht ein 64 System sicher, die Mehrheit der "Umsteiger" wird aber vor allem erst mal bei den Privat Usern liegen. Bei unserem Betrieb wie auch bei einigen andern welche ich kenne wurde jetzt erst auf Windos XP Pro umgerüstet, dazu haben wir 20 neue i865 bekommen. Diese Systeme werden bestimmt die nächsten 5 Jahre oder mehr laufen. Da wir auch Software haben welche im Preis pro Software so an die 20000€ liegen, liegt ein 64 Sytem noch in weiter Ferne.

Was ich in diesem Forum nicht so schön finde, ist das einige alles schlecht machen was nicht den Namen AMD oder trägt, oder auf ein anderes System vertrauen. Bei Hard Tecs 4U oder PC Experience z.B. haben solche Mitglieder keine Zukunft.
Man sollte sich doch diesbezüglich gegenseitig tolerieren.

mfg mani

 

[PuckPoltergeist]

Original geschrieben von xray01
Doppelte Bit-Breite
Wegen seiner 32-Bit-Architektur stößt Windows XP an seine Grenzen. Ein neuer Tempo-Schub ist erst mit 64-Bit zu erwarten.Unser Test zeigt, ob sich der Aufstieg auf Windows XP 64-Bit Edition wirklich lohnt.

Von Klaus Plessner, Oliver Ehm



Micosoft wird schon bald – zweite Jahreshälfte - eine 64-Bit-Ausgabe von Windows XP ins Rennen schicken.

Technisch gesehen klingt das Upgrade erst mal gut: Windows XP mit 64 Bit kann 4000mal so viel Arbeitsspeicher nutzen wie Windows XP mit 32 Bit, also 16 Terabyte statt vier Gigabyte. Theoretisch rechnet XP-64 auch viel schneller, da der Prozessor pro Taktzyklus doppelt so viele Daten verarbeiten kann. Es spricht vieles dafür, einen neuen PC mit 64-Bit-Prozessor auch mit dem neuen Betriebssystem auszustatten.

Doch der Leistungsschub stellt sich nur unter ganz bestimmten Voraussetzungen ein. So läuft Windows XP 64-Bit Edition eben nur auf Rechnern mit einem 64-Bit-Prozessor – auf Pentium- oder AMD-32- Plattformen verweigert das Betriebssystem den Dienst. Die volle Leistung des 64-Bit-XPs kommt außerdem nur bei mehr als vier Gigabyte RAM zum Vorschein; viele moderne PCs verkraften aber höchstens zwei Gigabyte.

So gelesen, aber auch laut Microsoft wird die volle Leistung bei 4 Gb ereicht.

Klasse, ist der Beitrag von MS selber? Damit disqualifizieren sie sich ein weiteres mal. Wenn ein OS an seine Leistungsgrenzen stößt, weil ihm nur 4GB Arbeitsspeicher zur Verfügung stehen, ist das schon äußerst bedenklich. In der Unix-Welt funktioniert das schon seit Jahrzehnten problemlos, nur bei MS kommt man mal wieder nicht klar. Wenn man dann noch bedenkt, dass ursprünglich mal 640k für alle Zeiten reichen würden, wird es endgültig lächerlich.
Wieso durch 64bit nun auf einmal doppelt so viele Daten verarbeitet werden können, ist mir auch noch schleierhaft. Wenn damit gemeint ist, dass 64bit-ints nun mit einmal bearbeitet werden können, sollen sie es auch so hinschreiben. Außerdem halte ich dann dagegen, dass das eine absolute Minderheit an Daten ist, die überhaupt so dick ist.

Vielleicht ist auch der Titel des Beitrags (Sinn oder Unsinn) nicht ganz korrekt. Sinn macht ein 64 System sicher,

Welchen? Ich schrieb von 64bit, nicht von AMD64.

die Mehrheit der "Umsteiger" wird aber vor allem erst mal bei den Privat Usern liegen.

Gerade da macht es noch am wenigsten Sinn. Wozu brauche ich zu Hause mehr als 4GB Speicher? Es macht im professionellen Umfeld Sinn, da wo der RAM benötigt wird. Ansonst ist es nur eine Vergeudung von Speicher.

Was ich in diesem Forum nicht so schön finde, ist das einige alles schlecht machen was nicht den Namen AMD oder trägt, oder auf ein anderes System vertrauen. Bei Hard Tecs 4U oder PC Experience z.B. haben solche Mitglieder keine Zukunft.
Man sollte sich doch diesbezüglich gegenseitig tolerieren.

mfg mani

Nun ja, einige hat man immer und überall. Dass es in letzter Zeit ziemlich extrem war stimmt, aber das beruhigt sich auch wieder.

 

[Bokill]

Dieser Thread war irgenwie eine klassische Wiederholung von schon längst durchdiskutiertem ...

AMD64 ist nicht nur eine 64Bit Geschichte, und wenn Programme mal mehr Speicher beanspruchen, dann ist dennoch niemand gezwungen unter AMD64 alles mit 64 Bit zu schreiben ... war aber alles schon durchdiskutiert worden.

Die Hauptpersonen in diesem Thread wussten aber dies sehr wohl, wann ist denn der nächste abgeschmackte Aufguss davon zu erwarten?

Für alle die den Murmeltiertag nochmals in alter Frische geniessen wollen ...
unter LINUX: 64 Bit überzeugt auf breiter Front - Benchmarks.

Weitere Thraedlegenden sind dort zu finden ... CPU Threadführer Kampf um die Wahrheit: "schlachten, die geschlagen werden müssen"

 

[rkinet]

Original geschrieben von PuckPoltergeist
Klasse, ist der Beitrag von MS selber? Damit disqualifizieren sie sich ein weiteres mal. Wenn ein OS an seine Leistungsgrenzen stößt, weil ihm nur 4GB Arbeitsspeicher zur Verfügung stehen, ist das schon äußerst bedenklich. In der Unix-Welt funktioniert das schon seit Jahrzehnten problemlos, nur bei MS kommt man mal wieder nicht klar.

nun, PuckPoltergeist, Microsoft hat sein 32 Bit OS für max. 2 GByte RAM ausgelegt, danach wird soweit möglich noch etwas etwas improvisiert.

Eine UNIX-Welt kennst schon seit langem 64 Bit.

Auch ist 64 Bit kein AMD-Thema mehr, sondern Intel beliefert ab Februar/März'05 den Massenwarkt mit kompatiblen 64 Bit-CPUs.
Entsprechend kann man absehen, das Microsoft in den letzten Zügen für das 64 Bit Win XP ist. Die Treiber sind ja auch schon teils in der Optimierung, siehe nvidia-Grafikdemo für 64 Bit (zieht 20-30% zusätzlich bei gleichem Takt durch)


Puck, Du solttes Deine Ideen mit Softwareentwicklern oder CPU-Designern diskutieren,
nicht hier. Nur die Erstgenannten denken an Dual-Core, Multi-Core oder eben schon das 'Cell'-Design. Und wollen nicht Software entwickeln, die im Code permanent die CPU-Generarationen abprüft, um jeweils den optimalen Code zu genieren.
x86-64 hat auch den modernsten IA32 Befehlssatz und muss keinen Kompromisse aus früheren Entwicklungsstufen mit sich schleifen. Auch ist zu erwarten, das x64-64, außer im Zusammenhang jetzt mit Dual-Core mit HT-Software und der kommenden Virtualisierung, nicht mehr signifikant erweitert werden muss.


Samsung rechnet für 2005 mit min. -30% absackenden Speicherpresien, da sind 2 GByte-RAM Wühltisch-PCs incl. Win 64 XP fast schon greifbar.

Also, vergiss die Vergangenheit - das OS 2005 wird ein 64 Bit OS sein, ebenso die Treiber.
Die Software wird im performancekritischen Bereich als 64 Bit kommen (DivX 64 oder die MS-Encoder dürften die ersten sein), der Rest ganz einfach friedlich in 32 Bit weiter laufen.


http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_11869,00.html?redir=CPOP64
AMD:
825 Programme von 250 Softwareentwicklern/ Firmen sind bereits auf 64 Bit portiert wurden. Aus allen Bereichen und sicherlich jeweils aktuelle und marktstarke Software.

 

[PuckPoltergeist]

Original geschrieben von HenryWince
> Wo genau jetzt der Speicher wirklich drauf geht, kann ich jetzt auch (noch) nicht sagen.

Ist doch offensichtlich: Im Longmode hat ein Pointer halt 64 bit (d.h. sizeof(int *) sind halt 8 byte), im 32-Bit Mode halt nur die Hälfte (sizeof(int *) sind da halt nur 4 byte).

Jepp, es sind zum einen die Zeiger, und was die nicht schaffen, erledigt das alignment ( =8 ). Insofern könnte man im long-mode eigentlich gleich durchgängig mit 64bit-Datentypen programmieren, wenn dadurch nicht auch noch der code-Bereich aufgeblasen werden würde.

Erklärt allerdings noch nicht den fünffachen Speicherverbrauch, von z.B. firefox.

 

[Dresdenboy]

Das Alignment ist bis für ein paar Befehle (z.B. MOVAPD) bei x86 und x86_64 nicht zwingend notwendig, kostet aber Leistung, falls entsprechende Boundaries überschritten werden. Das leistungssteigernde Alignment hängt dabei von der Datenwortbreite ab. Das Laden eines 32bit-Wertes von Adresse x oder x+4 (x modulo 8 = 0) im L1 oder L2 geht gleich schnell. Andere 64bit-Architekturen haben da durchaus Probleme.

 

[PuckPoltergeist]

Original geschrieben von Dresdenboy
Das Alignment ist bis für ein paar Befehle (z.B. MOVAPD) bei x86 und x86_64 nicht zwingend notwendig, kostet aber Leistung, falls entsprechende Boundaries überschritten werden.

Weshalb es wohl auch grundsätzlich verwendet wird, zumindest beim gcc, mit den standardmäßigen Optimierungsoptionen.

Das leistungssteigernde Alignment hängt dabei von der Datenwortbreite ab.

Also wenn ich das richtig verstanden habe, ist das alignment bei i386 4 und bei x86_64 grundsätzlich 8, egal welche Datentypen letztendlich verwendet werden.

PS: Nein, die Daten sind nicht grundsätzlich aligned. Wann, wieso und unter welchen Bedingungen die entsprechend ausgerichtet werden, weiß ich jetzt auch noch nicht.

 

[Dresdenboy]

Original geschrieben von PuckPoltergeist
Also wenn ich das richtig verstanden habe, ist das alignment bei i386 4 und bei x86_64 grundsätzlich 8, egal welche Datentypen letztendlich verwendet werden.

Ah, ich sehe schon - wir müssen hier genauer differenzieren. Es ist nicht so trivial. Bei x86_64 ist das optimale Alignment für 64bit-Werte 8. Für 32bit-Werte ist es 4, für 128bit-SIMD-Werte 16, für 16bit 2 usw. Das macht dann schon der Compiler bei der Optimierung. Nebenbei kann man Strukturen auch noch auf Cachelines alignen.

Das Alignment der mit malloc allokierten Speicherblöcke entspricht offenbar dem größten Datentyp (bei x86_64 dann 64bit, SSE nicht beachtet), was aber sich kaum auf den Speicherverbrauch auswirkt, da man mit malloc normalerweise größere Datenblöcke allokiert und nicht jedes einzelne 64bit- oder gar 8bit-Datenwort. Innerhalb der Datenblöcke kann dann das optimale Alignment für die einzelnen Datentypen angewendet werden.

Diese ganzen Alignment-Geschichten (bis auf die schon genannten Ausnahmen), sind nicht verpflichtend, aber einer höheren Performanz natürlich zuträglich.

 

[rkinet]

http://www.theinquirer.net/?article=20072

... But be that as it may, the fact of life is that by the end of 2005 Intel's desktop and server processors will have this technology inside. ...

(Anfang/Mitte 2006 dann den 65nm Dual-Core 'Sossaman', ebenso mit 64 Bit. )

Würde also auch einen 'Celeron 64' bedeuten, aber direkt spricht Intel dies nicht so aus. Nun, sobald Dual-Core für die höherpreisigen CPUs etabliert ist, wäre der Freischaltung von 64 Bit beim Celeron marketingtechnisch ok.
Auch könnte Intel so Q4'04 mit einer einheitlichen 64 Bit Plattform auch eine einheitliche Windows-Linie fahren. Gerade in Firmen/Office-PCs wäre eine einheitliche Linie beim OS sinnvoll, sodaß zumindest die Kunden die Wahlmöglichkeit auch beim Celeron 64 benötigen würde.

Damit hätte dann das konventionelle CPU-Design und OS-Design seinen Endpunkt erreicht.
'Longhorn' benötigt ja wahrscheinlich die 'Virtualisierung' und 'Thrusted' Fähigkeiten bei den CPU, logischerweise in 64 Bit.

----

Fazit:
Die nahe Zukunft ist 64 Bit - die Sinnfrage längst technisch beantwortet.

http://marketwatch-cnet.com.com/Int...e=pt&part=marketwatch-cnet&tag=feed&subj=news

Intel to put 64 bits in desktops in 2005
Lt. Roadmap die Pentium 4 6xx Reihe mit 2M-L2 ab 3,0 GHz / ca. $180.


Launchtermin - Gerücht Win XP pro x64: März'05 (http://www.theinquirer.net/?article=20085)

hier ohne Zeitangabe, aber über den Release-Ablauf (XP x64 und Server 2003 x64):
http://news.com.com/Microsoft+nears+release+of+64-bit+Windows/2100-1016_3-5481660.html?tag=nefd.top

----

http://cbs.marketwatch.com/news/new...057039&siteid=bigcharts&tool=1&dist=bigcharts

64 Bit als Dual-Core bis Ende 2006 = 70% des Desktop-Marktes ...

O-Ton von kommenden CEO-Otellini

tja, PuckPoltergeist,
selbst also der Celeron 64 Dual-Core hat von Intel bereits einen Zeitplan bekommen.
Da wird 2005 dann das 64 Bit Single-Core Jahr.

-----

http://cbs.marketwatch.com/news/new...083962&siteid=bigcharts&tool=1&dist=bigcharts

M.Dell said his company was "beholden to our customers" and would be competitive in delivering 64-bit computing technology.

tja, M.Dell vs. PuckPoltergeist ...

 

[rkinet]

http://www.tomshardware.de/news/20041208_105610.html

Zitat:
Intel will seine Desktop-Prozessoren schon 2005 mit 64-Bit-Funktionen ausstatten. Das erklärte der Konzern auf einer Analystenkonferenz in New York. Auch die kostengünstige Celeron-Linie soll die neuen Funktionen erhalten, hieß es weiter.

Die Intel-pdf und die Planung für EM64T: http://www.intel.com/intel/finance/presentations/PDF_Files/2004_fam.pdf


C e l e r o n 6 4 kommt ab Q1'05 - Intel offiziell

http://www.heise.de/newsticker/meldung/54021


http://futurezone.orf.at/futurezone.orf?read=detail&id=259567&tmp=57964
Nun gab Intel bekannt, ab 2005 alle seine Desktop-Prozessoren mit 64-Bit-Fähigkeiten auszustatten.


Fazit:
Celeron 64 und Sempron 64 schon 'fast' greifbar. AMD dürfte somit sein 'kein 32 Bit ab Mitte 2005' auch wie angekündigt umsetzen und Dual-Core ersetzt 64 Bit als 'Premium-Merkmal'
Wäre auch bzgl. Plattformen sinnvoll, da nicht zwei Windows-Varianten und Treiber bei den Firmenkunden gepflegt werden müssen.
Für den Anwender ergeben sich - außer dem Performancezuwachs - eh keine Veränderungen.

----
http://news.com.com/Microsoft+nears+release+of+64-bit+Windows/2100-1016_3-5481660.html

Codebasis für Win 32 und Win 64 jetzt (fast) gleich bei Microsoft. Es werden also nur zwei verschiedene Binärcodes generiert, der Source-Code beider Versionen ist gleich. Damit vereinfacht sich auch das Debugging und die Pflege von Windows.