64 Bit Prozessoren - Wurden eure Erwartungen erfüllt?

[Dr. Chandra]

Hallo an alle Technikbegeisterten!

Ich möchte einen Thread starten, bei dem ich gerne eure Meinung zu der "neuen" 64-Bit Prozessorengeneration hören würde. Ich habe überlegt, ob ich diesen Thread hier oder in einem anderen Unterforum starten soll. Im Prinzip könnte man ihn fast in jedem Unterforum rechtfertigen, da die CPU der Kern des Computers ist und alle Bereiche (Mainboards/AMD/Intel/Windows/Spiele/Anwendungen/etc..) betrifft.
Es geht mir aber hier in erster Linie um die subjektiven Erfahrungen, die mit der 64-Bit Technik gemacht wurden, und vor allem auch um die Frage, ob eure Erwartungen an die neue Technik erfüllt wurden.

Am 22.09.2003 war der Release des Athlon 64 3100+, des ersten Athlon 64 für Desktopsysteme. In gut zwei Wochen wird die Technik damit 3 Jahre alt. Im PC-Bereich ist dies eigentlich schon ein beträchtliches Alter. Nach 3 Jahren erstaunt es daher doch umso mehr, daß immernoch ein großer Teil der User mit 32-Bit CPUs oder 32-Bit Betriebssystemen unterwegs ist. - Ist das 64 Bit-Konzept an Microsoft gescheitert?
Selbst heute sind echte 64-Bit Systeme (CPU+Betriebssystem) eher selten. Die 64-Bit Edition von Windows XP fristet ein trauriges Schattendasein, da alle Welt (wohl zurecht) bereits mit dem sofortigen Entwicklungsstop für diese Plattform rechnet, sobald Windows Vista irgendwann nächstes Jahr erscheint.
Entsprechende Anwendungen oder gar Spiele für 64-Bit Prozessoren sucht man mit der Lupe. Und wenn man mal eines findet, wie beispielsweise Farcry, erscheint es einem bei näherer Betrachtung doch mehr als fraglich, ob hier wirklich 64-Bit Kerne voll genutzt werden.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2411

Welche Erfahrungen habt ihr mit euren 64-Bit CPUs gemacht? Habt ihr ein 64-Bit Betriebssystem oder eine Anwendung, die diese Technik nutzt? Oder habt ihr zu einer 64-Bit CPU gegriffen, weil ihr -wie ich- für die Zukunft gerüstet sein wolltet?

Interessant finde ich in diesem Zusammenhang auch die Diskussion über die Mehrkerntechnik. Obwohl in den wenigsten PCs die 64-Bit Technik tatsächlich bereits zum Einsatz kommt, werben die Hersteller bereits für ihre DualCore-Produkte. Eine Technik, die erst recht nicht mehr von aktuellen Betriebssystemen unterstützt wird. Von Hand kann man heute "mühevoll" einzelne Prozesse auf die unterschiedlichen Cores aufteilen. Aber haben wir uns das wirklich so vorgestellt?
Hat die Chipindustrie nicht eher die Erwartungen geweckt, daß eine mäßig schnelle Anwendung nun durch doppelte Prozessorleistung beschleuningt wird?

Vielleicht sehe ich das falsch, aber wie zB. soll ein komplexer und damit langsamer Prozeß von 2 Cores gleichzeitig bearbeitet werden, wenn sogar der interne Cache nicht gemeinsam genutzt werden kann? Weiß die linke Hand überhaupt, was die rechte tut? Und was ich eher als Manko werte, wird dann von den Hersteller noch als Feature a la 'jeder Kern verfügt über seinen eigenen Cache' verkauft.

Aber das soll jetzt nicht vom Thema ablenken. Könnt ihr mir vielleicht einen Benchmark oder ein sonstiges herstellerunabhängiges Utility empfehlen, mit dem ich unter Windows32 wenigstens feststellen kann, ob meine 64-Bit CPU überhaupt funktioniert?

Schonmal Danke im voraus.

[Spasstiger]

Die meisten, die einen 64-Bit-Prozessor gekauft haben, haben ihn deshalb gekauft, weil er die beste Leistung fürs Geld geboten hat und das auch unter 32 Bit (siehe Athlon 64, Pentium D).

Am Notebookmarkt und dem guten Absatz des Pentium M und des Core Duo sieht man ja, dass 64 Bit nicht wirklich ein Kaufargument ist (der Turion ist bei gleichem Takt langsamer und braucht etwas mehr Strom).

[Blutmaul]

64 Bit war kein Grund, eine neue CPU zu kaufen.
Allerdings kommt mir ein neues OS nur ins Haus, wenn es jetzt endlich mit 64 Bit losgeht und dies Verbesserungen mit sich bringt.
Sonst bleib ich eben bei Win XP 32-Bit.

[Gast]

dual-core-prozessoren werden schon wesentlich länger als 64bit unterstützt.

[schmacko]

ich habe mir einen athlon64 gekauft, weil es zu der zeit das beste preis-leistungs-angebot war. dass ein 64bit-prozessor für winxp keine vorteile bringt, war mir da schon klar. weiters war mir klar, dass selbst ein 64bit betriebssystem für meine 1gb speicher nicht grad die offenbarung sein werden.

insgesamt aber ist die entwicklung aber nur zu begrüßen, denn die 32bit grenze ist bald eine fiese hürde bei der rasanten weiterentwicklung der speichermengen. da ist es doch schön, dass für die betriebssystementwickler das vorhandensein von einer fast 100%-basis von 64bit-fähigen neusystemen auszugehen ist. wie langsam die softwaremühlen mahlen sieht man ja nicht nur bei der durchsetzung von 64bit-software sondern auch bei der nutzung von mehrprozessorsystemen (die ja schon ewig vom betriebssystem selbst unterstützt werden).

da letztere für mein nutzerprofil auch noch keinen nutzen bringen, arbeitet weiterhin ein fleißiges im 32bit-modus werkelndes 64bit cpu-lein für mich.

EDIT:
wenn dich die funktionsfähigkeit des 64bit-teils deiner cpu interessiert, dann saug dir doch einfach eine der vielen 64bit-versionen von linux-boot-cds, beispielsweise ubuntu. aus spass lasse ich manchmal meinen rechner damit booten, sehe dass nichts anders ist als vorher (mit 32bit) und "freue" mich über die theoretischen möglichkeiten.

[Gast]

Mein Athlon 64 hat meine Erwartungen vollstens erfüllt. Er hat immer ordentlich Leistung gebracht und bringt sie noch immer. Ein 64-bit-Windows benutze ich allerdings nicht. Trotzdem ist es äußerst sinnvoll, dass die CPU AMD64 kann. Nur so entsteht eine breite Hardwarebasis an 64-bit-Rechnern, sodass der Switch zu 64-bit überhaupt erfolgen kann. Man sollte nicht vergessen, dass der K8 die letzten 3 Jahre in erster Linie ein sehr schneller 32-bit-Prozessor war. Die 64-bit-Fähigkeit gab es eben zusätzlich.

[BlackBirdSR]

Hallo an alle Technikbegeisterten!

Ich möchte einen Thread starten, bei dem ich gerne eure Meinung zu der "neuen" 64-Bit Prozessorengeneration hören würde. Ich habe überlegt, ob ich diesen Thread hier oder in einem anderen Unterforum starten soll. Im Prinzip könnte man ihn fast in jedem Unterforum rechtfertigen, da die CPU der Kern des Computers ist und alle Bereiche (Mainboards/AMD/Intel/Windows/Spiele/Anwendungen/etc..) betrifft.
Es geht mir aber hier in erster Linie um die subjektiven Erfahrungen, die mit der 64-Bit Technik gemacht wurden, und vor allem auch um die Frage, ob eure Erwartungen an die neue Technik erfüllt wurden.



Dazu müsste man auch erstmal Erwartungen haben.
Mir ist schon klar, dass sich AMD und einige Firmen damals geradezu mit Meldungen erschlagen haben, die Performance und neue Features versprochen haben.
Allerdings habe ich das damals bereits bei MMX mitgemacht. Bei 3DNow! und SSE dann gleich nochmal. SSE2 war genauso, und mit 64 Bit war es nicht anders. Es werden pauschal 20-30% versprochen, die theoretisch vielleicht möglich sind. Praktisch bleiben vielleicht 5%, würde sich jemand die Mühe machen.

