Unterschied zwischen 32Bit und 64Bit CPUs? [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Unterschied zwischen 32Bit und 64Bit CPUs?

Paulus

2005-09-27, 18:41:42

Hi,

kann mir jemand auf verständliche weise kurz erklären wo die Unterschiede zwischen 32Bit bzw. 64Bit CPUs und deren Software liegt? Ein Link zu nem guten Artikel wäre auch schön.

Gruss,
Paulus

BlackBirdSR

2005-09-27, 18:44:40

Fruli-Tier

2005-09-27, 18:45:59

BlackBirdSR

2005-09-27, 18:48:11

Hardwareseitig besitzt eine 64Bit CPU doppelt soviele Register für die Datenhaltung, was diesen Dingern ermöglicht, deutlich mehr RAM zu addressieren. 32Bit Prozessoren hängen da glaube ich bei 4GB Obergrenze.

Das so als wichtigste Neuerung. Was genau sich noch hinter den 64Bit Implementierungen versteckt, das weiss ich allerdings nicht.

Das mit den doppelten Registern trifft aber nur für den K8 und P4 Prescott als 64Bit CPU zu.
Andere 64Bit CPUs haben keine 32Bit Versionen und daher auch nicht mehr von irgendwas.
Deutlich mehr RAM wird auch nicht durch die Anzahl der Register ansprechbar, sondern durch den größeren Adressraum.

Paulus

2005-09-27, 19:59:11

Was verstehst du unter verständlich?
Wie schätzt du dich ein?

Verständlich für jemanden der kein Informatikstudium hinter sich hat, aber doch eher den Wissensstand eines Fortgeschrittenen besitzt.

Coda

2005-09-27, 20:15:10

Fortgeschritten bei was?

Im wesentlichen haben die Dinger einfach 64bit breite Register und können damit rechnen und addressieren.

BlackBirdSR

2005-09-27, 20:25:04

Verständlich für jemanden der kein Informatikstudium hinter sich hat, aber doch eher den Wissensstand eines Fortgeschrittenen besitzt

Also auf gut Glück ;)

Im Generellen besteht der Unterschied zwischen 32Bit und 64Bit CPUs hauptsächlich in folgenden Punkten:

-32Bit CPUs können in der Regel maximal einen Adressraum von 32Bit ansprechen. Damit sind 4GB möglich. Praktisch gibt es Tricks mit denen z.B ein 36Bit Adressraum erreicht wird (PAE). Aber das ist nur ein Trick und dementsprechend nicht besonders günstig.
Der Adressraum bezeichnet die Menge an Speicheradressen, welche die CPU ansprechen kann. Bei 32Bit sind das eben 2^32 und damit 4GB
+64Bit CPUs sind in der Lage bis zu 64Bit an Speicher zu adressieren. Das steigert den möglichen Speicherausbau dann um Einiges. 4GB werden langsam knapp, besonders da nur 2-3GB in Windows32 nutzbar sind, und jedes Programm auch nur 2GB bekommen kann. Mit 64Bit CPUs kann man das umgehen. Es lassen sich auch größere Datenmengen verwalten.

-Die 32Bit CPU besitzt normalerweise ALUs, welche 32Bit Integerwerte in einem Durchgang berechnen können. Diese also nicht aufsplitten müssen. Der Inhalt eines Registers kann also ohne Zwischenschritt verarbeitet werden.
+Die 64Bit CPU besitzt normalerweise ALUs die doppelt so breit sind, und auch 64Bit Werte auf einmal annehmen. Mit 64Bit Werten rechnen lohnt sich z.B bei größeren Multiplikationen. Dort kann man mit einem 64Bit Rechenwerk ordentlich Arbeit sparen. Trotzdem macht es nicht immer Sinn alle Daten als 64Bit zu speichern, da es Platz wegnimmt und eventuell gar nicht nötig ist.
Für Spiele z.B ist das meistens nicht nötig.
Für FPU Angelegenheiten gilt das auch nicht. Die ist bei den meisten CPUs bereits in der Lage mit 64Bit oder mehr zu arbeiten.

-32Bit CPUs besitzen 32Bit breite allzweck Register. Darin lassen sich eben die 32Bit großen Daten speichern und später bearbeiten.
+64Bit CPUs müssen diese Register auf 64Bit verbreitern um die 64Bit Daten speichern zu können.
Hat ebenfalls keine Auswirkung auf die FPU

