# 32 oder 64bit

## cArN4g3

hallo,

hab jetzt leider mehrere monate linux-pause gemacht (auf grund eines süchtig machenden teufelsspiels (wow)) und beabsichtige endlich zu gentoo-linux zurückzukehren!

ich besitze hier einen amd64 und die radeon 9800er pro von ati.. 

hier meine frage:

sollte man lieber bei einem 32bit system bleiben oder empfiehlt es sich auf 64bit zu wechseln?

überwiegen die vorteile eines 64bit systems gegenüber den nachteilen des mehraufwandes 32bit-applikationen unter 64bit zu nutzen?

und was hat man als mehraufwand.?

mfg

carn

----------

## m.b.j.

Also flotter ist es mit 64 bit, Brenchmarks kannst du hier und sonstwo überall finden. Ich hab meinen Desktop komplett auf 64bit umgestellt, Probleme bereiten mir nur das Flash-Plugin (brauch ich leider da ein paar unserer Kunden Flash auf ihren von uns erstellten Hp's haben wollen).

Dies waere lösbar wenn ich mozilla-firefox-bin installiere hab allerdings keinen Bock drauf...

Ansonsten kann ich keinen Unterschied vom Administrationsaufwand zwichen meinen x86 und dem x86_64 Rechner feststellen.

----------

## SkaaliaN

ein 64bit system ist auf jeden fall schneller. viel mehr aufwand ist es eigentlich nicht. ich würde dir zu einem 64bit system raten. es ist halt nur so, dass manche progs da noch masked sind..das dürfte aber ja kein problem sein =)

----------

## caraboides

Warum sollte das Schneller sein?

Nur weil er einen grosseren Adressbus hat (bzw mehr als 4gb adressieren kann)? Es sei denn er hat z.b. 12 GB RAM dann macht das natuerlich sinn.

Ich denke mal eher das ist Jacke wie Hose.

----------

## m.b.j.

 *caraboides wrote:*   

> Warum sollte das Schneller sein?
> 
> Nur weil er einen grosseren Adressbus hat (bzw mehr als 4gb adressieren kann)? Es sei denn er hat z.b. 12 GB RAM dann macht das natuerlich sinn.
> 
> Ich denke mal eher das ist Jacke wie Hose.

 

Weil z.b. der variablentyp int unter C jetzt 64 statt 32 bits hat, das führt dazu das man nicht auf den wert long ausweichen muss um große Zahlen darzustellen... und da das Rechnen mit int's schneller geht als mit long's...

mir ist klar das das kein Perfecktes Bsp ist aber besser als nichts...

----------

## caraboides

Na ob das schneller ist, liegt auch am Compiler, das hat weinger mit 64Bit zu tun.

schon ein P1-166MMX hatte register die 128Bit Breit waren   :Smile: 

Also das ueberzeugt mich nicht.

----------

## caraboides

Sorry aber da hast du dich komplett geirrt:

int ist bei 32 und 64 bit  4Byte Gross (LP64 Size)

----------

## Dellerium

Mal na andere Frage.. ich hab neulich auf nem Server von uns den SLES als 64 Bit Version installiert ( Hab daheim Gentoo noch in 32Bit auf nem AMd64 laufen ) - weil ich einige Probleme mit dem Kernel hatte, wollte ich ihn mal fix neu kompilieren. Was Preemptive angeht hab ich dann gesehen, das davor gewarnt wird, ihn unter 64 Bit zu aktivieren - habt ihr des laufen, oder lasst ihr da lieber die Finger von?

----------

## SkaaliaN

also ich habe einen enormen geschwindigkeitszuwachs durch meinen amd64 bekommen. der compilt viel schneller als vorher. vor ein paar wochen hat er mal 605 pakete in knapp 5 std. durchgeknallt. das ist nicht übel.da kommt mein P4 nicht mit..der hat allerdings mehr GHz.

----------

## caraboides

Kann mal jemand folgenden Code auf 64Bit ausführen:

```

int main(){

int a;

long b;

printf("%d\n",sizeof(a));

printf("%d\n",sizeof(b));

}

```

einfach als test.c speichern und dann make test.

Und das ergebnis posten.   :Very Happy: 

Unter 32 Bit ist es: 4 und 4, also kann man auch schlecht auf long aus weichen @m.b.j

----------

## cArN4g3

hoi,

danke euch erstmal für die antworten, werde mir also ein 64bit system installieren.

und wenn ich mozilla-bin (oder vlt. andere binär-pakete) nutzen muss, um flash zu nutzen, np.. 

ich denke ich kann damit leben, ein oder zwei vorkompilierte pakete zu nutzen *g*

mfg

carn

----------

## SkaaliaN

also flash habe ich bisher leider noch nicht zum laufen bekommen.das will ein 32bit sys haben.da muss ich noich dran arbeiten.

----------

## m.b.j.

 *caraboides wrote:*   

> Kann mal jemand folgenden Code auf 64Bit ausführen:
> 
> ```
> 
> int main(){
> ...

 

```

mbj@mbj ~ $ nano -w test.c

mbj@mbj ~ $ gcc test.c 

mbj@mbj ~ $ ./a.out 

4

8

mbj@mbj ~ $ 