Als die ganzen Versprechungen und Interviews dann erschienen sind, ging ich einfach davon aus, das gleiche Geschwätz vor mir zu haben, dass es über die Jahre immer wieder gab. Und zwar nicht nur bei CPUs.
Sieht man sich dann etwas genau an, was AMD64 wirklich macht, dann hört man diesen Leuten auch gar nicht mehr zu.

x86-64 hat viel Potential, und es ist dringend notwendig. Es gibt viele Vorteile die auch spürbar sind. Aber nicht so wie es der Hype gerne darstellen würde.
Ich betreibe Win-XP64 und bin sehr zufrieden damit.
Erwartungen wurden insoweit erfüllt, dass x86-64 funktioniert und uns einen Schritt weiter bringt. Mehr Features oder Performance in Spielen habe ich nicht erwartet.

[StefanV]

SSE2 war genauso, und mit 64 Bit war es nicht anders. Es werden pauschal 20-30% versprochen, die theoretisch vielleicht möglich sind. Praktisch bleiben vielleicht 5%, würde sich jemand die Mühe machen.
Wenn man 64bit Integerwerte brauchen kann, kann AMD64 auch mal fast doppelt so schnell sein, z.B. bei Packern oder Verschlüsselung kann man sowas gebrauchen...
Aber auch NUR dann, sonst nicht.


x86-64 hat viel Potential, und es ist dringend notwendig. Es gibt viele Vorteile die auch spürbar sind. Aber nicht so wie es der Hype gerne darstellen würde.
Ich betreibe Win-XP64 und bin sehr zufrieden damit.
Erwartungen wurden insoweit erfüllt, dass x86-64 funktioniert und uns einen Schritt weiter bringt. Mehr Features oder Performance in Spielen habe ich nicht erwartet.
Naja, bleiben wir mal beim 'es ist dringendst Notwendig', den Rest sehe ich nicht soo sehr.
Außer ev. bei einigen 'Spezialanwendungen', was aber letztendlich bleibt ist der nötige, größere Adressraum...

[Tigerchen]

Hallo an alle Technikbegeisterten!

Ich möchte einen Thread starten, bei dem ich gerne eure Meinung zu der "neuen" 64-Bit Prozessorengeneration hören würde. Ich habe überlegt, ob ich diesen Thread hier oder in einem anderen Unterforum starten soll. Im Prinzip könnte man ihn fast in jedem Unterforum rechtfertigen, da die CPU der Kern des Computers ist und alle Bereiche (Mainboards/AMD/Intel/Windows/Spiele/Anwendungen/etc..) betrifft.
Es geht mir aber hier in erster Linie um die subjektiven Erfahrungen, die mit der 64-Bit Technik gemacht wurden, und vor allem auch um die Frage, ob eure Erwartungen an die neue Technik erfüllt wurden.

Am 22.09.2003 war der Release des Athlon 64 3100+, des ersten Athlon 64 für Desktopsysteme. In gut zwei Wochen wird die Technik damit 3 Jahre alt. Im PC-Bereich ist dies eigentlich schon ein beträchtliches Alter. Nach 3 Jahren erstaunt es daher doch umso mehr, daß immernoch ein großer Teil der User mit 32-Bit CPUs oder 32-Bit Betriebssystemen unterwegs ist. - Ist das 64 Bit-Konzept an Microsoft gescheitert?
Selbst heute sind echte 64-Bit Systeme (CPU+Betriebssystem) eher selten. Die 64-Bit Edition von Windows XP fristet ein trauriges Schattendasein, da alle Welt (wohl zurecht) bereits mit dem sofortigen Entwicklungsstop für diese Plattform rechnet, sobald Windows Vista irgendwann nächstes Jahr erscheint.
Entsprechende Anwendungen oder gar Spiele für 64-Bit Prozessoren sucht man mit der Lupe. Und wenn man mal eines findet, wie beispielsweise Farcry, erscheint es einem bei näherer Betrachtung doch mehr als fraglich, ob hier wirklich 64-Bit Kerne voll genutzt werden.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2411

Welche Erfahrungen habt ihr mit euren 64-Bit CPUs gemacht? Habt ihr ein 64-Bit Betriebssystem oder eine Anwendung, die diese Technik nutzt? Oder habt ihr zu einer 64-Bit CPU gegriffen, weil ihr -wie ich- für die Zukunft gerüstet sein wolltet?

Interessant finde ich in diesem Zusammenhang auch die Diskussion über die Mehrkerntechnik. Obwohl in den wenigsten PCs die 64-Bit Technik tatsächlich bereits zum Einsatz kommt, werben die Hersteller bereits für ihre DualCore-Produkte. Eine Technik, die erst recht nicht mehr von aktuellen Betriebssystemen unterstützt wird. Von Hand kann man heute "mühevoll" einzelne Prozesse auf die unterschiedlichen Cores aufteilen. Aber haben wir uns das wirklich so vorgestellt?
Hat die Chipindustrie nicht eher die Erwartungen geweckt, daß eine mäßig schnelle Anwendung nun durch doppelte Prozessorleistung beschleuningt wird?

Vielleicht sehe ich das falsch, aber wie zB. soll ein komplexer und damit langsamer Prozeß von 2 Cores gleichzeitig bearbeitet werden, wenn sogar der interne Cache nicht gemeinsam genutzt werden kann? Weiß die linke Hand überhaupt, was die rechte tut? Und was ich eher als Manko werte, wird dann von den Hersteller noch als Feature a la 'jeder Kern verfügt über seinen eigenen Cache' verkauft.

Aber das soll jetzt nicht vom Thema ablenken. Könnt ihr mir vielleicht einen Benchmark oder ein sonstiges herstellerunabhängiges Utility empfehlen, mit dem ich unter Windows32 wenigstens feststellen kann, ob meine 64-Bit CPU überhaupt funktioniert?

Schonmal Danke im voraus.
Alle meine Erwartungen wurden erfüllt.

1. Es setzte sich eine 64Bit Erweiterung durch mit der all meine Softwareschätze auch in Zukunft laufen.

2. Das der größere Adressraum erst mit einem neuen OS richtig genutzt werden wird war mir von Anfang an klar. Gleiches gilt für Multicore.

3. Auch der Umstieg von 16 zu 32 Bit hat "ewig" gedauert. Also nichts Neues.

[sanni]

Ich finde jetzt nicht unbedignt das der Umstieg im Moment etwas bringt aber später wenn Vista da ist werden alle froh sein einen AMD 64 und dergleichen zuhaben

[Gast]

Aber auch NUR dann, sonst nicht.

Sehr wohl kann es das. Doppelt so viele Register.

3. Auch der Umstieg von 16 zu 32 Bit hat "ewig" gedauert. Also nichts Neues.

Da war auch noch real->protected mode dabei. Heute kann man gut programmierte Software einfach neu kompilieren - ging damals nicht.

[BlackBirdSR]

Ich finde jetzt nicht unbedignt das der Umstieg im Moment etwas bringt aber später wenn Vista da ist werden alle froh sein einen AMD 64 und dergleichen zuhaben

Den größten Vorteil haben erstmal die Leute abseits der Öffentlichkeit.
Leute für uns Software entwickeln, oder damit professionell arbeiten.

Für uns normale User wird der Umstieg langsam und schleichend kommen. Es wird wohl nichtmal sonderlich spürbar sein.

[StefanV]

Naja, wenn man viel Speicher im System hat und mit mehreren Anwendungen gleichzeitig arbeitet (dabei ist es unerheblich, ob die Anwendung 32bittig oder 64bittig ist), hat man auch heute schon einen Vorteil.

Oder auch ansonsten Anwendungen die viel Speicher benötigen (Photoshop z.B.).

[Gast]

Naja, wenn man viel Speicher im System hat und mit mehreren Anwendungen gleichzeitig arbeitet (dabei ist es unerheblich, ob die Anwendung 32bittig oder 64bittig ist), hat man auch heute schon einen Vorteil.



naja nicht wirklich, jede anwendung hat ja ihren eigenen virtuellen adressraum, insofern kann man nur von 64 bit profitieren wenn eine einzelne anwendung an die grenze des adressraumes kommt.

[HOT]

naja nicht wirklich, jede anwendung hat ja ihren eigenen virtuellen adressraum, insofern kann man nur von 64 bit profitieren wenn eine einzelne anwendung an die grenze des adressraumes kommt.