Soviel zu den generellen Unterschieden. Jetzt muss man noch zwischen 64Bit CPUs wie dem Athlon64 oder dem Itanium2 unterschieden.
Der Itanium2 ist eine 64Bit CPU ohne speziellen 32Bit Modus im Befehlssatz. D.h es gibt keine 32Bit version. Der Athlon64 hat das sehr wohl, folglich kann man beide Modi vergleichen.

Im 64Bit Modus bekommt er die oben gelisteten Vorteile. Im Speziellen kann er 40Bit an Speicher adressieren. Das reicht momentan, und ist günstiger.
Alle 32Bit Register werden auf 64Bit verbreitert. Zu den 8 nach aussen sichtbaren Allzweck-Registern, kommen nochmal 8 dazu. So dass der Compiler nun 16 davon nutzen kann. Das bedeutet weniger Cache und Speicherzugriffe und mehr Performance.
Die 8 extra SSE2 Register bekommen ebenfalls 8 Register hinzu, somit werden es 16.
Die FPU bleibt auch hier unangetastet.

Trotzdem der Athlon64 also auch als 32Bit CPU arbeiten kann, ist er eine vollwertige 64Bit CPU.

Für die Software bedeutet dies, dass sie angepasst werden muss, um davon Nutzen zu machen. Ohne ein 64Bit Betriebsystem, dass die Eigenheiten der 64Bit CPU kennt und nutzen kann, geht gar nichts.
32Bit Software läuft auf dem 64Bit Windows Betriebsystem im Falle des Athlon64 aber trotzdem. Windows64 übersetzt Aufrufe der 32bit API in ihre 64bit Äquivalente.
Von all den Vorteilen hat 32Bit Software direkt aber nichts. (indirekt schon)

64Bit Software kann die Vorteile direkt nutzen, dazu gehören mehr Speicher und eben jene 64Bit großen Datentypen, wenn man sie braucht.
Durch die 8 zusätzlichen Register bekommt man meist auch ohne einen Performanceschub.
Im Fall von Windows64 ersetzt der SSE2 Befehlssatz die FPU der CPU. Damit kann man einige unschöne Eigenheiten der FPU umgehen, und gleichzeitig statt deren 8 Register, die 16 von SSE2 nutzen.
Auf einem 32Bit Betriebsystem läuft 64Bit Software nicht.

Fällt jemandem noch was ein, oder hab ich irgendwo Mist geschr?

Paulus

2005-09-27, 20:33:43

Also auf gut Glück ;)

Denke das war ne Antwort mit der ich was anfangen kann.

Danke für die Mühe.

P.S. Gute Zitate i.d. Sig.

Coda

2005-09-27, 23:05:29

Fällt jemandem noch was ein, oder hab ich irgendwo Mist geschr?Ja, das solltest du vielleicht ändern:

Windows64 übersetzt die ankommenden Befehle und versetzt die CPU zudem in einen Kompatibilitätsmodus.Da kommt sonst noch jemand auf die Idee, dass das eine Art JITC ist, der x86 in Software in x86-64 übersetzt.
"übersetzt Aufrufe der 32bit API in ihre 64bit Äquivalente" o.ä. wäre besser.

BlackBirdSR

2005-09-28, 08:25:11

Ja, das solltest du vielleicht ändern:

Da kommt sonst noch jemand auf die Idee, dass das eine Art JITC ist, der x86 in Software in x86-64 übersetzt.
"übersetzt Aufrufe der 32bit API in ihre 64bit Äquivalente" o.ä. wäre besser.

Danke, hast recht. Das könnte so verstanden werden.

Fruli-Tier

2005-09-30, 18:43:48

Das mit den doppelten Registern trifft aber nur für den K8 und P4 Prescott als 64Bit CPU zu.
Andere 64Bit CPUs haben keine 32Bit Versionen und daher auch nicht mehr von irgendwas.
Deutlich mehr RAM wird auch nicht durch die Anzahl der Register ansprechbar, sondern durch den größeren Adressraum.

Stimmt, hab ich leicht verdreht.

Ich habe auch auf K8 und Prescott abgezielt, da ich der Annahme war, diese sind als End-User CPUs gebräuchlicher als Itanium und Co ;-)