```

Muh, ich glaub da hab ich was falsch verstanden...

----------

## TheCurse

Nur mal so, es hat nichts mit der Programmiersprache und auch nicht mit der Speicherverwaltung (im Sinne von RAM) zu tun, dieses 64bit.

Ihr solltet euch vielleicht mal klarmachen, was denn die 64bit des PROZESSORS überhaupt bedeuten. Also was da jetzt überhaupt 64 anstelle von 32bit hat.

MfG

TheCurse

----------

## caraboides

Genau das hatte ich versucht klar zu machen.

Wenn ihr schreib das euer AMD64 besser ist als ein p4, hat das weniger mit 64bit zu tun.

Sondern das der einfach schneller ist in seinen Aktionen, oder mehr Datenumsetzen kann oder ne noch bessere Pipiline hat (oder mehere?)

Wie gesagt euer Auto fährt ja auch nich schneller nur weil jetzt 8 Leute anstatt 4 drinsitzen koennen.

----------

## UTgamer

Ich verzichte gerne auf Flash. Mir ist die Sicherheit vor Bufferoverflows mit dem neuen NX-Bit wichtiger als der Flash Mist.

Die Geschwindigkeit meines Dualprozessors läßt sich leider mit emerge nicht so gut mit einem Singleproz vergleichen  :Wink: 

PS für KDE-Nutzer:

Arts in 64 Bit weigert sich 32 Bitbinariesausgaben wie von Teamspeak2 oder Skype zu akzeptieren.

Daher habe ich arts deinstalliert, meine Soundkarte (Audigy 2 ZS) unterstützt HW-Mixing so das ich nicht auf das überkomplizierte dmix aus der Alsafamilie zurückgreifen muß. Das gute daran ist noch der Geschwindigkeitszuwachs für das nicht softwareemulierte Mixing.

----------

## platinumviper

 *caraboides wrote:*   

> Wie gesagt euer Auto fährt ja auch nich schneller nur weil jetzt 8 Leute anstatt 4 drinsitzen koennen.

 

Aber es bingt in der gleichen Zeit doppelt so viele Leute ans Ziel, wobei noch nicht berücksichtigt ist, dass der 4-Sitzer die Strecke drei mal fahren muss.  :Laughing: 

platinumviper

----------

## SkaaliaN

 *platinumviper wrote:*   

>  *caraboides wrote:*   Wie gesagt euer Auto fährt ja auch nich schneller nur weil jetzt 8 Leute anstatt 4 drinsitzen koennen. 
> 
> Aber es bingt in der gleichen Zeit doppelt so viele Leute ans Ziel, wobei noch nicht berücksichtigt ist, dass der 4-Sitzer die Strecke drei mal fahren muss. 
> 
> platinumviper

 

 :Laughing:   :Laughing:   :Laughing:   :Laughing:   :Twisted Evil:   da hast recht drin   :Exclamation:   :Exclamation:   :Exclamation: 

----------

## caraboides

Ok wir wäre es damit:

"Dein Auto hat jetzt 8 anstatt 4 Räder"    :Smile: 

Bessere Analogie?

CU

----------

## SkaaliaN

 *caraboides wrote:*   

> Ok wir wäre es damit:
> 
> "Dein Auto hat jetzt 8 anstatt 4 Räder"   
> 
> Bessere Analogie?
> ...

 

mh... 8 räder bringen einen schneller zum ziel, da die ps besser auf die straße gebracht werden können  und der grip besser iz  :Twisted Evil: 

----------

## UTgamer

 :Laughing:  Die Robustheit (NX-Bit) in schwierigem Gelände (Hacker) nicht vergessen. rofl.

You made my day   :Very Happy: 

----------

## platinumviper

 *caraboides wrote:*   

> Ok wir wäre es damit:
> 
> "Dein Auto hat jetzt 8 anstatt 4 Räder"   
> 
> Bessere Analogie?

 

Nö, in die Register des AMD64 passen doppelt so viele Daten (64 Bit statt 32), ausserdem hat er mehr Register.

platinumviper

----------

## TheCurse

Und was haben die 64bit jetzt mit den Registern zu tun? Ich kann auch in einen 32bit Prozessor mehr und größere Register reinpacken.

(Ist euch schonmal aufgefallen, dass die 64bit etwas mit Bussen zu tun haben?)

----------

## fly-a-lot

 *platinumviper wrote:*   

> Nö, in die Register des AMD64 passen doppelt so viele Daten (64 Bit statt 32), ausserdem hat er mehr Register.

 

Hmm, ich mag mich gar nicht in soche Meinungskriege einmischen. Ich für meinen Teil bin seit etwa einem halben Jahr mit einem AMD64 System unterwegs. Wie vorher schon angedeutet wurde, funktioniert noch nicht alles wie es sollte. Andererseits ist der Umstieg irgendwann schlicht fällig und einiges läuft eben auch schneller. In meinem Fall scheint die größere Registerzahl beim AMD64 beispielsweise Auswirkungen auf die Performance zu haben. So wie es aussieht, scheint Java davon ordentlich zu profitieren (habe sehr große Java Applikationen). Allerdings ist nun wirklich nicht alles schneller und manches hat eben auch einen größeren Speicherbedarf.

Probleme haben mir persönlich eher die nicht-open-source Pakete bereitet. Acrobat reader, Flash, etc im 64bit Firefox funktioniert noch nicht (es sei denn hat hat sich vor kurzem etwas geändert), Sun's JDK 1.5.0 macht auch nicht nur 1.5-Probleme, sondern auch AMD64-Probleme obendrauf, usw.

Aber um auf die ursprüngliche Frage zurückzukommen. Die Frage ist doch eigentlich kaum ob man umsteigt, sondern wann. Oder hat noch jemand eine 16bit Version auf seinem 32-bit Rechner laufen? Naja, das hinkt ein wenig, weil man heutzutage doch häufig mehr als nur 1 MB Haupspeicher im System hat  :Wink: . Ich persönlich denke allerdings, dass man den Schritt zu 64-bit durchaus schon tun kann. Wenn man allerdings eine möglichst ruhige Kugel schieben möchte oder ein super-komplett und mit allem Schickimicki ausgestattetes System haben möchte, dann ist es meines Erachtens durchaus vertretbar zu warten bis die 64-bit Systeme normaler Alltag sind. Leider scheint das noch nicht so ganz der Fall zu sein. Etliche Entwickler haben durchaus noch einige Probleme, ihre eigene Software in den Griff zu bekommen   :Confused: 

----------

## fly-a-lot

 *TheCurse wrote:*   

> Und was haben die 64bit jetzt mit den Registern zu tun? Ich kann auch in einen 32bit Prozessor mehr und größere Register reinpacken.
> 
> (Ist euch schonmal aufgefallen, dass die 64bit etwas mit Bussen zu tun haben?)

 

Naja, die Sache mit den Registern hängt mit der konkreten Gestaltung der im unteren Preissegment verfügbaren CPUs zu tun. Die haben im 64-bit Modus halt doppelt so viele Register.

----------

## caraboides

Wo hast du den das herr?

Die anzahl der Register hat nix mit der Performance zu tun!!!!!!!!!

Auch hat man mit 64Bit nicht mehr Register!!!!!

Das hat rein garnichts mit einander zu tun (oder hat ein AMD64 4TB Register, wenn ja kann ich ja meinen RAM und Cache ausbauen)

Die Rechner werden mit 64BIt nicht schneller!!!! die CPUs sind schneller geworden(bessere Alu, Pipiline, hoeherer Takt usw.!!

----------

## TheCurse

 *fly-a-lot wrote:*   

> Naja, die Sache mit den Registern hängt mit der konkreten Gestaltung der im unteren Preissegment verfügbaren CPUs zu tun. Die haben im 64-bit Modus halt doppelt so viele Register.

 

Deinen ersten Satz verstehe ich nicht.

Zum zweiten Satz: Die Frage ist doch (wenn überhaupt), WARUM hat er denn doppelt so viele Register (wenn es denn überhaupt so ist, was ich bezweifle), und dann kommst du vielleicht darauf, was es mit den 64bit auf sich hat.

----------

## fly-a-lot

 *caraboides wrote:*   

> Wo hast du den das herr?
> 
> Die anzahl der Register hat nix mit der Performance zu tun!!!!!!!!!
> 
> Auch hat man mit 64Bit nicht mehr Register!!!!!

 

Na, lass uns mal ganz ruhig bleiben.

Also, AMD hat bei der Kostruktion der CPU mehr Register spendiert. Sind wir da noch einig? Diese Register stehen natürlich im 32bit-Modus nicht zur Verfügung.

So, wenn man im 64-bit Modus nun schon Daten im Register hat, stehen sie zur Verarbeitung unmittelbar zur Verfügung, man muss nicht erst in den verhältnismäßig langsamen Cache oder in das noch langsamere RAM. Auch muss man den Inhalt des Registers nicht erst in den Speicher zurückschreiben usw. 

Mit anderen Worten, wenn man die Daten in den Registern der CPU hat, dann ist das die schnellste Möglichkeit überhaupt mit den Daten zu arbeiten. Volle Geschwindigkeit ohne Umwege durch irgendeinen externen Speicher.

Die Frage warum gerade Java davon profitiert, kann ich leider nicht beantworten, ich weiss es schlicht nicht. Den Gedanken, dass es wohl an der Anzahl der Register liegt, hatte ich ursprünglich (glaube ich) aus der c't, bin mir aber nicht ganz sicher. Die Beobachtung, dass 64-bit Java auf den Opterons/Athlon64 schneller ist als im 32bit Modus haben allerdings einige gemacht. Meine ersten Benchmarks damals haben ergeben, dass der Performance-Vorsprung irgendwo zwischen 30 und 45% lag (Opteron-System).

----------

## fly-a-lot

 *caraboides wrote:*   

> Auch hat man mit 64Bit nicht mehr Register!!!!!

 

Oh, wir scheinen da doch nicht gleicher Meinung zu sein.

Schnell mal was mit Google gesucht:

 *Quote:*   

> Anwendungen, die im Legacy oder Compatibility Mode laufen, stehen beim Hammer weiterhin nur die acht allgemeinen 32 Bit breiten Register EAX, EBX, ECX, EDX, EBP, ESI, EDI und ESP zur Verfügung. Arbeitet der Prozessor dagegen im 64-Bit-Mode, erweitert die AMD64-Architektur diese acht Register über den R-Präfix auf 64 Bit. Die verbreiterten Register erhalten die Bezeichnungen RAX bis RSP. Zusätzlich kann der Hammer im 64-Bit-Mode auf acht neue ebenfalls 64 Bit breite GPRs (General Purpose Register) R8 bis R15 zugreifen.[/b]

 

aus http://www.tecchannel.de/server/hardware/401971/index4.html

OK?

----------

## caraboides

 *fly-a-lot wrote:*   

>  *caraboides wrote:*   Wo hast du den das herr?
> 
> Die anzahl der Register hat nix mit der Performance zu tun!!!!!!!!!
> 
> Auch hat man mit 64Bit nicht mehr Register!!!!! 
> ...

 

Ok ich habe mich gesammelt: bin jetzt ganz ruhig.

[quote="fly-a-lot"]

Also, AMD hat bei der Kostruktion der CPU mehr Register spendiert. Sind wir da noch einig? Diese Register stehen natürlich im 32bit-Modus nicht zur Verfügung.

[/code]

Warum kommt man an die "mehr"-Register nich im 32Bit modus ran? verstehe ich nicht. Wieviel sind den Das.

Klar wenn ich mehr Register habe muss ich weniger auslagern. Ich bin jetzt davon ausgegangen, das im 64Bit und 32Bit Modus gleich viel Register vorhanden sind.

Und da ist eine Steigerung der Performance zu sehen, logisch.

Aber dann sind wir bei alten Problem, wa sist Performance?

I/O-Performance? 

MIPS? Sollte auch bei mehr Register konstant beliben.

CU

----------

## caraboides

 *fly-a-lot wrote:*   

>  *caraboides wrote:*   Auch hat man mit 64Bit nicht mehr Register!!!!! 
> 
> Oh, wir scheinen da doch nicht gleicher Meinung zu sein.
> 
> Schnell mal was mit Google gesucht:
> ...

 

Ok  :Wink: 

Würden die anderen Register auch im 32Bit-Modus zuverfügung stehen, wären sie aber gleich schnell. (Warum machen die das?)

----------

## fly-a-lot

 *TheCurse wrote:*   

>  *fly-a-lot wrote:*   Naja, die Sache mit den Registern hängt mit der konkreten Gestaltung der im unteren Preissegment verfügbaren CPUs zu tun. Die haben im 64-bit Modus halt doppelt so viele Register. 
> 
> Deinen ersten Satz verstehe ich nicht.
> 
> Zum zweiten Satz: Die Frage ist doch (wenn überhaupt), WARUM hat er denn doppelt so viele Register (wenn es denn überhaupt so ist, was ich bezweifle), und dann kommst du vielleicht darauf, was es mit den 64bit auf sich hat.

 

OK, um die Sache klarer zu formulieren.

1. Satz: AMD hat es halt so gemacht mit der doppelten Anzahl von Registern. Schön wäre die dreifache Anzahl gewesen, oder vielleicht die vierfache. Damit hatten andere ganz gute Erfahrungen im Workstation-Bereich gemacht, es ist aber kein Allheilmittel. Gegangen wäre es auch, wenn man die gleiche Anzahl von Registern genommen hätte.

2. Satz: Da verstehe ich Deine Bemerkung leider nicht wirklich. Es gibt viele Wege, eine CPU schneller zu machen, meist muss man mehreres gleichzeitig tun. Ein Weg ist es, die Antahl der verfügbaren Register zu erhöhen. Wie gesagt, alle Daten in den Registern lassen sich in voller Geschwindigkeit ohne Zugriff auf externes und langsames Cache/RAM verwenden. Das kann schon Speed bringen...

 *Quote:*   

>  und dann kommst du vielleicht darauf, was es mit den 64bit auf sich hat

 

Keine Ahnung was Du mir damit sagen willst

----------

## fly-a-lot

 *caraboides wrote:*   

> Würden die anderen Register auch im 32Bit-Modus zuverfügung stehen, wären sie aber gleich schnell. (Warum machen die das?)

 

Oje, das ist so lange her, dass ich in Assembler programmiert habe.

Ohne mir wirklich sicher zu sein:

Wenn man ein Programm für die X86-Architektur schreibt, hat man einen gewissen Aufbau der CPU vor Augen. Dazu gehören einfach bestimmte Register, die bestimmte Aufgaben erfüllen können. In einem Programm, dass auch auf einer 32-bit CPU laufen soll (wo es diese Register nicht gibt), kann man die neuen Register schlicht nicht verwenden. Die CPU kennt dann ja noch nicht einmal den zugehörigen Maschinencode. Daher sind solche Umstellungen eigentlich nur möglich, wenn man für die neue Architektur komplett neu kompiliert.

----------

## fly-a-lot

Oh, jetzt habe ich versehentlich schon gepostet. Geht aber weiter:

Vermutlich wolte man nicht, dass sich noch zwei Subkulturen von kommerzieller Software entwickeln. Einmal für 32-bit CPUs und einmal für 64-bit CPUs im 32-bit Modus. Weshalb auch, die Tage der 32-bit CPUs sind gezählt. Es ist doch nur eine Frage der Zeit, bis praktisch alle Systeme 4+ GB RAM haben werden. Microsoft wird das RAM sicher zu nutzen (oder verschwenden) wissen. Da bin ich ganz zuversichtlich   :Wink: 

----------

## caraboides

Klar,

die wollen das ich ne neue CPU kaufe  die 64Bit hat und die  schneller ist, das die shenller ist hat zwar nix mit 64Bit zu tun. Aber Normalos ist es halt leichter zu verklickern: 64Bit = schneller.

Tja die Welt ist schlecht. *biermachauf*

Ich bleibe lieber bei meinem SPARC    :Laughing: 

Aproppos: Was ich von Vista gesehen habe, zeigt das die mit der Performance schon umzugehen wissen. Und 2 3DKarten sind dann auch Pflicht: eine fuers OS und eine zum Spielen (Und dann sind wir ja auch bei DUALCORE: eine fuers OS eine Zum Spielen)

Dann kaufe ich mir wieder NES mit dem konnte ich auch schon spielen  :Wink: 

----------

## SkaaliaN

 *caraboides wrote:*   

> Klar,
> 
> die wollen das ich ne neue CPU kaufe  die 64Bit hat und die  schneller ist, das die shenller ist hat zwar nix mit 64Bit zu tun. Aber Normalos ist es halt leichter zu verklickern: 64Bit = schneller.
> 
> Tja die Welt ist schlecht. *biermachauf*
> ...

 

Von Vista halte ich eh nichts. Das ist meines Erachtens nach eh schrott wofür man Geld bezahlen soll.  :Razz: 

----------

## fly-a-lot

Jaja, ich musste auch gerade schmunzeln als ich mich an den Kauf meines ersten 486er erinnerte. Sehr schnell damals, mit sage und schreibe 25MHz  :Smile: 

Aber der Punkt war, dass ich damals echt Klinken putzen musste um ein System zu ergattern, dass bis auf 16MB RAM aufgerüstet werden konnte (4MB Standard damals). Die haben mich alle für bescheuert gehalten weil man ja doch NIEMALS soooo viel RAM brauchen werde. Naja, das hatte natürlich mit der begrenzten Vorstellungskraft der sogenannten Experten zu tun. Wer denkt denn auch, dass es jemals etwas anderes als 16bit DOS Programme geben könnte, oder?

Persönlich sehe ich allerdings jetzt eine vergleichbare Lage, wenn auch nicht so dringlich und zwingend wie damals. 32bit Systeme werden meines Erachtens über kurz oder lang zum alten Eisen gehören. Allerdings wohl eher wegen des größeren Adressraums. Ein 32-bit System würde ich mir aus dem Grund heute nicht mehr zulegen (es sei denn natürlich, man braucht es aus speziellen Gründen). Irgendwann wird es für Windows auch nur noch 64-bit Programme geben und man ist mit seinem 32-bit Windows-Rechner eher angeschmiert als man möchte. Naja, und das wird dann wohl Auswirkungen auf den gesamten PC-Markt nach sich ziehen. Vielleicht so etwas wie den Acrobat-Reader nur noch in 64-bit und nicht mehr in 32-bit usw.

----------

## TheCurse

Um es nochmal klar und verständlich auszudrücken:

Es ist völlig klar, dass ein Prozessor mit mehr Registern in gewisser hinsicht schneller ist

Das hat aber rein gar nichts mit 64bit-Technologie zu tun!!!

Also wenn man von 64bit spricht, und irgendwelche Geschwindigkeitsvorteile daran sieht, dass er mehr Register hat (man kann auch einem 32bit-Prozessor mehr Register einbauen!!!), ist blödsinn!!!

Der (bzw. die) interne Bus ist einfach breiter, woraus eine schnellere (bzw. breitere, d.h. mehr gleichzeitig, an der eigentlichen Geschwindigkeit ändert sich ja nix) Datenübertragung möglich ist. Deshalb machen mehr Register Sinn, was aber nur eine logische Konsequenz des ganzen ist. 

Hoffe, dass mich diesmal irgendwer verstanden hat.

----------

## UncleOwen

 *TheCurse wrote:*   

> Das hat aber rein gar nichts mit 64bit-Technologie zu tun!!!

 

Ich glaub, das hat inzwischen jeder verstanden. Nur geht's hier nicht um 64bit im Allgemeinen, sondern eben um x86 vs. amd64 - und der HAT nunmal mehr Register. Nichts anderes wurde gesagt.

----------

## caraboides

@TheCurse

Der AdressBus ist breiter! nich der DatenBus. Ich glaube da gab es auch schon 128Bit Datenbus um z.B. mehre Wörter gleichzeitig zu uebertragen. PCI gibt es z.B. mit 64Bit breitem Datenbus in einem 32bit System.

----------

## fly-a-lot

 *UncleOwen wrote:*   

> Ich glaub, das hat inzwischen jeder verstanden. Nur geht's hier nicht um 64bit im Allgemeinen, sondern eben um x86 vs. amd64 - und der HAT nunmal mehr Register. Nichts anderes wurde gesagt.

 

Tja, ich denke ehrlich gesagt auch, dass der Vergleich real existierender Systeme nahe liegt. Mit dem Übergang zu den 64-bit Systemen ist halt auch eine neue CPU-Generation verbunden, insbesondere bei AMD. Sicher verbinden die meisten mit dem 64-bit Label unwillkürlich auch den technischen Fortschritt, der mit dem nun 64-bittigen Adress- und Datenbus eigentlich nicht so viel zu tun hat. Aber eine Diskussion, die so etwas künstlich aufzudröseln versucht, ist doch irgendwie von rein akademischem Interesse. Bei der Gelegenheit müsste man in der Tat Vor- und Nachteile abwägen und auch berücksichtigen, dass 64-bit Systeme eben auch Nachteile mit sich bringen, so beispielsweise der größere Speicher(=RAM)-bedarf.

Es ist es aber halt so, dass reale 64-bitter heute schneller sind als die 32-bitter. Auch wenn ich zugebe, dass man bei den derzeitigen Intel CPUs Abstriche machen muss. Und das hat dann weniger mit 64-bit zu tun, als mit der Tatsache, dass das CPU-Design bei Intel zur Zeit nicht wirklich state of the art ist. Aber ich denke, dass man die Augen nicht davor verschliessen kann, dass die kommenden CPU-Generationen wohl 64-bittig sein werden. Und in diese Generationen gehen dann auch andere technische Fortschritte ein. Naja, und irgendwann kommt dann wohl auch Intel wieder mit einem guten CPU-Design, denke ich.

----------

## fly-a-lot

 *caraboides wrote:*   

> Der AdressBus ist breiter! nich der DatenBus. Ich glaube da gab es auch schon 128Bit Datenbus um z.B. mehre Wörter gleichzeitig zu uebertragen.

 

Vorsicht, Du musst ganz verschiedene Datenbusse unterscheiden. Die CPU internen Datenbusse, mit der u.a. die Register verbunden sind, haben sich in der Tat verändert. Davon zu unterscheiden ist die Verbindung von CPU und RAM, die funktioniert ganz anders. Und je weiter man in Richtung Peripherie geht, stösst man auf immer andere Busse. Das aber ist unabhängig vom Wechsel auf 64-bit Adressierung im RAM.

----------

## Hungry Hugo

 *fly-a-lot wrote:*   

> [...]Und in diese Generationen gehen dann auch andere technische Fortschritte ein. Naja, und irgendwann kommt dann wohl auch Intel wieder mit einem guten CPU-Design, denke ich.

 

full ack!!!

Das ganze wird auch nicht mehr lange auf sich warten lassen  :Cool: . Intel hat nach meinen Informationen Anfang letzten Jahres ein "extra"

Team abgestellt um eine 64-Bit CPU für den Desktop-Bereich zu entwickeln. Ich bin davon überzeugt das dann auch Intel wieder die "Oberhand" auf dem Desktop-Markt gewinnt. Vielleicht nicht lange da AMD ja auch nicht schläft aber die Zeit wird zeigen wer innovativer

ist und ich denke da hat Intel eine sehr sehr gute Change.

Ich bin übrigens eingefleischter Intel-Fan und selbst wenn eine AMD CPU "schneller" ist würde ich immer ohne Ausnahme Intel einsetzen.

Allein die Revolution der HT Technick in 2004 und nun die Dual-Core Technik im Verbund mit HT lassen auf eine aufregende Zukunft hoffen.

Gruß Hungry Hugo

----------

## flo_gentoo

 *Quote:*   

> Ich bin übrigens eingefleischter Intel-Fan und selbst wenn eine AMD CPU "schneller" ist würde ich immer ohne Ausnahme Intel einsetzen.
> 
> Allein die Revolution der HT Technick in 2004 und nun die Dual-Core Technik im Verbund mit HT lassen auf eine aufregende Zukunft hoffen.

 

Das kann man sehen wie man will, aber einen vorteil hat es auf jeden fall: Konkurenz belebt das Geschäft

----------

## hoschi

 *UTgamer wrote:*   

> Mir ist die Sicherheit vor Bufferoverflows mit dem neuen NX-Bit wichtiger als der Flash Mist.

 

Ohh, mit solchen Vermutungen wäre ich vorsichtig. Oder einfach gesagt, das stimmt inzwischen nicht mehr, kann man umgehen.

Liege ich richtig, dass der BUS der Prozessors bei EMT64 und AMD64 auf 64 Bit breite Gewachsen ist, also höherer Datendurchsatz?

Die Register sind doch schon seit langem größer?

64Bit ist für Sparc usw. sowieso ein alter Hut

----------

## Genone

 *Hungry Hugo wrote:*   

>  *fly-a-lot wrote:*   [...]Und in diese Generationen gehen dann auch andere technische Fortschritte ein. Naja, und irgendwann kommt dann wohl auch Intel wieder mit einem guten CPU-Design, denke ich. 
> 
> Das ganze wird auch nicht mehr lange auf sich warten lassen . Intel hat nach meinen Informationen Anfang letzten Jahres ein "extra"
> 
> Team abgestellt um eine 64-Bit CPU für den Desktop-Bereich zu entwickeln. Ich bin davon überzeugt das dann auch Intel wieder die "Oberhand" auf dem Desktop-Markt gewinnt. Vielleicht nicht lange da AMD ja auch nicht schläft aber die Zeit wird zeigen wer innovativer
> ...

 

Also diesen marketingorientierten Netburst Quatsch mit abgekupferter IBM Technik als Revolution zu bezeichnen, naja ...

Hoffe mal das Intel aus diesem Bockmist was gelernt hat und endlich nen würdigen P3 Nachfolger bringt (der P-M hats ja leider noch nicht ins Desktop Segment geschafft  :Sad:  ).

----------

## platinumviper

Hier wird einiges durcheinander geworfen, daran ist zum Teil auch Intels Marketingabteilung schuld, die das Geschäft mit den wesentlich teureren Itanium 2 Prozessoren schützen will. Die Bezeichnung EM64T (Extended Memory 64 Technology) soll den Eindruck erwecken, dass es um den adressierbaren Speicher geht, das ist aber nicht der Fall. Eine Speicheradresse kann bei AMD64 48 Bit breit sein, also 256 TB adressieren, physikalisch sind nur 40 Pins vorhanden, also maximal ein TB. Kurioserweise können ausgerechnet Intels EM64T Prozessoren nur die unteren 4 GB per DMA (Direct Memory Access) ansprechen, Zugriffe auf höhere Speicherbereiche sind langsam, AMD64 Prozessoren greifen auf den gesamten Speicher per DMA zu.

Von einem 64-Bit Prozessor spricht man, wenn der Prozessor 64-Bit Daten verarbeiten kann, wie die Daten zum Prozessor gelangen und wie groß der Adressraum ist spielt dabei keine Rolle. Zur Geschwindigkeit nur ein keines Beispiel, eine Addition von zwei 64-Bit Zahlen läuft etwas vereinfacht folgendermassen ab:

64-Bit CPU:

1. Zahl x wird aus dem Speicher in Register RAX geladen

2. Zahl y wird aus dem Speicher in Register RBX geladen

3. Register RBX wird zu Register RAX addiert

4. das Ergebnis (Register RAX) wird in den Speicher übertragen

32-Bit CPU:

1. die oberen 32 Bit von x werden in Register EAX geladen

2. die unteren 32 Bit von x werden in Register EBX geladen

3. die oberen 32 Bit von y werden in Register ECX geladen

4. die unteren 32 Bit von y werden in Register EDX geladen

5. EDX wird zu EBX addiert und ein Überlauf-Bit  im Flag-Register auf 0 oder 1 gesetzt (das Ergebnis kann 33 Bit lang sein)

6. ECX und das Überlauf-Bit werden zu EAX addiert

7. EAX wird in den Speicher übertragen

8. EBX wird in den Speicher übertragen

Es sind bei der 32-Bit CPU also zwei Rechen- und sechs Speicher-Operationen notwendig, bei der 64-Bit CPU aber nur eine Rechen- und 3 Speicher-Operationen.

Zur Zahl der Register: die 32-Bitter von Intel und AMD haben zwar acht Register, benutzbar sind aber nur vier (im Instruction Pointer z.B. kann mann nun mal keine Daten lagern), die entsprechenden 64-Bitter haben 16 Register von denen zwölf uneingeschränkt benutzbar sind.

Ob 64 Bit etwas bringen hängt natürlich auch davon ab, wie das Programm geschrieben wurde und was der Optimizer des Compilers daraus macht. Da der Bedarf auch durch das Angebot an preiswerten 64-Bit CPUs entsteht, würde ich heute niemandem mehr den Kauf eines 32-Bitters empfehlen.

Revolutionär ist die 64-Bit-Technologie übrigens nicht, es gibt sie schon seit fast 30 Jahren, neu ist nur, dass 64-Bitter dank AMD für Privatleute erschwinglich geworden sind. Performance bringt aber nur eine gezielte Optimierung des Programmcodes, Mitte der 80er beherrschten zwei Firmen mit völlig unterschiedlichen Konzepten den Supercomputing Markt, Cray mit anfangs einem, später wenigen superschnellen 64-Bit Prozessoren und Thinking Machines Corporation mit massiv-parallelen Rechnern mit 1-Bit CPUs, das kleinste "Einsteiger" Modell hatte 16384 CPUs. Auf beiden Systemreihen liessen sich im Prinzip die selben Probleme lösen, aber man musste den Programmcode eben auf Vektorisierbarkeit oder auf Parallelisierbarkeit optimieren, heute nimmt einem der Optimizer des Compilers die meiste Arbeit ab und optimiert auch Programme die für 32-Bit Prozessoren geschrieben wurden auf 64-Bit Prozessoren.

platinumviper

----------

## fly-a-lot

@platinumviper

Wunderbarer Beitrag, ich habe ihn sehr genossen!

 *platinumviper wrote:*   

> Mitte der 80er beherrschten zwei Firmen mit völlig unterschiedlichen Konzepten den Supercomputing Markt, Cray mit anfangs einem, später wenigen superschnellen 64-Bit Prozessoren und Thinking Machines Corporation mit massiv-parallelen Rechnern mit 1-Bit CPUs, das kleinste "Einsteiger" Modell hatte 16384 CPUs. Auf beiden Systemreihen liessen sich im Prinzip die selben Probleme lösen, aber man musste den Programmcode eben auf Vektorisierbarkeit oder auf Parallelisierbarkeit optimieren, heute nimmt einem der Optimizer des Compilers die meiste Arbeit ab und optimiert auch Programme die für 32-Bit Prozessoren geschrieben wurden auf 64-Bit Prozessoren.

 

Sag mal, warst Du damals schon mit dabei? Du klingst mir nicht gerade nach Halbwissen. 

Allerdings würde ich gerne off-topic darauf hinweisen, dass die Anpassung von Software auf massiv parallele Systeme alles andere als trivial war. Zumindest aus meiner Erfahrung heraus war die Vektorisierung damals viel einfacher (ausgehend von damals üblichen Fortran-Programmen) als der Umgang mit den massiv parallelen Systemen. Ich zumindest bin damals nicht wirklich in der Lage gewesen, "meine" Probleme in die massiv parallele Welt vernünftig zu übersetzen. Wie gesagt, die SIMD bei Cray und auch bei den IBM 3090 Vektorprozessoren waren mir da schon näher und irgendwie auch einfacher zu handhaben. Leider hat es wohl zu wenige fine grain parallelism Probleme gegeben, um die massiv parallelen Systeme zum Erfolg zu führen. Heute baut ja scheinbar doch alles irgendwie auf course grain parallelism auf. Das reduziert natürlich auch den Kommunikationsaufwand ganz erheblich...

Sag mal, war die Mindestausstattung des CM-1 damals wirklich 16k CPUs? Ich dachte, dass ich meine mehr oder weniger erfolglosen Tests immer auf 64k Knoten laufen hatte. Aber 16k macht bei Hypercubes letzlich auch irgendwie Sinn.

----------

## fly-a-lot

 *platinumviper wrote:*   

> 64-Bit CPU:
> 
> 1. Zahl x wird aus dem Speicher in Register RAX geladen
> 
> 2. Zahl y wird aus dem Speicher in Register RBX geladen
> ...

 

wieder on topic:

platinumviper weist zu Recht darauf hin, dass es sehr darauf ankommt, was der Optimierer aus dem Programm macht!

In der realen Welt zur Zeit existierender Compiler und Programme bleibt von den Vorteilen der schnelleren Integer-Arithmetik (siehe platinumviper's Ausführungen) und der größeren Anzahl von Registern anscheinend nicht viel übrig. 

1. Integer-Arithmetik

Die schnelle Integer-Arithmetik ist eine der wenigen 64-bit bedingten Fortschritte. Man sollte deren Bedeutung in den realen Programmen aber weder unter- noch überschätzen. Einen ordentlichen Leistungsschub gibt es natürlich nur bei Programmen, die einerseits heftigen Gebrauch davon machen und andererseits zuvor mit long Variablen gearbeitet haben und nun auf int wechseln können. Und genau über letzeren Punkt komme ich manchmal ins Grübeln. Wie groß ist eigentlich die Anzahl der Programmierer, die ihre Programme tatsächlich dahingehend checken, ob man aus einem long nun ein int machen kann? Ich habe das Gefühl, dass es an der Front nicht wirklich gut aussieht. Möglicherweise muss da noch sehr viel mehr Zeit vergehen (d.h. 64bit zur Normalität werden), bis sich wieder richtige Vorteile ergeben. 

Wer früher schon Programme geschrieben hat, die auf unterschiedlichen Rechnertypen laufen sollten, kennt vielleicht auch noch das Dilemma. Nehme ich jetzt int oder long (bei mir war es meist die Frage ob double, aber egal)? Wenn ich auf dem System soundso bin, dann ist long aber nur 64 Bit, beim System soundso sind es 128 Bit. Vielleicht sollte ich doch sicher gehen und lieber ein long nehmen, sonst gibt es irgendwann einmal Probleme wenn keiner mehr daran denkt...

Leider haben es sich die Compiler-Jungs in den frühen Jahren mit solchen Konstrukten wie int und long recht bequem gemacht. Wirklich hilfreich wäre es beim Umgang mit verschiedenen Prozessortypen gewesen, wenn man Datentypen wir int32, int64, int128 (gemeint ist: mindestens 32bit, 64bit, usw) zur Verfügung hätten. Dann könnte der Compiler in Abhängigkeit vom Zielsystem den am besten geeigneten Datentyp auswählen. Will meinen: aus int32 mache 32bit Integer auf 32bit-Systemen und ein 64bit Integer auf 64bit-Rechnern, aus int64 mache Datentyp long auf 32bit-Systemen, normales int mit 64 Bit auf 64bit-Systemen, usw). Aber der Zug ist wohl leider schon lange abgefahren. Dadurch, dass zumindest in der C/C++/usw-Welt von einigen mit großem Vergnügen lustig zwischen int, char und irgendwelchen Pointern usw hin- und hergefummelt wird, geht das natürlich nicht. Und so fürchte ich, dass zwar sehr viele Programme von der 64bit Integer-Arithmetik profitieren könnten, jetzt aber sozusagen automatisch auf 128bit umgestellt werden, d.h. long bleibt einfach long und geht damit von 64bit auf 128bit, egal ob das wirklich erforderlich ist. Schade drum...

2. die größere Anzahl Register

Ich hatte zuvor schon darauf hingewiesen, das eine größere Anzahl von Registern Geschwindigkeitsvorteile bringen kann, da auf die Daten unmittelbar zugegriffen werden kann. Allerdings muss man eine Kleinigkeit im Hinterkopf behalten. Sobald man ein Unterprogramm anspringt, sichern "normale" Compiler (d.h. bei Verwendung üblicher Optimierungenslevel) sämtliche Register in einen Stack (im RAM) und holen sie wieder zurück, sobald der Rücksprung aus dem Unterprogramm erfolgt. Dabei wird normalerweise nicht darauf geachtet, welche Register in den Unterprogrammen überhaupt gebraucht werden. Es werden also sämtliche Register gespeichert, was zu einigem Overhead führt. Bei heutiger Programmierweise verwendet man ungeheuer viele Unterprogramme, in denen recht häufig sehr, sehr wenig passiert. Ohne das für und wider diskutieren zu wollen wird aber ersichtlich, dass die Compiler sehr stark in Richtung inline optimieren müssen (d.h. den Code des Unterprogramms an der Stelle integrieren, an der eigentlich das Unterprogramm aufgerufen wird), um Prozessoren mit vielen Registern gut in Szene zu setzen. 

Aber auch was diesen Punkt anbelangt, sehe ich bislang noch keine wirklich großen Fortschritte. In vielen Fällen werden Programme gar nicht so compiliert, dass die AMD64-Architektur mit den vielen Registern zu voller Form auflaufen könnte. Man beachte das folgende beliebig gewählte Beispiel aus einer Dokumentation betreffend GCC:

 *Quote:*   

> Beachten Sie aber, daß jede Optimierung größer als O2 riskant ist, da der Compiler eventuell Funktionen als inline behandeln könnte, die nicht im Quellcode als inline deklariert sind.

 

Und jetzt Hand aufs Herz. Mit welchen Compileroptionen compilieren wir unser Gentoo-System? Die meisten stolzen Athlon64 Besitzer wohl mit -O2, oder?

----------

## RealGeizt

 *fly-a-lot wrote:*   

>  *platinumviper wrote:*    
> 
> Und jetzt Hand aufs Herz. Mit welchen Compileroptionen compilieren wir unser Gentoo-System? Die meisten stolzen Athlon64 Besitzer wohl mit -O2, oder?

 

CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -fomit-frame-pointer -pipe"

ich will nur anmerken, dass ich persönlich ein geschwindigkeitsvorteil beim kompilieren merke. hatte erst ein 32 bit system und darauf ein frisches 64er.

----------

## fly-a-lot

 *RealGeizt wrote:*   

> 
> 
> CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -fomit-frame-pointer -pipe"

 

Moment mal, das macht ja einen besseren Eindruck als meine eigenen Einstellungen. Ich glaube, ich sollte die Gelegenheit nutzen und mir doch noch mal meine Compileroptionen ansehen ...    :Shocked: 

Ich nehme mal an, dass Du auch beim Compilieren des Kernels nie auf Probleme gestossen bist, oder?

Diskussion zu den AMD64 Compileroptionen übrigens in https://forums.gentoo.org/viewtopic-t-257417-highlight-amd64+cflags.html

----------

## RealGeizt

 *fly-a-lot wrote:*   

>  *RealGeizt wrote:*   
> 
> CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -fomit-frame-pointer -pipe" 
> 
> Moment mal, das macht ja einen besseren Eindruck als meine eigenen Einstellungen. Ich glaube, ich sollte die Gelegenheit nutzen und mir doch noch mal meine Compileroptionen ansehen ...   
> ...

 

nö, hatte damit bis jetzt keine probleme...ich meine, es sind ja die von amd empfohlenen flags  :Smile: 

----------

## fly-a-lot

Hmm, looks like I missed -ffast-math and -funit-at-a-time, but -funit-at-a-time is already enabled with -O3. Everything else seems to be the same on my system.

If I'm not mistaken there was an issue with --ffast-math, but I have to think about it and eventually check again.

----------

## UTgamer

 *hoschi wrote:*   

>  *UTgamer wrote:*   Mir ist die Sicherheit vor Bufferoverflows mit dem neuen NX-Bit wichtiger als der Flash Mist. 
> 
> Ohh, mit solchen Vermutungen wäre ich vorsichtig. Oder einfach gesagt, das stimmt inzwischen nicht mehr, kann man umgehen.

 

Doch dies stimmt noch, die Hürde es zu umgehen ist sehr sehr hoch, nun es bedeuted nicht das es nicht geht. Ich denke du spielst auf den Heise Beitrag >> Verwundbar trotz No Execute << an.

Dann lies auch bitte die Kommentare wie diesen dort: 

DAS ist das Problem sowie diese Antwort.

Soweit wie ich das verstanden habe müssen Library Funktionen angesprungen werden, die bei den meisten Maschinen an der selben Adresse im Speicher liegen.

Also da bei fast alle Distributionen von der Stange die Libraryversionen und Kompileroptionen bekannt sind, sind diese besonders von der Lücke betroffen.

Nun kommt jedoch Gentoo ins Spiel, hier weiß der Angreifer nicht welche gewünschte Libraryversion ich gerade nutze, mit welchen Kompilerversionen ich sie erstellt habe und mit welchen Kompileroptionen. 

Welche Adresse muß er nun anspringen?

Doch, mit Gentoo und NX-Bit fühle ich mich recht sicher, viel mehr als ohne. Zudem ja auch die klassischen 32Bit Bufferoverflows Geschichte sind.   :Smile: 

----------