Photoshop kann unter 64Bit 4GB Adressraum nutzen, unter 32Bit nicht, obwohl Photoshop eine 32Bit Anwendung ist. 32Bit Programme profitieren durchaus von 64Bit. Auch Spiele kann man teilweise über Konfigurationsdateien darauf optimieren, bei HL2 soll das angeblich gehen.

[#44]

Damals wurde von vielen Zeitschriften 64-Bit Technologie als DAS FEATURE schlechthin gehypet und dem weniger technikversierten User vorgegaukelt sie sei für den enormen Leistungsvorteil verantwortlich.

Nunja es war ja mehr oder weniger das Glück der 64-Bit Technologie das sie in Prozessoren die zum Erscheinungstermin NOCH mehr Leistung/MHZ boten zum Einsatz kam (was aber nicht mit dieser Technologie zuammenhing). So war sie schnell in aller Munde und auch in sehr vielen PCs.

[x]Meine Erwartung wurde erfüllt (wenn auch nicht durch die Technologie selbst, sondern eher durch das effiziente Design der A64 CPUs)

Nutzen habe ich allerdings bis heute keinen davon, da ich kein RAM-Monster unterm Tisch habe.

Die Zeit in der die Speicherverwaltung mit 32-Bit nichtmehr ausreicht ist schon in Sicht (gerade für Spieler und andersweitig spezialisierte User) daher: Besser zu früh als zu spät.

[Gast]

nein, imho hat sich nichts geändert !

[PHuV]

Ich muß denmächst auf 64 Bit umstellen bzw. auf 64 Bit entwickeln, aber erst mal unter Unix (HPUX Itanium und AIX), für zu Hause plane ich gerade eine Installation mit Java 64 und Eclipse 64 auf einem E6700, um mal ein bißchen rumzuspielen und zu testen, insbesondere die Ram Beschränkungen usw. .

Man wird auf 64 Bit bald umstellen müssen, weil einfach der 32 Bit-Adressraum für manchen Anwendungen einfach heute nicht mehr aussreicht. Ich verstehe sowieso nicht, warum das mit Vista nicht in 64 Bit durchgezogen wird.

[HisN]

Keine Erwartungen=Keine Enttäuschungen.

Aufm Server merke ich nen bisschen mehr Performance durchs 64-Bit-OS und auf der Workstation profitiert eigentlich nur Photoshop CS2 dadurch das es jetz 4GB Arbeits-Grundlage hat und nicht mehr 1,5GB ... das ist für mich nen Killerfeature, einige Filter laufen bis zu 100% schneller durch die Speichermenge, die Festplatte wird deutlich entlastet.

[Gast]

Photoshop kann unter 64Bit 4GB Adressraum nutzen, unter 32Bit nicht, obwohl Photoshop eine 32Bit Anwendung ist. 32Bit Programme profitieren durchaus von 64Bit.

klar, ich schrieb ja auch dass einzelne anwendungen die alleine sehr viel adressraum benögtigen profitieren.

StefanVs aussage habe ich aber eher so gedeutet dass man auch von 64bit profitiert wenn viele kleine anwendungen laufen, was aber nicht der fall ist da jede anwendung ihren eigenen adressraum bekommt.

[Don Vito]

für mich war ganz klar der Kaufgrund, das 64Bit Windoof zu testen.
DualCore ist klar für die neuen Games und Vista

[Brillus]

Also ich habe noch keinen, abr ich bin zfrieden damit.

Und mit den 64Bit ist nciht nru deswegen gut weil man mehr Speicher anfragen kann sondern auch weil man auch viel höhere Chancen hat wenn manwas anfrodert eine passenden platz zu bekomen. So hab ich es schon mal geschafft bei einen Programm das nur rund 100MB gebraucht hat hinzubekomen das kein Speicher mehr angefragt werden konnte.

(Es ging um ein Highmaüp renderer bei dem zuerst zum aufbauen viele kleien Objekte immer wieder neu erzeigt wurden und wenn ncihtmehr gebraucht werden weggeworfen wurden, und am schluss dann ein Großes objekt kam(Dann hat es geknallt))

[Dr. Chandra]

Dazu müsste man auch erstmal Erwartungen haben.
Mir ist schon klar, dass sich AMD und einige Firmen damals geradezu mit Meldungen erschlagen haben, die Performance und neue Features versprochen haben.(...)

Mehr Features oder Performance in Spielen habe ich nicht erwartet.
Also um ehrlich zu sein, hatte ich schon mehr Features und vor allen Dingen auch Performance in Spielen und Anwendungen erwartet. Und im Prinzip waren meine Erwartungen schon so, daß Microsoft erstmal keinen Nutzen aus der neuen Technologie zieht. Ich hätte eher erwartet, daß es die Programmierer sind (wie im Fall von Photoshop), die sich die 64-Bit-Technik "auf eigene Faust" zu Nutzen machen. Aber offenbar ist dies nicht oder zu wenig geschehen.
Entweder hat also die 64-Bit Technik nicht das angekündigte Potential, um aktuelle Programme zu beschleunigen, oder die Programmierer wollen die altbewährten "32-Bit-Trampelpfade" nicht verlassen. Eigentlich müßte es durch die 64-Bit Technik gerade beim Verschieben/Bearbeiten von großen Datenfeldern enorme Geschwindigkeitsvorteile geben. Ich bin daher schon ein bischen enttäuscht, daß sich nicht einmal die Geschwindigkeit/Datendichte bei aktuellen Packern wie WinZip erhöht hat. Wahrscheinlich fürchtet man dort aber auch, daß sich eine mit einer 64-Bit CPU bearbeitete Datei nicht mehr ohne weiteres von einer 32-Bit CPU auspacken lassen wird.

Der erweiterte Addressraum ist bei der 64-Bit Technik dabei für mich eher ein Feature, als das Hauptthema. Eigentlich müßte durch die 64-Bit Technik die Geschwindigkeit in der größere Integervariablen von der CPU bearbeitet werden, deutlich zu beschleunigen sein. Und hat sich durch die verbreiterten Register denn nicht auch die Rechengenauigkeit der FPU verdoppelt? Oder wurde die aus der 64-Bit Schiene ausgeklammert?

Hier gibt es ein Schaubild von AMD zur 64-Bit Technologie:

http://www.amd.com/de-de/Processors/ProductInformation/0,,30_118_9485_9487%5e9493,00.html

Wenn man genau hinschaut, entdeckt man, daß AMD sich von seinen "Additional 64-bit internal registers for computing performance" schon einen Performanceschub erhofft hat. - Nur wo ist der geblieben? - Ich erinnere mich noch dunkel an die Werbekampagne von AMD für ihre 64-Bit Prozessoren... war dort nicht ein muskelbepackter Oberarm mit einem AMD64-Logo zu sehen?... Wo steckt denn nun die ganze Power?

Kennt jemand eine Seite, auf der es ein besseres Schaubild zur 64 Bit Technologie gibt? - Was mich mal interessieren würde ist, ob die FPU ebenfalls in die 64-Bit Technik einbezogen wurde. Das Schaubild von AMD gibt zu dieser Frage nichts her.

[klumy]

Nein 64Bit CPUs haben mir nichts gebracht.
Jedoch hoffe ich auf die Zukunft

[Gast]

klar, ich schrieb ja auch dass einzelne anwendungen die alleine sehr viel adressraum benögtigen profitieren.

StefanVs aussage habe ich aber eher so gedeutet dass man auch von 64bit profitiert wenn viele kleine anwendungen laufen, was aber nicht der fall ist da jede anwendung ihren eigenen adressraum bekommt.

Uhm es gibt schon einen Vorteil, nämlich den wenn viele 32-Bit Apps zusammen mehr als 4GiB physikalischen RAM beanspruchen.

[del_4901]

Also um ehrlich zu sein, hatte ich schon mehr Features und vor allen Dingen auch Performance in Spielen und Anwendungen erwartet. Und im Prinzip waren meine Erwartungen schon so, daß Microsoft erstmal keinen Nutzen aus der neuen Technologie zieht. Ich hätte eher erwartet, daß es die Programmierer sind (wie im Fall von Photoshop), die sich die 64-Bit-Technik "auf eigene Faust" zu Nutzen machen. Aber offenbar ist dies nicht oder zu wenig geschehen.
Entweder hat also die 64-Bit Technik nicht das angekündigte Potential, um aktuelle Programme zu beschleunigen, oder die Programmierer wollen die altbewährten "32-Bit-Trampelpfade" nicht verlassen. Eigentlich müßte es durch die 64-Bit Technik gerade beim Verschieben/Bearbeiten von großen Datenfeldern enorme Geschwindigkeitsvorteile geben. Ich bin daher schon ein bischen enttäuscht, daß sich nicht einmal die Geschwindigkeit/Datendichte bei aktuellen Packern wie WinZip erhöht hat. Wahrscheinlich fürchtet man dort aber auch, daß sich eine mit einer 64-Bit CPU bearbeitete Datei nicht mehr ohne weiteres von einer 32-Bit CPU auspacken lassen wird.
eigendlich ist die Geschwindigkeit Summa Summarum sogar etwas langsamer, da die Pointer etwas größer geworden sind. Das versteckt sicht aber sehr gut hinter Latenzen.


Der erweiterte Addressraum ist bei der 64-Bit Technik dabei für mich eher ein Feature, als das Hauptthema.

Das ist das Feature schlechthin. Erstens hab ich so viel freien Adressraum, das ich fast schon würfeln kann um ein freies Plätzchen zu finden. Und zweitens kann ich mir meine komplette HDD oder GPU-RAM in den Adressraum mappen, das ist die edelste aller Zugriffsformen!

Eigentlich müßte durch die 64-Bit Technik die Geschwindigkeit in der größere Integervariablen von der CPU bearbeitet werden, deutlich zu beschleunigen sein.
Nur das 64bit Ints kein Schwein braucht, außer bei Cryptographie etc.

Und hat sich durch die verbreiterten Register denn nicht auch die Rechengenauigkeit der FPU verdoppelt? Oder wurde die aus der 64-Bit Schiene ausgeklammert?

Nein die FPU ist wie eh und jeh 80bit breit 128bei SIMD ISSE Berechnungen, und das war schon immer so.

Hier gibt es ein Schaubild von AMD zur 64-Bit Technologie:

http://www.amd.com/de-de/Processors/ProductInformation/0,,30_118_9485_9487%5e9493,00.html

Wenn man genau hinschaut, entdeckt man, daß AMD sich von seinen "Additional 64-bit internal registers for computing performance" schon einen Performanceschub erhofft hat. - Nur wo ist der geblieben? - Ich erinnere mich noch dunkel an die Werbekampagne von AMD für ihre 64-Bit Prozessoren... war dort nicht ein muskelbepackter Oberarm mit einem AMD64-Logo zu sehen?... Wo steckt denn nun die ganze Power?

Kennt jemand eine Seite, auf der es ein besseres Schaubild zur 64 Bit Technologie gibt? - Was mich mal interessieren würde ist, ob die FPU ebenfalls in die 64-Bit Technik einbezogen wurde. Das Schaubild von AMD gibt zu dieser Frage nichts her.
Ohne 64-bit SW auch keine zusätzlichen Register. Die bringen etwas an Perfomance, sind aber meiner Meinung nach überbewertet.

[del_4901]

Uhm es gibt schon einen Vorteil, nämlich den wenn viele 32-Bit Apps zusammen mehr als 4GiB physikalischen RAM beanspruchen.
Falsch, hier kann man Swappen oder man nutzt PAE. Mal davon abgesehen, das eine Anwendung unter 32bit jehmals 4GiB bekommen wird. Da muss noch so einiges Anderes in den Adressraum rein.

[Neomi]

Wahrscheinlich fürchtet man dort aber auch, daß sich eine mit einer 64-Bit CPU bearbeitete Datei nicht mehr ohne weiteres von einer 32-Bit CPU auspacken lassen wird.

Es gibt keinen Grund, sowas zu fürchten. Erstmal kann man 64 Bit Arithmetik auch mit einer 32 Bit CPU nutzen, dann nur eben etwas langsamer dank Emulation. Andererseits hat ein Datenformat nicht von der ausführenden Hardware abhängig zu sein.

Und hat sich durch die verbreiterten Register denn nicht auch die Rechengenauigkeit der FPU verdoppelt? Oder wurde die aus der 64-Bit Schiene ausgeklammert?

FP64 (Double Precision) gab es schon lange vor 64 Bit, intern wird sogar in der Regel mit 80 Bit gerechnet.

[Gast]

Uhm es gibt schon einen Vorteil, nämlich den wenn viele 32-Bit Apps zusammen mehr als 4GiB physikalischen RAM beanspruchen.

dazu bräuchte man erstmal mehr als 4GiB physikalischen speicher, was allerdings kein "normales" mainboard unterstützt soviel speicher, und selbst wenn könnte man diesen mit PAE auch nützen.

der einzig wirkliche vorteil besteht dann wenn eine anwendung entsprechend viel speicher braucht.

[Gast]

Also um ehrlich zu sein, hatte ich schon mehr Features und vor allen Dingen auch Performance in Spielen und Anwendungen erwartet. Und im Prinzip waren meine Erwartungen schon so, daß Microsoft erstmal keinen Nutzen aus der neuen Technologie zieht.


dann hast du die 64bit-technik nicht verstanden.


Ich hätte eher erwartet, daß es die Programmierer sind (wie im Fall von Photoshop), die sich die 64-Bit-Technik "auf eigene Faust" zu Nutzen machen. Aber offenbar ist dies nicht oder zu wenig geschehen.
Entweder hat also die 64-Bit Technik nicht das angekündigte Potential, um aktuelle Programme zu beschleunigen, oder die Programmierer wollen die altbewährten "32-Bit-Trampelpfade" nicht verlassen. Eigentlich müßte es durch die 64-Bit Technik gerade beim Verschieben/Bearbeiten von großen Datenfeldern enorme Geschwindigkeitsvorteile geben.


wieso sollte das mit 64bit-technik schneller werden? im gegenteil durch die größeren pointer wird es eher langsamer.


Ich bin daher schon ein bischen enttäuscht, daß sich nicht einmal die Geschwindigkeit/Datendichte bei aktuellen Packern wie WinZip erhöht hat. Wahrscheinlich fürchtet man dort aber auch, daß sich eine mit einer 64-Bit CPU bearbeitete Datei nicht mehr ohne weiteres von einer 32-Bit CPU auspacken lassen wird.


was soll denn der quatsch? wieso sollte sich eine datei welche mit einer 64bit-cpu gepackt wurde nicht mit einer 32bit-cpu entpacken lassen? das endergebnis ist doch das selbe, höchstens der weg dahin etwas anders.



Der erweiterte Addressraum ist bei der 64-Bit Technik dabei für mich eher ein Feature, als das Hauptthema.


das ist eigentlich das wichtigste an der sache, natürlich vor allem für programmierer, der enduser bekommt ja nicht mit welche winkelzüge sich die programmierer ausdenken müssen um nicht über den 32bit adressraum drüberzuschießen.


Eigentlich müßte durch die 64-Bit Technik die Geschwindigkeit in der größere Integervariablen von der CPU bearbeitet werden, deutlich zu beschleunigen sein.


nur braucht man in den seltensten fällen 64bit integers.


Und hat sich durch die verbreiterten Register denn nicht auch die Rechengenauigkeit der FPU verdoppelt? Oder wurde die aus der 64-Bit Schiene ausgeklammert?


die fpu war schon immer 80bit für die FPU bzw. 128bit für SSE, da war keine verbreiterung mehr nötig.




Wenn man genau hinschaut, entdeckt man, daß AMD sich von seinen "Additional 64-bit internal registers for computing performance" schon einen Performanceschub erhofft hat. - Nur wo ist der geblieben? - Ich erinnere mich noch dunkel an die Werbekampagne von AMD für ihre 64-Bit Prozessoren... war dort nicht ein muskelbepackter Oberarm mit einem AMD64-Logo zu sehen?... Wo steckt denn nun die ganze Power?


sicher bringen die zusätlichen register ein wenig, aber vollbringen auch keine wunder.

[Gast]

Man wird auf 64 Bit bald umstellen müssen, weil einfach der 32 Bit-Adressraum für manchen Anwendungen einfach heute nicht mehr aussreicht. Ich verstehe sowieso nicht, warum das mit Vista nicht in 64 Bit durchgezogen wird.

Weil es die Masse noch nicht braucht. Otto-Normal-Verbraucher kommt auch heutzutage noch prima mit 512MB über die Runden.

[Gast]

Weil es die Masse noch nicht braucht. Otto-Normal-Verbraucher kommt auch heutzutage noch prima mit 512MB über die Runden.
Es geht um den virtuellen Adressraum, nicht um die Speicherkapazität des Arbeitsspeichers.

[Gast]

dazu bräuchte man erstmal mehr als 4GiB physikalischen speicher, was allerdings kein "normales" mainboard unterstützt soviel speicher, und selbst wenn könnte man diesen mit PAE auch nützen.

Ist PAE in der Hinsicht wirklich transparent? Ich weiß ja das eine Anwendung das über die komische API benützen muss, aber paged das OS bei mehreren Anwendungen automatisch?

[Gast]

Es geht um den virtuellen Adressraum, nicht um die Speicherkapazität des Arbeitsspeichers.

Ist mir schon klar, dass der Adresspool für den "realen" und virtuellen Speicher herhalten müssen. Ja und?
Auch als Vista-Normal-Benutzer wird man imo damit die nächsten 5 Jahre noch gut über die Runden kommen.
Und für die Sonderfälle gibts ja noch das Paging (nicht der Weisheit letzter Schluß, aber es funktioniert).

[del_4901]

Ist mir schon klar, dass der Adresspool für den "realen" und virtuellen Speicher herhalten müssen. Ja und?
Auch als Vista-Normal-Benutzer wird man imo damit die nächsten 5 Jahre noch gut über die Runden kommen.
Und für die Sonderfälle gibts ja noch das Paging (nicht der Weisheit letzter Schluß, aber es funktioniert).

Au ich krieg Kopfschmerzen. Bitte nochmal genauer über Pageing informieren. Unterschiede zu Swapping und virtueller Adressraum. Ich würd's dir ja erklärn, aber das währ dann das 1 000 000mal in diesem Forum, und außerdem füllt das eine ganze Vorlesung eines Semesters.
Aber soviel kann ich dir verraten, wenn Paging nicht die Weißheit letzter Schluss ist, was dann? Swapping, Overlay, die Segmentierung eines 8086?

Aber eine Frage habe ich dann doch noch: Was für Sonderfälle?

Und dann habe ich noch eine Prüfungsfrage für dich (sogar mit ankreuzen)
Was bedingt Paging?
[ ] mehr Adressen als Speicher.
[ ] mehr Speicher als Adressen.

[Colin MacLaren]

Ich als technisch eher nicht so versierter Anwender hatte vor zwei Jahren damit gerechnet, daß im Jahre 2006 eine relativ breite Masse an Spielen optionalen 64-Bit Support hat und im Bereich von 10-15% von profitieren.

Daß 64-Bit quasi völlig ungenutzt bleibt hätte ich nicht erwartet.

[StefanV]

dazu bräuchte man erstmal mehr als 4GiB physikalischen speicher, was allerdings kein "normales" mainboard unterstützt soviel speicher, und selbst wenn könnte man diesen mit PAE auch nützen.

der einzig wirkliche vorteil besteht dann wenn eine anwendung entsprechend viel speicher braucht.
*Aua*
Wenn ich sowas schon lesen muss, wird mir ganz anders...
Du hast echt keinen Plan, was so alles adressiert werden muss bzw wie vollgemüllt der Adressraum ist.

Ansonsten:
Siehe Signatur, lies den Thread, da steht alles drin, alles weitere zum Thema Adressraum und Speicher da rein, nicht hier!

[kruemelmonster]

Ich als technisch eher nicht so versierter Anwender hatte vor zwei Jahren damit gerechnet, daß im Jahre 2006 eine relativ breite Masse an Spielen optionalen 64-Bit Support hat und im Bereich von 10-15% von profitieren.

Daß 64-Bit quasi völlig ungenutzt bleibt hätte ich nicht erwartet.

Das lässt sich gut mit den DirectX Hardwaregenerationen und dem passenden Spielesupport vergleichen: es hängt alles von der weltweit installierten Hardwarebasis ab.

Der R300 ist vor Pi-mal-Daumen 3 Jahren rausgekommen, so ziemlich jeder Spieler hat sich in der Zeit min. einen DX9 Beschleuniger gekauft, ergo sehen wir kurz vor D3D10 die Blütezeit der DX9 Spiele, ermöglicht durch die hohe Verbeitung von DX9 Hardware, und sei es auch nur ne GF6100 onboard.

Mit Vista geht das Spiel dann in die nächste Runde: meine erste D3D10 Karte wird außer Crysis und ein paar D3D10 Techdemos wohl ausschließlich DX9 Spiele beschleunigen dürfen bis dann auch der letzte Lidl-PC Käufer D3D10 mittels einer GeForce 8200 TC oder Radeon X2300 HM abgreift und wir auf die 11er Geschmacksrichtung warten.

Solange da draussen weiterhin "zu viele" Athlon XP's und P4's (ich weiß, da gibt's auch n paar mit AMD64;D) ihren Dienst tun wird sich kaum ein Unternehmen auf 64bit stürzen, Spezialfälle ausgenommen.

/edit:

Was ich recht bemerkenswert finde, ist das Microsoft schon während der Entwicklung von Windows 2000 von einer 64bittigen AMD CPU Kenntnis hatte. Auf der Windows 2000 CD gibt es im i386 Ordner in der txtsetup.sif gleich am Anfang die Einträge für die verschiedenen CPU-Architekturen: da gibt's alpha, x86, ia64 und zum Schluss axp64. Klingt wie AMD, watschelt wie AMD, wird wohl AMD sein. Leider ist meine älteste Win2000 CD mit SP2, falls also noch jemand eine Uralt Win2000 RTM CD rumliegen hat, bitte mal nachschauen.

[Gast]

*Aua*
Wenn ich sowas schon lesen muss, wird mir ganz anders...
Du hast echt keinen Plan, was so alles adressiert werden muss bzw wie vollgemüllt der Adressraum ist.



natürlich hab ich soviel plan dass ich weiß dass der 4GB adressraum (bzw. eigentlich nur 2GB/anwendung) knapp wird.
nur bringt dir 64bit rein garnichts wenn du 1000 anwendungen hast die je 100MB adressraum benötigen. jede anwendung bekommt nämlich ihren eigenen adressraum und der ist in diesem fall für jede anwendung leer genug. windows kann für alle anwendungen gemeinsam wesentlich mehr als 4GB beanspruchen, und das im 32bit-modus.

[HOT]

dazu bräuchte man erstmal mehr als 4GiB physikalischen speicher, was allerdings kein "normales" mainboard unterstützt soviel speicher, und selbst wenn könnte man diesen mit PAE auch nützen.

der einzig wirkliche vorteil besteht dann wenn eine anwendung entsprechend viel speicher braucht.

Nahezu alle A64 Boards unterstützen mehr, da der A64 Controller mehr kann (bis zu 4 2GB Modulen).

[HOT]

Ist mir schon klar, dass der Adresspool für den "realen" und virtuellen Speicher herhalten müssen. Ja und?
Auch als Vista-Normal-Benutzer wird man imo damit die nächsten 5 Jahre noch gut über die Runden kommen.
Und für die Sonderfälle gibts ja noch das Paging (nicht der Weisheit letzter Schluß, aber es funktioniert).

Nein, der Adressraum muss für ALLES herhalten, zum Beispiel auch alle Geräte.

[Gast]

Nein, der Adressraum muss für ALLES herhalten, zum Beispiel auch alle Geräte.

klar, aber der adressraum existiert für jeden prozess extra.

100 prozesse können für sich wunderbar in den 32bit adressraum passen und insgesamt trotzdem deutlich mehr als 4GB in anspruch nehmen.

[del_4901]

klar, aber der adressraum existiert für jeden prozess extra.

100 prozesse können für sich wunderbar in den 32bit adressraum passen und insgesamt trotzdem deutlich mehr als 4GB in anspruch nehmen.
Nichts Anderes hat er behauptet!

Er hat nur gesagt das sämtliche I/O in den Adressraum gemappt werden muss.
Willst du also in Programm XYZ deine Graka oder ganz simpel eine Mouse benutzen, müssen die entsprechenden dlls + was sonnst noch dazukommt (Grafikspeicher) in den Adressraum gemappt werden.

Um mal einer Frage vorwegzugreifen: Nein, der Taskmanger zeigt diesen "Overhead" nicht an.

[Tigerchen]

Sehr wohl kann es das. Doppelt so viele Register.



Da war auch noch real->protected mode dabei. Heute kann man gut programmierte Software einfach neu kompilieren - ging damals nicht.

1. Wo zum Teufel hast du das erste Zitat her? Das ist nicht von mir!

2. Tut keiner. Es ist schon so wie ich schrieb. So ein Umstieg dauert eben seine Zeit. Das wichtigste ist doch sowieso daß uns IA-64 erspart bleibt.

[Dr. Chandra]

Es gibt keinen Grund, sowas zu fürchten. Erstmal kann man 64 Bit Arithmetik auch mit einer 32 Bit CPU nutzen, dann nur eben etwas langsamer dank Emulation. Andererseits hat ein Datenformat nicht von der ausführenden Hardware abhängig zu sein.

Interessante These, daß sagen die Programmierer von WinZip dazu:

Neben dem urspr�nglichen ZIP-Dateiformat unterst�tzt WinZip 9.0 auch die 64-Bit-Erweiterungen des ZIP-Dateiformats. In diesem erweiterten Format k�nnen Sie beliebige Datenmengen in ZIP-Dateien speichern, die praktisch keinen Gr��enbeschr�nkungen mehr unterliegen.

Beim urspr�nglichen ZIP-Format war die Anzahl der Dateien in einer ZIP-Datei auf 65.535 und die Gr��e der archivierten Dateien sowie der Archivdatei selbst auf 4 GB begrenzt. F�r das erweiterte 64-Bit-Format gelten diese Einschr�nkungen nicht mehr. Sowohl die Gr��e und Anzahl der archivierten Dateien als auch die Gr��e der ZIP-Datei selbst ist praktisch nur noch durch die verf�gbaren Systemressourcen begrenzt.

Das urspr�ngliche Dateiformat wird von WinZip nach wie vor in vollem Umfang unterst�tzt und nach M�glichkeit auch weiterhin verwendet. Das erweiterte 64-Bit-Format wird nur benutzt, wenn dies aufgrund der Gr��e oder Anzahl der Dateien erforderlich ist.

Hinweis: ZIP-Dateien, die mithilfe der 64-Bit-Erweiterung erstellt wurden, k�nnen nur mit einem ZIP-Dienstprogramm wie WinZip 9.0 ge�ffnet werden, das dieses Format ebenfalls unterst�tzt.

http://www.winzip.de/whatsnew90.htm

Ob man nur ein WinZip 9.0 mit der 64-Bit-Erweiterung benötigt, oder auch eine zugehörige 64-Bit CPU (was ich vermute), wird hier nicht deutlich. Aber warum sollte WinZip sonst weiterhin erstmal das "ursprüngliche" Dateiformat verwenden und nur in Ausnahmefällen auf die 64-Bit-Erweiterung zurückgreifen?

Interessant fand ich auch den Erfahrungsbericht zu der für 64-Bit optimierten Version von Mini-GZIP. Wenn ich den unten zitierten Artikel richtig lese, wurde von den Programmieren von Mini-GZIP eine gebremste 32-Bit Version in Umlauf gebracht, um dem dummen User einen gewaltigen Performance-Gewinn der 64-Bit Version des Programmes vorzugaukeln. Ein direkter Vergleich mit dem alten 32-Bit-WinZip hat diesen "64-Bit-Betrug" jedoch auffliegen lassen:

"Bereits ein Re-Compile mit Microsoft Visual Studio sowie das Setzen einiger Compiler-Switches steigert die Performance von Mini-GZIP 32 Bit um zirka die Hälfte."

"Die 64-Bit-Version von Mini-GZIP wird von einer AMD64-optimierten Assembler-Routine unterstützt. Mit der "handgestrickten" 64-Bit-Optimierung ist der Athlon 64 FX-51 aber trotzdem nicht schneller als das 32-Bit-WinZip."

"Das Beispiel des hochoptimierten 64-Bit-Packers und des beigelegten 32-Bit-Packers mit nicht optimiertem Code zeigt, dass von Herstellern gelieferte Benchmarks stets mit Vorsicht zu genießen sind. Je nach verwendetem Compiler sowie dessen Einstellungen kann man Programme beliebig bremsen. Finale Analysen über die 64-Bit-Performance können wir erst mit Benchmark-Tools von Drittanbietern machen."

http://www.computerpartner.de/technik/636696/index.html

Da meine obige Frage nach einem solchen Benchmarktool offenbar untergegangen ist, stelle ich sie an dieser Stelle noch einmal:
Kennt jemand ein zuverlässiges Tool oder ein Utility, mit welchem sich die 64-Bit Performance oder die 64-Bit Funktionalität meiner CPU anzeigen läßt?
Bitte kein Tool von den Herstellern AMD/Intel, da diese Tools mit Sicherheit "geschönte" Werte verkünden.

Ich stelle mir den Test ungefähr so vor:
Zuerst wird ein Datenfeld unter Zuhilfenahme der bewährten 32-Bit-Technik verarbeitet (auf Zeit). Im zweiten Durchgang wird dasselbe Datenfeld nun unter Zuhilfenahme von nativem (also nicht lediglich 64-Bit-optimierten) Programmcode noch einmal verarbeitet.

Hier müßte sich dann doch gerade auch bei Verwendung von ein und derselben CPU ein Unterschied erkennen lassen. Wenn (was ich schon beinahe gewillt bin zu vermuten) hier kein meßbarer Unterschied festzustellen ist, dann müßte man doch die Frage nach der Ursache stellen. Werden im normalen Anwendungsfall bei einer 64-Bit-CPU nur mehr "Nullen" durch die Register geschoben? Was denkt ihr?
Etwas ähnliches habe ich hier bereits in einem anderen Thread "vermutet", der aufgrund der genervten Reaktion eines "bekennenden" 64-Bit-DualCore-Besitzers leider geschlossen werden mußte.

[del_4901]

Interessante These, daß sagen die Programmierer von WinZip dazu:

Neben dem urspr�nglichen ZIP-Dateiformat unterst�tzt WinZip 9.0 auch die 64-Bit-Erweiterungen des ZIP-Dateiformats. In diesem erweiterten Format k�nnen Sie beliebige Datenmengen in ZIP-Dateien speichern, die praktisch keinen Gr��enbeschr�nkungen mehr unterliegen.

Beim urspr�nglichen ZIP-Format war die Anzahl der Dateien in einer ZIP-Datei auf 65.535 und die Gr��e der archivierten Dateien sowie der Archivdatei selbst auf 4 GB begrenzt. F�r das erweiterte 64-Bit-Format gelten diese Einschr�nkungen nicht mehr. Sowohl die Gr��e und Anzahl der archivierten Dateien als auch die Gr��e der ZIP-Datei selbst ist praktisch nur noch durch die verf�gbaren Systemressourcen begrenzt.

Das urspr�ngliche Dateiformat wird von WinZip nach wie vor in vollem Umfang unterst�tzt und nach M�glichkeit auch weiterhin verwendet. Das erweiterte 64-Bit-Format wird nur benutzt, wenn dies aufgrund der Gr��e oder Anzahl der Dateien erforderlich ist.

Hinweis: ZIP-Dateien, die mithilfe der 64-Bit-Erweiterung erstellt wurden, k�nnen nur mit einem ZIP-Dienstprogramm wie WinZip 9.0 ge�ffnet werden, das dieses Format ebenfalls unterst�tzt.

http://www.winzip.de/whatsnew90.htm

Ob man nur ein WinZip 9.0 mit der 64-Bit-Erweiterung benötigt, oder auch eine zugehörige 64-Bit CPU (was ich vermute), wird hier nicht deutlich. Aber warum sollte WinZip sonst weiterhin erstmal das "ursprüngliche" Dateiformat verwenden und nur in Ausnahmefällen auf die 64-Bit-Erweiterung zurückgreifen?

Interessant fand ich auch den Erfahrungsbericht zu der für 64-Bit optimierten Version von Mini-GZIP. Wenn ich den unten zitierten Artikel richtig lese, wurde von den Programmieren von Mini-GZIP eine gebremste 32-Bit Version in Umlauf gebracht, um dem dummen User einen gewaltigen Performance-Gewinn der 64-Bit Version des Programmes vorzugaukeln. Ein direkter Vergleich mit dem alten 32-Bit-WinZip hat diesen "64-Bit-Betrug" jedoch auffliegen lassen:

"Bereits ein Re-Compile mit Microsoft Visual Studio sowie das Setzen einiger Compiler-Switches steigert die Performance von Mini-GZIP 32 Bit um zirka die Hälfte."

"Die 64-Bit-Version von Mini-GZIP wird von einer AMD64-optimierten Assembler-Routine unterstützt. Mit der "handgestrickten" 64-Bit-Optimierung ist der Athlon 64 FX-51 aber trotzdem nicht schneller als das 32-Bit-WinZip."

"Das Beispiel des hochoptimierten 64-Bit-Packers und des beigelegten 32-Bit-Packers mit nicht optimiertem Code zeigt, dass von Herstellern gelieferte Benchmarks stets mit Vorsicht zu genießen sind. Je nach verwendetem Compiler sowie dessen Einstellungen kann man Programme beliebig bremsen. Finale Analysen über die 64-Bit-Performance können wir erst mit Benchmark-Tools von Drittanbietern machen."

http://www.computerpartner.de/technik/636696/index.html

Da meine obige Frage nach einem solchen Benchmarktool offenbar untergegangen ist, stelle ich sie an dieser Stelle noch einmal:
Kennt jemand ein zuverlässiges Tool oder ein Utility, mit welchem sich die 64-Bit Performance oder die 64-Bit Funktionalität meiner CPU anzeigen läßt?
Bitte kein Tool von den Herstellern AMD/Intel, da diese Tools mit Sicherheit "geschönte" Werte verkünden.

Ich stelle mir den Test ungefähr so vor:
Zuerst wird ein Datenfeld unter Zuhilfenahme der bewährten 32-Bit-Technik verarbeitet (auf Zeit). Im zweiten Durchgang wird dasselbe Datenfeld nun unter Zuhilfenahme von nativem (also nicht lediglich 64-Bit-optimierten) Programmcode noch einmal verarbeitet.

Hier müßte sich dann doch gerade auch bei Verwendung von ein und derselben CPU ein Unterschied erkennen lassen. Wenn (was ich schon beinahe gewillt bin zu vermuten) hier kein meßbarer Unterschied festzustellen ist, dann müßte man doch die Frage nach der Ursache stellen. Werden im normalen Anwendungsfall bei einer 64-Bit-CPU nur mehr "Nullen" durch die Register geschoben? Was denkt ihr?
Etwas ähnliches habe ich hier bereits in einem anderen Thread "vermutet", der aufgrund der genervten Reaktion eines "bekennenden" 64-Bit-DualCore-Besitzers leider geschlossen werden mußte.

Du vermutest falsch.

Du wurstest einfach alles Durcheinander.

64bit != 64bit

Eine 64bit ist eine CPU, welche einen 2^64 bit Großen Adressraum besitzt.
Das und allein das ist das Kriterium für eine 64bit CPU!

So ist z.B der AGTL (FSB) eines Pentium 4 Northwood 64bit breit (trotzdem ist es keine 64bit CPU)
Der Pentium MMX kann über die MMX Unit 64bit (packed)-Integer "durchwürgen".
Auch der Pentium ohne MMX kann das schon eben über die normale 32bit Festkomma Einheit indem High und Low bit extra berechnet werden ... Datentyp long.
Ebenso ist DDR über einen 64bit breiten BUS angebunden.


Und genau so kann man auch (da muss ich jetzt lügen, wieviel es genau sind... sind aber mehr als 32) das Dateisystem mit einem 64bit Dateisystem Formatieren. (wie vermutlich NTFS ... ich hab nicht nachgeschaut ... ist aber auch egal). Auch ein 32bit Prozessor kann dieses Dateiformat lesen, und eben somit auch Dateien größer als 4GB.
Nichts Anderes ist eben das neue Winzip Format ... da ist einfach mehr Platz gelassen worden, um größere Datein packen zu können, ende aus Feierabend!


Und an der Performance wird sich auch durch x64 NICHTS ändern zumindestens nicht viel, mal abgesehen von den zusätzlichen Registern, und einigen wenigen Beispielen wo man int64 bzw long benutzen kann. (das ist aber die Minderheit aller Fälle und insbesondere in Spielen etc. NICHT anzutreffen)

Trotzdem brauchen wir den 64bit Adressraum, weil bald Feierabend ist und wir nichtmehr genug Daten für Spiel XYZ Adressieren können, oder halt eben auf eine sehr langsame Emulation zurückgreifen müssten. (die kann geartet sein wie auch immer, ich lass das mal hier außen vor ... Stichwort Overlays[eine der Möglichkeiten ... wenn noch möglich, die beste Variante] wen es interessiert)

[Dr. Chandra]

Du vermutest falsch.

Du wurstest einfach alles Durcheinander.

64bit != 64bit

Eine 64bit ist eine CPU, welche einen 2^64 bit Großen Adressraum besitzt.
Das und allein das ist das Kriterium für eine 64bit CPU!

Negativ. Ich wurste nicht. - Eine 64-Bit CPU ist eine CPU deren Adreß- und Datenregister 64-Bit breit sind. Der 2^64(?) Bit große Adreßraum beruht einzig und allein auf der Tatsache, daß durch die verbreiterten Adreßregister mehr 'Hausnummern' verteilt/mehr Daten adressiert werden können, was aber nur ein Teilaspekt einer 64-Bit CPU ist.

64 Bit = 64 Bit

"Alle Register sind bei AMD64 64 Bit lang; wenn der Prozessor im 32-bit-Kompatibilitätsmodus läuft, werden die obersten 32 Bit jedes Registers auf 0 gesetzt."

http://de.wikipedia.org/wiki/AMD64

Wie es bei den Intel-CPUs aussieht, weiß ich natürlich nicht. Die sind bei mir aber auch schon seit sie ihren ersten Celeron-Prozessor rausgebracht haben unten durch. Intels Firmenpolitik würde ich glatt zutrauen eine 128-Bit CPU vorzustellen. Und wenn man unter die "Haube" schaut sind es in Wirklichkeit nur 2 64-Bit Cores.

Wenn die obige Aussage zutrifft -was sie tut-, dann schaufelt jede 64-Bit CPU bei jedem Taktzyklus 32 binäre Nullen pro Register durch den Speicher. Bei einer DualCore CPU, deren zweiter Kern nicht anständig genutzt wird, sind es sogar 96 Nullen, die bei jedem Takt pro Register durch den Chip wandern. Es ist nämlich keineswegs so, daß die oberen 32-Bit der 64-Bit Register nicht geladen und zwischengespeichert werden:

"Alle Adresswerte sind 64bit statt 32bit breit, deren Speicherung verbraucht daher doppelt soviel Platz, bei Bewegungen zwischen RAM und CPU müssen somit doppelt soviel Bytes bewegt werden, und verbrauchen auch in den Caches doppelt soviel Platz. Auch manche andere Objekte werden bei der Neuübersetzung von x86 von 32bit auf 64bit im x64 Modell erweitert - sichtbar wird dieses in den erzeugten Programmdateien, die typisch 25%-30% größer sind."

Insoweit könnte man AMD also gratulieren, daß sie es geschafft haben, daß ihre 64-Bit Boliden nicht auch noch effektiv langsamer werkeln, als ihre 32-Bit Vorgänger. Aber wer weiß - noch sind ja keine echten 64-Bit-Anwendungen / Spiele draußen. Vielleicht kommt der große Aufschrei ja erst noch, wenn beim ersten echten direkten Leistungsvergleich zwischen einer 32- und 64-Bit-CPU die 64-Bit CPU auf dem selben Leistungsniveau einer vergleichbaren 32-Bit-CPU aber mit halbem L1-Cache liegt.

Wäre es also denkbar, daß die selbe Anwendung auf Rechnern mit Windows Vista (soweit sie den zusätzlichen Adreßraum nämlich gar nicht benötigt) auf einer vergleichbaren 32-Bit CPU erheblich schneller läuft?

Ich stell mir das ganze bildlich so vor:

64-Bit-CPU:
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 + 1 = 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 000A

32-Bit-CPU:
0000 0000 0000 0000 0000 0000 0000 0001 + 1 = 0000 0000 0000 0000 0000 0000 0000 000A

Versteht ihr, was ich meine? Rein theoretisch müßte sich dieser "Bremseffekt" auf 64-Bit-Sytemen schon im 32-Bit-Kompatibiltätsmodus bemerkbar machen. Offenbar hat AMD es aber geschafft, diesen Performanceeinbruch durch vergrößerte Caches und angehobene Taktraten abzufedern. Wer sich bei seinem Athlon64 jedoch über den größeren Cache und die höhere Taktung freut, der muß sich nun doch fragen, ob dieser "Fortschritt" nicht durch die 64-Bit-Technik aufgefressen wurde.

[del_4901]

Das mit den 64bit breiten Registern stimmt, aber soweit wollte ich gar nicht aushohlen, warscheinlich um weitere Fragen zu erspaaren. ^^
Aber 64bit breite Integer-Rechneneinheiten sind keine Pflicht, aber oft vorzufinden.

Die Nullierung der Oberen-bits bringt natürlich auch keine Geschwindigkeitsnachteile im 32bit Mode. Wiso auch? es wird einfach nur mit dem unteren Bits gerechnet. Ich denke AMD war clever genug, nicht die kompletten Registerwerte im 32bit Modus durch die Busse zu jagen.

Wenn ich an die x32 Adressgrenze stoße ist es schneller mit dem x64 Overhead zu leben, als großartig drumherum zu programmiern, FAKT!

[Dr. Chandra]

Ich denke AMD war clever genug, nicht die kompletten Registerwerte im 32bit Modus durch die Busse zu jagen.
Das ist eine Frage, die mich zum Beispiel brennend interessieren würde. Deshalb suche ich auch unter anderem nach einem Benchmark-Tool, daß solche Dinge einmal abchecken könnte.
Wie ist zB. die tatsächliche L1-Cache-Nutzung einer 64-Bit-CPU im Vergleich zu einer 32-Bit-CPU oder im Kompatibilitätsmodus. Und wenn es im Kompatibilitätsmodus tatsächlich zu einer echten eingeschränkten Nutzung (also auch Minderbelastung der Caches) kommt, dann frage ich mich, ob uns mit der Einführung von Windows Vista nicht noch eine 'böse' Überraschung ins Haus steht.

[del_4901]

Das ist eine Frage, die mich zum Beispiel brennend interessieren würde. Deshalb suche ich auch unter anderem nach einem Benchmark-Tool, daß solche Dinge einmal abchecken könnte.
Wie ist zB. die tatsächliche L1-Cache-Nutzung einer 64-Bit-CPU im Vergleich zu einer 32-Bit-CPU oder im Kompatibilitätsmodus. Und wenn es im Kompatibilitätsmodus tatsächlich zu einer echten eingeschränkten Nutzung (also auch Minderbelastung der Caches) kommt, dann frage ich mich, ob uns mit der Einführung von Windows Vista nicht noch eine 'böse' Überraschung ins Haus steht.

Unwarscheinlich, weil für die Sachen, die wir Hauptsächlich bzw. Hauptberuflich machen, ist mehr als genug Cache zur Verfügung. Und die neue 3D-Software bzw. Spiele wird ihre ganze Kraft aus dem 64bit Adressraum schröpfen. Unreal3 belegt jetzt bereits schon soviel Hauptspeicher, das die Adressen schon allein dafür ... da ist noch kein I/O Gerät mich eingerechnet ... knapp wird.

Ich hab selber WINx64 in Betrieb mit EMT64 und bin begeistert, wie responive so ein System doch sein kann. So Böse wird die Überraschung auch mit VISTA nicht sein. Es ist ja nicht so das aufeinmal alles doppelt so groß wird. Bei Spielen kommen kaum int64 zum Einsatz, und die bischen pointer die da umhergeschoben werden, das sind sowenig das fällt kaum in's Gewicht.

[Dr. Chandra]

Unwarscheinlich, weil für die Sachen, die wir Hauptsächlich bzw. Hauptberuflich machen, ist mehr als genug Cache zur Verfügung. Und die neue 3D-Software bzw. Spiele wird ihre ganze Kraft aus dem 64bit Adressraum schröpfen. Unreal3 belegt jetzt bereits schon soviel Hauptspeicher, das die Adressen schon allein dafür ... da ist noch kein I/O Gerät mich eingerechnet ... knapp wird.

Ich hab selber WINx64 in Betrieb mit EMT64 und bin begeistert, wie responive so ein System doch sein kann. So Böse wird die Überraschung auch mit VISTA nicht sein. Es ist ja nicht so das aufeinmal alles doppelt so groß wird. Bei Spielen kommen kaum int64 zum Einsatz, und die bischen pointer die da umhergeschoben werden, das sind sowenig das fällt kaum in's Gewicht.
Aber wenn Microsoft ernst macht und Windows Vista wirklich zu 100% ein 64-Bit Betriebssystem ist, dann muß man doch damit rechnen, daß alle kleinen , popligen Hintergrundtasks plötzlich auch 64-Bit breit werden. Ich denke da zB. an so Sachen wie Timer, Scheduler, Firewalls, Virenkiller und die ungezählten anderen Services, die auf einem Windows-Rechner im Hintergrund rumkrebsen. Vielleicht haben sie es in Vista aber auch so gemacht, daß 64-Bit Funktionen nur bei Anfrage zur Verfügung stehen, so daß der Rechner eigentlich auch weiterhin im Kompatibiltätsmodus unterwegs ist. Manchmal habe ich jedenfalls diesen Verdacht, wenn ich mir die 64-Bit Edition von Windows XP so ansehe...

[del_4901]

Aber wenn Microsoft ernst macht und Windows Vista wirklich zu 100% ein 64-Bit Betriebssystem ist, dann muß man doch damit rechnen, daß alle kleinen , popligen Hintergrundtasks plötzlich auch 64-Bit breit werden. Ich denke da zB. an so Sachen wie Timer, Scheduler, Firewalls, Virenkiller und die ungezählten anderen Services, die auf einem Windows-Rechner im Hintergrund rumkrebsen. Vielleicht haben sie es in Vista aber auch so gemacht, daß 64-Bit Funktionen nur bei Anfrage zur Verfügung stehen, so daß der Rechner eigentlich auch weiterhin im Kompatibiltätsmodus unterwegs ist. Manchmal habe ich jedenfalls diesen Verdacht, wenn ich mir die 64-Bit Edition von Windows XP so ansehe...

Selbst dann wird der Cacheverbrauch nicht verdoppelt. Und mal unter uns ... nicht umsonnst haben aktuelle VISTA-ready CPUs bis zu 4MB Cache ... das reicht locker aus. Eher würde ich mir da Gedanken machen über den interen Bus vom K8 zwischen L1 und L2 Cache, der ist dann doch etwas schwach auf der Brust. Der Core2 hat solche Probleme nicht und der K8L soll auch an dieser Stelle verbessert werden.

[HOT]

Selbst dann wird der Cacheverbrauch nicht verdoppelt. Und mal unter uns ... nicht umsonnst haben aktuelle VISTA-ready CPUs bis zu 4MB Cache ... das reicht locker aus. Eher würde ich mir da Gedanken machen über den interen Bus vom K8 zwischen L1 und L2 Cache, der ist dann doch etwas schwach auf der Brust. Der Core2 hat solche Probleme nicht und der K8L soll auch an dieser Stelle verbessert werden.

Der Conroe kann unter 64Bit aber keine MakroOp-Fusion durchführen, ist also ebenfalls eingeschränkt. Was die Caches angeht, der kritische L1 ist bei allen CPUs weitaus gross genug, auf die L2 Grösse reagieren die CPUs sowieso unterschiedlich und auch der wird dicke ausreichen.
Zudem gewinnt der K8 durch 64Bit mehr als der Conroe.

[HOT]

Aber wenn Microsoft ernst macht und Windows Vista wirklich zu 100% ein 64-Bit Betriebssystem ist, dann muß man doch damit rechnen, daß alle kleinen , popligen Hintergrundtasks plötzlich auch 64-Bit breit werden. Ich denke da zB. an so Sachen wie Timer, Scheduler, Firewalls, Virenkiller und die ungezählten anderen Services, die auf einem Windows-Rechner im Hintergrund rumkrebsen. Vielleicht haben sie es in Vista aber auch so gemacht, daß 64-Bit Funktionen nur bei Anfrage zur Verfügung stehen, so daß der Rechner eigentlich auch weiterhin im Kompatibiltätsmodus unterwegs ist. Manchmal habe ich jedenfalls diesen Verdacht, wenn ich mir die 64-Bit Edition von Windows XP so ansehe...

Schonmal bei Win x64 in den Taskmanager geschaut? Da ist alles, was zum Windows gehört, 100% 64-bittig. Und es schränkt überhaupt nicht ein.