Unfug

2005-10-01, 00:53:18

Also wenn ich jetzt nicht ganz falsch liege (bitte berichtigen falls doch), dann müsste es doch wie folgt sein:

Nehmen wir eine 4-BIT CPU:
Diese hat also 4 Bit um befehle ausführen zu können (0000, 0001, 0010, 0100, 1000, 0011..also schon eine Menge).

Eine 32-Bit CPU hat entsprechend 0000000000...(32 stellen).
Also ne ganze Menge an mehr Befehle können ausgeführt werden.
Also gehe ich theorethisch davon aus, daß die 64-BIT CPU 64 Stellen für 0 oder 1 hat.

Jetzt ist die Frage: Was bringt es?

Stell Dir einfach vor Du hättest eine Menge RAM (über 4GB). Und wir geben jedem stück ram eine Adresse.Von 0 bis ......ne enorm grosse Zahl.

So eine 32 Bit CPU kann nicht jede Adresse ansprechen , sondern nur die ,die im Bereich von 2^32 ist.

Aber ich glaube (nicht schlagen), hat die AMD64 CPU auch neue Befehle bekommen.
Das jetzt aber zu erklären (Assemblercode) wäre wohl etwas zu kompliziert

Ich bin mir nicht 100% sicher obs so stimmt, falls nicht ignoriere meinen scheiss

Coda

2005-10-01, 00:54:59

Nein. Die Befehlswörterlänge hat damit nichts zu tun. Bei x86 sind die Befehle sowieso zwischen 1 und 12 bytes lang.

Unfug

2005-10-01, 01:02:19

Nein. Die Befehlswörterlänge hat damit nichts zu tun. Bei x86 sind die Befehle sowieso zwischen 1 und 12 bytes lang.
prima, man lernt gerne dazu

Gast

2006-01-25, 22:56:11

Ich frage mich was Apple in der Zukunft gedenkt zu tun?

Die sind dabei von PPC auf Intel (Yonah) zu switchen aber auf 32Bit!?!?
Gut Yonah kann kein 64 bit (nur PAE) aber wäre es dann nicht sinnvoller gewesen, noch ein halbes Jahr auf die 64Bit CPUs von Intel zu warten?

Oder ist 32Bit mit PAE vollkommen ausreichend?

BTW:
Soweit ich mitbekommen habe, kann der G5 problemlos 32Bit und 64Bit Software (ohne Performanceverlust) nebeneinander "fahren". Bei Intel und AMD muss dafür hingegen ein "Kompatibilitätslayer" für 32Bit im 64Bit OS integriert sein, was auch etwas an Performance kostet!

ShadowXX

2006-01-25, 23:17:47

Gast

2006-01-25, 23:30:01

Yo...der Layer kostet ca. wahnsinnige 1% Leistung.

Das ist aber trotzdem alles unnötig und Hickhack gibt es womöglich auch. Es sei denn die Anwendungen (außer ganz wenige und spezielle Pro-Apps) bleiben 32Bit.

Davon abgesehen gehe ich davon aus, das auch im MacOSX sowas wie ein WoW64-Layer intergriert ist.
WoW64-Layer? Was ist das genau?

BlackBirdSR

2006-01-25, 23:33:42

Das ist aber trotzdem alles unnötig und Hickhack gibt es womöglich auch. Es sei denn die Anwendungen (außer ganz wenige und spezielle Pro-Apps) bleiben 32Bit.

Irgendwas sagt mir, dass Apple eigentlich erst mit Merom/Conroe umsteigen wollte, es aber in dieser Hinsicht einige Änderungen gab.
Testsamples von Conroe/Woodcrest gibt es Gerüchten zu folge schon seit Monaten mit 2.9GHz.
Könnte mit ein Faktor bei der Entscheidung von Apple gewesen sein.
Warum dann Core Duo? K.A

WoW64-Layer? Was ist das genau?

World of Warcraft in der 64Bit Version. Mit 2^64er Instanzen ;D

Nö das hier:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/running_32_bit_applications.asp

Gast

2006-01-25, 23:48:52

Warum dann Core Duo? K.A

Wirklich seltsam! Vielleicht wollte man nicht mehr ein halbes Jahr warten, da sonst die G4 zu sehr ins Hintertreffen geraten wären (die G5 sind ja nicht das Problemkind). Wobei es da ja Gerüchteweise einen neuen G4 gibt, der sicherlich noch gut genug gewesen wäre das halbe Jahr zu überbrücken!

Vielleicht will man damit aber auch den Entwicklern einfach Druck machen, endlich auf Universal Binaries zu setzen!

Aber trotzdem seltsam...

World of Warcraft in der 64Bit Version. Mit 2^64er Instanzen ;D

LOL

Nö das hier:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/running_32_bit_applications.asp

Ah ok der Layer!

Was für Anwendungen benötigen denn in mittlerer Zukunft wirklich 64Bit?

Aber Treiber müssen dann trotzdem für 32Bit und 64Bit geschrieben werden (und noch für PPC) -> wieder Nachteil

zeckensack

2006-01-25, 23:49:29

BTW:
Soweit ich mitbekommen habe, kann der G5 problemlos 32Bit und 64Bit Software (ohne Performanceverlust) nebeneinander "fahren". Bei Intel und AMD muss dafür hingegen ein "Kompatibilitätslayer" für 32Bit im 64Bit OS integriert sein, was auch etwas an Performance kostet!Der G5 und der K8 unterscheiden sich in diesem Punkt nicht. Auch auf dem G5 muss für 64 Bit-Prozesse ein von dir so gefürchteter "Kompatibilitätslayer" laufen.

Und das hat auch nichts mit Emulation zu tun, sondern mit 64 Bit-LIBs (.DLL auf Windows, .so auf'm Mac), die auch von 32 Bit-Applikation genutzt werden wollen. Dafür gibt's nur zwei Möglichkeiten. Entweder man übersetzt alles zweimal, knallt es doppelt auf den Rechner, und kreuzt die Finger in der Hoffnung dass schon automatisch das richtige rauskommt und es zu keinen Konflikten kommt ... oder man stellt eben auf Systemebene sicher, dass jede 64 Bit-LIB die von einem 32 Bit-Prozess geladen wird, "gelayert" wird.

Microsoft hat schon vieles sehr sehr falsch gemacht, und schießt immer noch gewaltigste Böcke, aber WOW64 ist technisch "state of the art" -- was nicht bedeutet dass es Zauberei oder besonders kompliziert wäre, sondern nur dass es eine sehr gute und elegante Lösung des Problems darstellt.

Das sollten vielleicht auch mal Mac-User zur Kenntnis nehmen. Und ebenfalls zur Kenntnis nehmen sollten Mac-User dass auf "ihren" Systemen das gleiche passiert, weil es passieren muss.
Wenn man natürlich vom eigenen Sytem weniger Details kennt als von den "bösen anderen", ist falsch verteilte Kritik vorprogrammiert.

Gast

2006-01-26, 00:03:07

Das sollten vielleicht auch mal Mac-User zur Kenntnis nehmen.
Ich bin doch garkein böser Macuser! :(

Und ebenfalls zur Kenntnis nehmen sollten Mac-User dass auf "ihren" Systemen das gleiche passiert, weil es passieren muss.
Es hätte doch nicht passieren müssen, da man doch direkt vollständig auf 64Bit hätte switchen können!

Aber danke für die Erklärung. Das Thema 32Bit Vs. 64Bit wird halt momentan viel in der Mac-Community diskutiert. z.B: hier http://www.macguardians.de/index.php?p=4085&c=1#82708

zeckensack

2006-01-26, 00:24:18

Ich bin doch garkein böser Macuser! :(Gut :)
Ich bin auch kein böser Erklärbär. Es fällt mir nur auf, dass einige (nicht alle) Mac-User sehr ... einseitige Ansichten von Rechnern haben. Belassen wir es dabei :)
Es hätte doch nicht passieren müssen, da man doch direkt vollständig auf 64Bit hätte switchen können!Das kann sich keiner leisten. Man würde mit einem Schlag die Abwärtskompatibilität zu 32 Bit-Software verlieren, und müsste von vorne anfangen, alles müsste portiert werden. Das Software-Ökosystem "Mac" wäre damit ziemlich im Arsch IMO. Für ein 64 Bit-Windows gelten natürlich die gleichen Maßstäbe.

Mit diesem "Layer" müssen erstmal "nur" alle Treiber portiert werden, und die Applikationen können schön langsam hinterherkommen. Und es wird, sei dir sicher, auch in fünf Jahren noch Mac- und Windows-Programme geben die nicht portiert wurden, also noch 32bittig sind, aber trotzdem noch nützlich genug um irgendwo eingesetzt zu werden.

Bei OSS sind solche radikalen Schritte wesentlich leichter durchzuziehen, ja. Neukompilieren, und mit etwas Glück läuft's, ohne dass man etwas ändern muss. Bei einer closed source-Applikation, wo der Erzeuger (noch) keinen Bock auf die Portierung hat, stehst du ohne "Layer" einfach ziemlich blöd da.

Gast

2006-01-26, 06:18:39

Das Software-Ökosystem "Mac" wäre damit ziemlich im Arsch IMO. Für ein 64 Bit-Windows gelten natürlich die gleichen Maßstäbe..

Wieso?

Für den Switch von PPC zu Intel muss doch eh neue Software rausgehauen werden (Universal Binary). Die hätte man dann auch gleich in 64Bit rausbringen können oder etwa nicht?

ShadowXX

2006-01-26, 07:26:20

Wieso?

Für den Switch von PPC zu Intel muss doch eh neue Software rausgehauen werden (Universal Binary). Die hätte man dann auch gleich in 64Bit rausbringen können oder etwa nicht?

Rate mal weswegen es Rosetta gibt, wenn so ein Totalswitch (egal ob jetzt beim Mac von PPC auf Intel, oder bei X86 von 32 auf 64Bit) so easy wäre und alle Programmierschmieden nur darauf warten alle Ihre Produkte auf einen Schlag zu "konvertieren"......

Demirug

2006-01-26, 07:32:06

Rate mal weswegen es Rosetta gibt, wenn so ein Totalswitch (egal ob jetzt beim Mac von PPC auf Intel, oder bei X86 von 32 auf 64Bit) so easy wäre und alle Programmierschmieden nur darauf warten alle Ihre Produkte auf einen Schlag zu "konvertieren"......

Die Sünden der Vergangenheit. Wobei ich PPC auf Intel eher mit X86 auf IA64 vergleichen würde oder für alle die sich noch erinnern X86 auf Alphas.

Bytecode ist schon was schönes stand aber "damals" natürlich nicht zur Disposition.

Gast

2006-01-26, 07:36:29

Rate mal weswegen es Rosetta gibt, wenn so ein Totalswitch (egal ob jetzt beim Mac von PPC auf Intel, oder bei X86 von 32 auf 64Bit) so easy wäre und alle Programmierschmieden nur darauf warten alle Ihre Produkte auf einen Schlag zu "konvertieren"......

Klar, Rosetta muss es so oder so gehen aber wäre es denn nicht möglich gewesen, dass der Compiler für die neue Software auf Intel (die in der Universal Binary steckt), gleich echten 64Bit Code erzeugt hätte!

Zu dem angeblichem Mischbetrieb bei PPC steht hier (in den Linkx) etwas:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3755556&postcount=233

Aber so wie ich die Erkärung von Zecki verstehe, stimmt das dann so nicht, wie dort behauptet!

ShadowXX

2006-01-26, 09:27:38

Klar, Rosetta muss es so oder so gehen aber wäre es denn nicht möglich gewesen, dass der Compiler für die neue Software auf Intel (die in der Universal Binary steckt), gleich echten 64Bit Code erzeugt hätte!

Zu dem angeblichem Mischbetrieb bei PPC steht hier (in den Linkx) etwas:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3755556&postcount=233

Aber so wie ich die Erkärung von Zecki verstehe, stimmt das dann so nicht, wie dort behauptet!

Ja....so wie das da steht ist es nonsense.

Von . ut brauchst du aber auch nichts anderes erwarten.........er hat Ahnung vom MacOSX, dann hört es aber schon auf, speziell was x86 anbelangt ist er eher nicht so bewandert (Und hat dazu eine sooooo extremes Mac-Brillenmodell auf, das man alles was er über x86 sagt nicht soooo ernst nehmen sollte).

Lebt er eigentlich noch? Oder hat Ihn der doch vollzogenen PPC->X86 switch (den er ja bis zur letzten Sekunde angezweifelt hat und immer der Meinung war, dass Jobs IBM damit nur Angst machen wollte) in Grab gebracht??

P.S.
den letzen Absatz bitte nicht zu ernst nehmen......kleine stichelleien müssen mal erlaubt sein....

Ganon

2006-01-26, 09:40:57

Und das hat auch nichts mit Emulation zu tun, sondern mit 64 Bit-LIBs (.DLL auf Windows, .so auf'm Mac)

Nope. Auf dem Mac sind's .dylib und .framework.

Ganon

2006-01-26, 10:05:33

Und da wir jetzt sowieso wieder völlig OffTopic sind:

Bei OS X gibt's soweit ich das in einem Kommentar bei Slashdot gelesen habe, ziemliche Probleme mit 64bit. Sagte ich auch schon mal hier irgendwo im Forum. Da bei Cocoa ja alles über Pointer angesprochen wird, verdoppelt sich der dafür benötigte Speicher durch 64bit und somit soll es angeblich massive Performance-Einbußen geben.

D.h. bei 64bit gibt's sowieso noch ein paar Probleme, als nur die CPU.

Keine Ahnung inwiefern das stimmt:

You're missing something massively important. The reason why we chose not to release 64-bit versions of the UI frameworks is that they run much slower than the 32-bit versions.

User interface code is really pretty messy when you get right down to it. You're doing a lot of abstraction, moving a lot of pointers and integers around. On exactly the same G5-based computer, a 64-bit UI is going to run considerably slower than a 32-bit UI because of cache exhaustion. Because you're using pointers that are twice as big as you need them to be, you can only fit half as many of them in the various caches that are there to speed up your computer's performance. That effectively cuts your caches in half.

So we had two choices: Either waste a ton of developer time releasing 64-bit-clean versions of the UI frameworks and then tell our developers not to use them, or just don't ship them at all.

http://apple.slashdot.org/article.pl?sid=05/04/12/148225&tid=179&tid=3

ShadowXX

2006-01-26, 10:12:26

Ganon

2006-01-26, 10:23:12

MS hatte diese Probleme scheinbar nicht....liegt das nur an der Art, wie das bei Apple programmiert wird?

Weiß ich nicht so genau. Mit den ganzen Adressierungssachen von Speicher etc. hab ich mich noch nicht beschäftigt. Hab ich noch vor.

Aber wenn es ein Problem mit Pointern ist, dann hat Apple auch ein Problem, da alles über Pointer angesprochen wird. Eine Klasse in Cocoa besteht nur aus Pointern (oder halt C-Datentypen). Ein Array nimmt auch keine Objekte auf, sondern nur Pointer zu diesen Objekten. Und durch die sehr hohe Abstraktion von Cocoa, gibt's halt massig Pointer.

Keine Ahnung wie das in anderen Systemen verarbeitet wird.

sloth9

2006-01-26, 17:06:32

Weiß ich nicht so genau. Mit den ganzen Adressierungssachen von Speicher etc. hab ich mich noch nicht beschäftigt. Hab ich noch vor.

Aber wenn es ein Problem mit Pointern ist, dann hat Apple auch ein Problem, da alles über Pointer angesprochen wird. Eine Klasse in Cocoa besteht nur aus Pointern (oder halt C-Datentypen). Ein Array nimmt auch keine Objekte auf, sondern nur Pointer zu diesen Objekten. Und durch die sehr hohe Abstraktion von Cocoa, gibt's halt massig Pointer.

Keine Ahnung wie das in anderen Systemen verarbeitet wird.

Was? Sowas suboptimales bei Apple? Aber der iPod ist doch so chic... :D

*SCNR*

-_-

2006-01-29, 11:27:30

Der G5 und der K8 unterscheiden sich in diesem Punkt nicht. Auch auf dem G5 muss für 64 Bit-Prozesse ein von dir so gefürchteter "Kompatibilitätslayer" laufen.

Bist du sicher?

Soweit ich weiß ist das nicht so, denn das jetzige OSX auf dem G5 ist teilweise schon 64 Bit (soweit ich weiß bis auf die GUI).

In Macforen liest man immer solche Sprüche:

"Bei PowerPC ist ein reines 64Bit System ja auch nicht nötig, da er beides parallel ausführen kann.
Die 64Bit x-86 können nur entweder oder.
Außerdem wäre eine 64Bit GUI unnötig, da eine GUI nie mehr als 4GB Ram braucht !"

"das wird wohl nicht der fall sein, das problem ist ja die AMD64/IA64/EMT64 architektur, da kann man nicht problemlos 32bit mit 64bit vermischen wie man das auf den PPC kann."

"Beim PPC stimmt das auch, bei AMD64 aber nicht. AMD64 ist nur eine 64bit-Erweiterung für einen 32bit-x86-Prozessor. Der Prozessor kann nur entweder im 32- oder im 64bit-Modus laufen, aber nicht im Mischbetrieb.

Laufen parallel ein 32- und ein 64bit-Prozess, muss die CPU ständig zwischen den beiden Modi wechseln, was natürlich Leistung kostet. Ein Athlon64 beispielsweise gibt sich in 32bit als AthlonXP aus."

Das meiste davon habe ich jetzt mal hieraus kopiert: http://www.macuser.de/forum/showthread.php?t=145447&page=2&pp=15

Hmmmmmmmm

BlackBirdSR

2006-01-29, 11:35:36

Das stimmt nicht.

im 64Bit Modus kann der K8 genau so 32Bit Code abarbeiten.
Der Wechsel in den Compatibility Modus kostet in dieser Hinsicht nichts, und die CPU kann auch 32Bit und 64Bit Code nebeneinander ausführen.
Ich weiß nicht, woher immer dieser Märchen kommen.
Der K8 ist eine vollständige 64Bit CPU, die wie der G5 auch 32Bit Code bearbeiten kann.

Im direkten 32Bit Modus gibt sich der K8 nicht als AthlonXP aus, sondern als 32Bit K8.
Dieser Modus hat aber nichts mit dem 64Bit/32Bit Mischbetrieb zu tun.

zeckensack

2006-01-29, 12:01:46

Bist du sicher?Ja.
<...>
Das meiste davon habe ich jetzt mal hieraus kopiert: http://www.macuser.de/forum/showthread.php?t=145447&page=2&pp=15

HmmmmmmmmDas ist ja nicht auszuhalten! Nichts davon stimmt!
Die Informationen liegen für jeden frei verfügbar im Internet herum :|

"1.3.2
[64 bit] mode is enabled by the system software on an individual
code-segment basis."

"2.1 Operating Modes
See “Operating Modes” on page 12 for a complete description
of the operating modes supported by the AMD64 architecture.

2.1.1 Long Mode
The AMD64 architecture introduces long mode and its two submodes:
64-bit mode and compatibility mode.
64-Bit Mode.
64-bit mode provides full support for 64-bit system
software and applications. The new features introduced in
support of 64-bit mode are summarized throughout this chapter.
To use 64-bit mode, a 64-bit operating system and tool chain are
required.
Compatibility Mode.
Compatibility mode allows 64-bit operating
systems to implement binary compatibility with existing 16-bit
and 32-bit x86 applications. It allows these applications to run,
without recompilation, under control of a 64-bit operating
system in long mode. The architectural enhancements
introduced by the AMD64 architecture that support
compatibility mode are summarized throughout this chapter."

Quelle (PDF) (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf)

Soviel zum "Mischbetrieb".

Coda

2006-01-29, 12:19:31

Ich glaub ich muss mal nen Trollaccout in dem macuser Forum aufmachen. Das ist ja kranke Scheiße da X-D

Gast

2006-01-29, 12:27:43

Ich glaub ich muss mal nen Trollaccout in dem macuser Forum aufmachen. Das ist ja kranke Scheiße da X-D

Ja mach mal! ;)

BlackBirdSR

2006-01-29, 12:28:29

Ich glaub ich muss mal nen Trollaccout in dem macuser Forum aufmachen. Das ist ja kranke Scheiße da X-D

Um ehrlich zu sein.
Ich bin in dieser Richtung schon so viel Mist gewohnt, dass ich gar nicht mehr versuche dagegen zu halten.
Lohnt sich IMO nicht, und mit dem Alter hat man auch irgendwan was besseres zu tun ;)

Gibts eigentlich Foren, wo über PPCs Mist verbreitet wird? Möchte ja auch mal die andere Seite sehen :tongue:

ste^2@nicht_angemeldet

2006-01-29, 13:00:02

Ich habe einen Account bei Macuser und habe mich auch immer über diese Aussage dort gewundert.

Ich habe in dem Thread dort mal einen Abschnitt aus der PDF, die Zeckensack verlinkt hat, gepostet!

ShadowXX

2006-01-29, 13:06:52

Um ehrlich zu sein.
Ich bin in dieser Richtung schon so viel Mist gewohnt, dass ich gar nicht mehr versuche dagegen zu halten.
Lohnt sich IMO nicht, und mit dem Alter hat man auch irgendwan was besseres zu tun ;)

Gibts eigentlich Foren, wo über PPCs Mist verbreitet wird? Möchte ja auch mal die andere Seite sehen :tongue:

Ich hatte es mal versucht (bei MacUser)...allerdings nicht als "Troll", sondern auf sachliche Art.
Kann man aber vergessen.....sobald man versucht die Falschaussagen richtigzustellen, wird man entweder völlig ignoriert oder von mindesten 20 verschieden Leuten zugetextet das man doch nur schwachsinn erzählt.

Ich habe im laufe der Jahre allerdings mitbekommen, das das ganze tatsächlich ein reines Apple-User-Problem ist....bei denen ist das was Apple sagt Gesetz, Marketing = Wahrheit und x86 (egal in welcher Ausführung) das pure Böse.
Schlimmer als bei uns das ganze mit nV vs. ATI.

P.S.
Ausnahmen bestätigen natürlich die Regel...es gibt auch durchaus Mac-User, die zugänglich sind und sich mit argumenten Überzeugen lassen.

ste^2

2006-01-29, 13:19:20

So, jetzt habe ich auch schon ein erstes Gegenposting erhalten! :D

Die müssen umschalten, das kostet Zeit.

In der Windows 64Bit Edition laufen 32Bit Anwendungen in einer Virtual Machine.

http://www.macuser.de/forum/showthread.php?p=1474338#post1474338

ShadowXX

2006-01-29, 13:21:00

So, jetzt habe ich auch schon ein erstes Gegenposting erhalten! :D
http://www.macuser.de/forum/showthread.php?p=1474338#post1474338

Versuch es gar nicht erst weiter....die glauben sowieo nur das, was Sie glauben wollen.

Ganon

2006-01-29, 13:46:53

Ausnahmen bestätigen natürlich die Regel...es gibt auch durchaus Mac-User, die zugänglich sind und sich mit argumenten Überzeugen lassen.

Hey. Vergiss nicht die MacUser die auch wissen wie es wirklich ist!!!11einself ;)

ShadowXX

2006-01-29, 14:04:14

Hey. Vergiss nicht die MacUser die auch wissen wie es wirklich ist!!!11einself ;)

Die gibts natürlich auch......auch wenn ich gehört habe, das diese nur in Reservaten (wie dem 3DC) vorkommen und ordentlich gepflegt und gehegt werden müssen ;)

ste^2

2006-01-29, 14:11:47

Naja, die Macuser die ich persönlich kenne (also nicht aus Foren) scheinen diesbezüglich alle OK zu sein.

Ich glaube die Macuser werden durch Foren teilweise zu Unrecht in ein falsches Licht gerückt. Wenn man mal genau schaut, dann sind das doch meist immer nur die gleichen Personen (mit vielen Postings), die eine gewisse "Propaganda" posten. Ein paar labern gewisse Dinge dann einfach blind nach. Aber der Masse ist das schlicht egal (nur die posten nicht soviel). Aber das ist alles IMHO!

Gast

2006-02-11, 14:00:54

Man hört, dass man im Gegensatz zu x86 bei PPC unter 64Bit keine 64 Bit Treiber benötigt.

"Wahrscheinlich brauchen wir dann auch 64 Bit Treiber (die wir bei Tiger / PPC ja nicht gebraucht haben)"

Zwar für PPC aber so könnte das ja auch für x86 aussehen:

Fat Binaries
The updated Mach-O format in Tiger supports the concept of Fat Binaries. These allow both 32-bit and 64-bit executables to be shipped as part of the same file. This means that developers and network system administrators can distribute a single version of an application to all users regardless of whether their system contains a G3, G4, or G5 processor. When the application is executed, the system automatically selects the appropriate code for the system without user intervention. Using Fat Binaries greatly simplifies distribution, installation, and administration of applications.™

http://developer.apple.com/macosx/64bit.html

http://www.apple.com/de/macosx/features/64bit/