Sinn und Unsinn von 64bit
- Ersteller PuckPoltergeist
- Erstellt am
PuckPoltergeist
Grand Admiral Special
Um das wieder aus den anderen Threads heraus zu halten, mach ich mal hier den neu auf. Vielleicht wird ja eine anständige Diskussion draus, und ich lerne auch noch was dazu. 
Zuerst nochmal ein paar Sachen, auf die ich dazu eingehen will:
Nun ja, inwiefern sind dort 64bit-GPRs wirksam? Dass Software auf AMD64 im allgemeinen schneller läuft als im 32bit-Modus, habe ich erwartet. Kann jetzt noch jemand erklären, inwiefern das mit den 64bit-Registern zu tun hat? Ich sehe da ehrlich gesagt keinen Grund, und einen Vergleich zu anderen 64bit-Architekturen habe ich leider auch nicht.
Meine Gegenfrage dazu: Warum sollte ich Mitte 2005 auf dem Desktop 64bit einsetzen? Brauche ich denn die Leistung, die mir AMD64 zusätzlich bringt, wirklich? Dazu stellt sich mir auch noch die Frage, ob ich die zusätzliche Leistung überhaupt bekomme? Ein beachtlicher Teil der heutigen Software ist stark auf x86 optimiert worden, so dass AMD64 dort erstmal kaum was bringt. Dazu muss ich noch mit einem deutlichen Mehrbedarf an RAM rechen, welcher durch die 64bit verursacht wird. Trage ich dem nicht Rechnung, wird der PC am Ende sogar langsamer, allen zusätzlichen Registern zum Trotz.
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=181589&highlight=amd64
64bit sind bei Servern oder Workstations schon lange Tagesordnung, ganz einfach, weil dort der Speicher benötigt wird. Wozu brauche ich das aber auf dem Desktop? Um ehrlich zu sein, ich bekomme Bauchkrämpfe bei dem Gedanken an Office-Programme oder Spiele, die 4GB RAM benötigen.
Sorry, aber dieses "Warum sollte Mitte 2005 noch irgendwer einen PC ohne 64-Bit-Technologie kaufen wollen?" ist für mich nur Säbelrasseln des Marketing.
Zuerst nochmal ein paar Sachen, auf die ich dazu eingehen will:
Nun ja, inwiefern sind dort 64bit-GPRs wirksam? Dass Software auf AMD64 im allgemeinen schneller läuft als im 32bit-Modus, habe ich erwartet. Kann jetzt noch jemand erklären, inwiefern das mit den 64bit-Registern zu tun hat? Ich sehe da ehrlich gesagt keinen Grund, und einen Vergleich zu anderen 64bit-Architekturen habe ich leider auch nicht.
Meine Gegenfrage dazu: Warum sollte ich Mitte 2005 auf dem Desktop 64bit einsetzen? Brauche ich denn die Leistung, die mir AMD64 zusätzlich bringt, wirklich? Dazu stellt sich mir auch noch die Frage, ob ich die zusätzliche Leistung überhaupt bekomme? Ein beachtlicher Teil der heutigen Software ist stark auf x86 optimiert worden, so dass AMD64 dort erstmal kaum was bringt. Dazu muss ich noch mit einem deutlichen Mehrbedarf an RAM rechen, welcher durch die 64bit verursacht wird. Trage ich dem nicht Rechnung, wird der PC am Ende sogar langsamer, allen zusätzlichen Registern zum Trotz.
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=181589&highlight=amd64
64bit sind bei Servern oder Workstations schon lange Tagesordnung, ganz einfach, weil dort der Speicher benötigt wird. Wozu brauche ich das aber auf dem Desktop? Um ehrlich zu sein, ich bekomme Bauchkrämpfe bei dem Gedanken an Office-Programme oder Spiele, die 4GB RAM benötigen.
Sorry, aber dieses "Warum sollte Mitte 2005 noch irgendwer einen PC ohne 64-Bit-Technologie kaufen wollen?" ist für mich nur Säbelrasseln des Marketing.
Zuletzt bearbeitet:
also zur sehr technisch gestellten frage kann ich leider nichts sagen.
aber:
es ist schließlich nur noch 6 monate hin das wird sich nicht mehr viel gegenüber der heutigen sitation tun.
windows x86-64 wird es vieleicht geben vieleicht auch nicht. und nur wenn intel ab jetzt alle cpus mit x86-64 ausliefert wird sich der anteil an diesen chips bis dahin noch signifikant erhöhen.
aber letztenendes werden auch in 6 monaten die "bremskötze" von x86-64 noch da sein. also zu wenig ausgereifte treiber und softwareunterstützung und mehr speicherbedarf.
ich schätze wenn man von "Anfang 2007" redet wird die aussage um einiges realistischer.
aber:
ist sicher nur marketing geblubber.
es ist schließlich nur noch 6 monate hin das wird sich nicht mehr viel gegenüber der heutigen sitation tun.
windows x86-64 wird es vieleicht geben vieleicht auch nicht. und nur wenn intel ab jetzt alle cpus mit x86-64 ausliefert wird sich der anteil an diesen chips bis dahin noch signifikant erhöhen.
aber letztenendes werden auch in 6 monaten die "bremskötze" von x86-64 noch da sein. also zu wenig ausgereifte treiber und softwareunterstützung und mehr speicherbedarf.
ich schätze wenn man von "Anfang 2007" redet wird die aussage um einiges realistischer.
rkinet
Grand Admiral Special
In der Liste sind PovRay und lame,
lt. anandtech-Benchmarks aber jetzt deutlich schneller unter 64 Bit.
Nein, für das Planet3DNow! Forum reicht ein Celeron 733 (übigens ne Super sparsame CPU), 256 MB, Win XP und DSL voll aus. Da gebe ich Dir recht, 64 Bit wäre da Blödsinn.
Nur, schon wer 500 Euro o.ä. für einen PC ausgiebt, wird nicht zu Ehren von IA32 auf 0-10% bis (Extremfall) +50% verzichten wollen. Der Celeron EM64T dürfte auch bei NORMA Weihnachten 2005 gut laufen, oder eben 2006. Die AMD eh ...
Nun, es gibt für diese These keinerlei Hinweise in aktuellen Benchmarks.
Schaut man sich x86-64 in Assembler an, ist das Gerücht bzgl. Mehrverbrauch nun wirklich albern.
Die Anzahl der CPU-Anweisung bei gleicher Programmieraufgabe wird geringer (die CPU muss weniger Befehle abarbeiten) und nimmt nur in Einzelfällen leicht an Byte zu (so. 5-10% = die CPU-Anweisungen werden länger).
Für 32 Bit Anwendungen bleibt es gleich, bzw. bei (zeitlich) intensiver Nutzung des OS/DirectX profitieren diese vom dort vorhandenen 64 Bit-Design.
Der 90nm Sempron hat einen K8-Kern, also auch x86-64 komplett in Hardware. (s. http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=192689)
Der Prescott = P4 und Celeron D ebenso.
Welche Gründe gibt es Mitte 2005 = 2 Jahre nach der 64 Bit Einführung für ein dauerhaftes Deaktivieren von x86-64
Gründe dafür, sieht man z.B. bei der aktuellen HP-Produktlinie.
Die gleiche PC-Reihe hat Sempron und Athlon XP heute.
Bald eben Sempron und Athlon 64 auf einer Plattform.
HP müßte ab Windows 64 XP jeweils zwei verscheiden Varianten vorhalten einmal 32 Bit Windows, einmal 64 Bit Windows.
Nur, damit der Athlon 64 der einzige mit 64 Bit bleibt ?
Der Joker könnte 'Dual-Core' sein, was dem Sempron 64 wieder in die zweite Reihe stellen würde.
Intel dürfte es ganauso sehen. Nur der P-M ist dann zunächst ohne 64 Bit, was allerdings geplant ab Q1'06 per 'Sossaman' ja enden soll.
Übrigens, auch Billy MS sprach von 'komplett 64 Bit' bei AMD bis Ende 2005 und später bei Intel.
Es geht also nur um einige Monate, die CEO Ruiz hier progressiver sich äußert.
Die aktuelle Roadmap von AMD gibts für Mitte 2005 locker her.
Letztlich entscheidet AMD und das AMD-Marketing, ob 64 Bit generell freigeschaltet wird etwa Mitte 2005 mit Erscheinen von Windows 64 XP.
Zuletzt bearbeitet:
I²K
Grand Admiral Special
, wenn man für den gleichen Preis einen PC mit 64-Bit-Technologie kaufe kann.
von folgendem finde ich leider nicht mehr die originalseite, aber es ist in diesem zusammenhang vielleicht ganz interessant:
rc4-amd64
RC4 implementation for AMD64
Marc Bevand
<bevand_m (at) epita.fr>
November 1, 2004
Download
rc4-amd64.html - Latest version of this paper
rc4-amd64.tar.bz2 - RC4 implementation for AMD64
Introduction
RC4, or Arcfour, is one of the fastest stream cipher available. Unfortunately none of the current implementations of this cipher achieve really good speeds on AMD64 processors. This is true when such processors run in 32-bit mode as well as 64-bit mode. The reason for this lack of speed depends on the mode:
32-bit mode. In this case RC4 implementations generally use standard i386 assembly language optimizations. The result is that RC4 is reasonably fast, but not enough, because it does not benefit of the 64-bit extensions.
64-bit mode. RC4 implementations are not usually optimized for this mode, so they generally use a standard C language implementation. The consequence of this is that RC4 is often even slower than in 32-bit mode.
This unhappy situation is partly due to the fact that the AMD64 architecture is very recent: AMD sold its first AMD64 processors in 2003, while i386 processors have been introduced in 1986. Generally speaking, most CPU-hungry i386 applications are already very well optimized, while much of the work remains to be done for AMD64. This paper demonstrates it is possible to achieve incredible speedups by writing AMD64 assembly code: throughput of the best currently known RC4 implementations has been surpassed by a factor of two.
Current implementations
OpenSSL offers some of the fastest implementations of RC4. Here is the throughput it can reach on recent i386 & AMD64 processors:
OpenSSL 0.9.7d (openssl speed rc4) Processor Throughput (MB/s)
Athlon XP 3000+ 2.2 GHz 198
Opteron 244 1.8 GHz (32-bit) 163
Opteron 244 1.8 GHz (64-bit) 135
Pentium 4 3.0 GHz 120
All of those processors run in 32-bit mode, except for the Opteron (marked in bold) which runs in 64-bit mode. As we can see, the Opteron is quite slow in 64-bit mode (135 MB/s), it is just a little faster than the Pentium 4 (120 MB/s -- Pentium 4 processors are known to be particularly slow in this benchmark). The Opteron is faster in 32-bit mode (163 MB/s), but not that much. As explained in the introduction, this 32-bit/64-bit difference is due to the fact that OpenSSL provides 2 different RC4 implementations, one is an optimized i386 assembly language version, and the other is a generic C language version.
Note: OpenSSL version 0.9.7d has been used on each processor. The GCC version used to compile OpenSSL really matters only for the Opteron in 64-bit mode because it is the only case where C code is being evaluated. This benchmark used GCC 3.4.2 with the options -march=opteron -O3 (basically the best that is available nowadays). Another important point to consider when compiling the C version of RC4 for OpenSSL is how the following macros has been defined, this benchmark used: -DRC4_INT='unsigned char' -DRC4_CHUNK='unsigned long' (default values defined in opensslconf.h).
New implementation
As presented above, such speeds are unacceptable. AMD64 processors are capable of much faster RC4 throughput. That's why I decided to write an AMD64 assembly language version of RC4: rc4-amd64. It can be obtained from the "Download" section at the top of this paper. Please note that I have placed this implementation in the public domain, so that it can be useful to the maximum number of people. Here is the throughput of rc4-amd64:
rc4-amd64 (rc4speed, provided with rc4-amd64) Processor Throughput (MB/s)
Opteron 244 1.8 GHz (64-bit) 319
In 64-bit mode, we now get 319 MB/s with rc4-amd64, instead of 135 MB/s with OpenSSL. rc4-amd64 is more than 2.3 times (or +130%) faster than OpenSSL. And, believe me or not, rc4-amd64 was a week-end hack: I did not spend more than 10 hours working on it. I hope this shows you what is possible when code is optimized for the AMD64 architecture.
Note: obviously, rc4-amd64 cannot be tested in 32-bit mode, since it has been designed for 64-bit mode.
Technical details
rc4-amd64 includes major hand optimizations. Here are the most effective ones:
Extra registers. A total of 11 general-purpose registers are used (%rax, %rbx, %rcx, %rdx, %rsi, %rdi, %rbp, %rsp, %r8, %r9, %r11). So, yes, extra registers defined by AMD64 (compared to i386) are useful. OpenSSL i386 implementation has to use the stack to store some datas.
64-bits registers. rc4-amd64 processes data by chunk of 8 bytes (same size than 64-bit registers), this method is particularly adapted to the 64-bit architecture.
"Manual" instruction scheduling. Although modern processors have out-of-order execution units, arranging instructions in order to try to break adjacent instructions interdependency greatly enhances performance. One particular instruction that proved to be extremely important to place is movb (%rbp,%rbx,8), %r8b (see the source code to locate it).
DirectPath Single instructions. The Software Optimization Guide for AMD Athlon 64 and AMD Opteron Processors describes 3 types of instructions: DirectPath Single, DirectPath Double and VectorPath instructions. DirectPath Single instructions are the most efficient ones since each of them decodes directly into 1 macro-op in hardware. rc4-amd64 tries to use exclusively such instructions.
Conclusion
rc4-amd64 has been presented, it offers 2.3 times the throughput of OpenSSL, which makes it, as of today, the world's fastest RC4 symmetric cipher implementation running on general purpose CPUs.
Many other areas could benefit from such AMD64 optimizations: data compression algorithms, checksumming algorithms, video encoding, etc. Unfortunately AMD64 is so young that it will take some time (1, 2, 4 years ?) before all the real-world applications run at full-speed on this evolutionary architecture.
rc4-amd64
RC4 implementation for AMD64
Marc Bevand
<bevand_m (at) epita.fr>
November 1, 2004
Download
rc4-amd64.html - Latest version of this paper
rc4-amd64.tar.bz2 - RC4 implementation for AMD64
Introduction
RC4, or Arcfour, is one of the fastest stream cipher available. Unfortunately none of the current implementations of this cipher achieve really good speeds on AMD64 processors. This is true when such processors run in 32-bit mode as well as 64-bit mode. The reason for this lack of speed depends on the mode:
32-bit mode. In this case RC4 implementations generally use standard i386 assembly language optimizations. The result is that RC4 is reasonably fast, but not enough, because it does not benefit of the 64-bit extensions.
64-bit mode. RC4 implementations are not usually optimized for this mode, so they generally use a standard C language implementation. The consequence of this is that RC4 is often even slower than in 32-bit mode.
This unhappy situation is partly due to the fact that the AMD64 architecture is very recent: AMD sold its first AMD64 processors in 2003, while i386 processors have been introduced in 1986. Generally speaking, most CPU-hungry i386 applications are already very well optimized, while much of the work remains to be done for AMD64. This paper demonstrates it is possible to achieve incredible speedups by writing AMD64 assembly code: throughput of the best currently known RC4 implementations has been surpassed by a factor of two.
Current implementations
OpenSSL offers some of the fastest implementations of RC4. Here is the throughput it can reach on recent i386 & AMD64 processors:
OpenSSL 0.9.7d (openssl speed rc4) Processor Throughput (MB/s)
Athlon XP 3000+ 2.2 GHz 198
Opteron 244 1.8 GHz (32-bit) 163
Opteron 244 1.8 GHz (64-bit) 135
Pentium 4 3.0 GHz 120
All of those processors run in 32-bit mode, except for the Opteron (marked in bold) which runs in 64-bit mode. As we can see, the Opteron is quite slow in 64-bit mode (135 MB/s), it is just a little faster than the Pentium 4 (120 MB/s -- Pentium 4 processors are known to be particularly slow in this benchmark). The Opteron is faster in 32-bit mode (163 MB/s), but not that much. As explained in the introduction, this 32-bit/64-bit difference is due to the fact that OpenSSL provides 2 different RC4 implementations, one is an optimized i386 assembly language version, and the other is a generic C language version.
Note: OpenSSL version 0.9.7d has been used on each processor. The GCC version used to compile OpenSSL really matters only for the Opteron in 64-bit mode because it is the only case where C code is being evaluated. This benchmark used GCC 3.4.2 with the options -march=opteron -O3 (basically the best that is available nowadays). Another important point to consider when compiling the C version of RC4 for OpenSSL is how the following macros has been defined, this benchmark used: -DRC4_INT='unsigned char' -DRC4_CHUNK='unsigned long' (default values defined in opensslconf.h).
New implementation
As presented above, such speeds are unacceptable. AMD64 processors are capable of much faster RC4 throughput. That's why I decided to write an AMD64 assembly language version of RC4: rc4-amd64. It can be obtained from the "Download" section at the top of this paper. Please note that I have placed this implementation in the public domain, so that it can be useful to the maximum number of people. Here is the throughput of rc4-amd64:
rc4-amd64 (rc4speed, provided with rc4-amd64) Processor Throughput (MB/s)
Opteron 244 1.8 GHz (64-bit) 319
In 64-bit mode, we now get 319 MB/s with rc4-amd64, instead of 135 MB/s with OpenSSL. rc4-amd64 is more than 2.3 times (or +130%) faster than OpenSSL. And, believe me or not, rc4-amd64 was a week-end hack: I did not spend more than 10 hours working on it. I hope this shows you what is possible when code is optimized for the AMD64 architecture.
Note: obviously, rc4-amd64 cannot be tested in 32-bit mode, since it has been designed for 64-bit mode.
Technical details
rc4-amd64 includes major hand optimizations. Here are the most effective ones:
Extra registers. A total of 11 general-purpose registers are used (%rax, %rbx, %rcx, %rdx, %rsi, %rdi, %rbp, %rsp, %r8, %r9, %r11). So, yes, extra registers defined by AMD64 (compared to i386) are useful. OpenSSL i386 implementation has to use the stack to store some datas.
64-bits registers. rc4-amd64 processes data by chunk of 8 bytes (same size than 64-bit registers), this method is particularly adapted to the 64-bit architecture.
"Manual" instruction scheduling. Although modern processors have out-of-order execution units, arranging instructions in order to try to break adjacent instructions interdependency greatly enhances performance. One particular instruction that proved to be extremely important to place is movb (%rbp,%rbx,8), %r8b (see the source code to locate it).
DirectPath Single instructions. The Software Optimization Guide for AMD Athlon 64 and AMD Opteron Processors describes 3 types of instructions: DirectPath Single, DirectPath Double and VectorPath instructions. DirectPath Single instructions are the most efficient ones since each of them decodes directly into 1 macro-op in hardware. rc4-amd64 tries to use exclusively such instructions.
Conclusion
rc4-amd64 has been presented, it offers 2.3 times the throughput of OpenSSL, which makes it, as of today, the world's fastest RC4 symmetric cipher implementation running on general purpose CPUs.
Many other areas could benefit from such AMD64 optimizations: data compression algorithms, checksumming algorithms, video encoding, etc. Unfortunately AMD64 is so young that it will take some time (1, 2, 4 years ?) before all the real-world applications run at full-speed on this evolutionary architecture.
und immer noch imponierend finde ich ja folgende benches:
http://www.pcstats.com/articleview.cfm?articleid=1665&page=6
http://www.pcstats.com/articleview.cfm?articleid=1665&page=8
ich erwarte, daß nichts besser wird, aber vieles anders (spd 1998 )...ne, im ernst: ich erwarte und erhoffe, daß gerade in dem bereich, in dem intel noch so dominiert - encoding - ein leistungszuwachs möglich ist. bei divx scheint dies ja auch zu stimmen (siehe obersten link).
http://www.pcstats.com/articleview.cfm?articleid=1665&page=6
http://www.pcstats.com/articleview.cfm?articleid=1665&page=8
ich erwarte, daß nichts besser wird, aber vieles anders (spd 1998 )...ne, im ernst: ich erwarte und erhoffe, daß gerade in dem bereich, in dem intel noch so dominiert - encoding - ein leistungszuwachs möglich ist. bei divx scheint dies ja auch zu stimmen (siehe obersten link).
Zuletzt bearbeitet:
rkinet
Grand Admiral Special
http://66.102.9.104/search?q=cache:...amd64.html+RC4+implementation+for+AMD64&hl=de
ok, nur im Google 32 Cache, aber etwas besser lesbar.
(original Link geht nicht mehr.)
Also: x86-64 ist eine schöne Architektur, der noch ausgereiftere Compiler benötigt.
---------
http://anandtech.com/cpuchipsets/showdoc.aspx?i=2256
Intel ab 3,0 GHz/ 2M in 64 Bit in wenigen Wochen
Intel dürfte bei der Einführung einfach statt Preisrücknahme
2M/EM64T statt 1M liefern,
also dann 64 Bit bei Intel in wenigen Wochen ab ca. 165 EURO / $218
ok, nur im Google 32 Cache, aber etwas besser lesbar.
(original Link geht nicht mehr.)
Also: x86-64 ist eine schöne Architektur, der noch ausgereiftere Compiler benötigt.
---------
http://anandtech.com/cpuchipsets/showdoc.aspx?i=2256
Intel ab 3,0 GHz/ 2M in 64 Bit in wenigen Wochen
Intel dürfte bei der Einführung einfach statt Preisrücknahme
2M/EM64T statt 1M liefern,
also dann 64 Bit bei Intel in wenigen Wochen ab ca. 165 EURO / $218
Zuletzt bearbeitet:
ach so, und dann gab es damals noch den link von mocad zu einem vergleich em64t vs. amd64. wegen des dummen threadtitels ist der beitrag aber ein wenig untergegangen glaube ich, weil es kaum reaktionen gab: ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=189051&highlight=linux
aber der link war umso interessanter
http://www.linuxhardware.org/article.pl?sid=04/10/27/204232&mode=thread
edit: jetzt, wo ich mir das nochmals betrachte, muß ich sagen: lesepflicht, wirklich echt interessant
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=189051&highlight=linux
aber der link war umso interessanter
http://www.linuxhardware.org/article.pl?sid=04/10/27/204232&mode=thread
edit: jetzt, wo ich mir das nochmals betrachte, muß ich sagen: lesepflicht, wirklich echt interessant
PuckPoltergeist
Grand Admiral Special
Wenn dazu auch noch aufgeschlüsselt worden wäre, wo und mit welchen flags die jeweiligen Softwareversionen gebaut wurden, ließe sich das vielleicht auch erklären. Wie meine Ergebnisse zustande gekommen sind, kann man ja nachlesen.
Nun ja, ich nehm die Mehrleistung mit, und muss dafür den Speicher verdoppeln. Sehe ich echt keinen Sinn drinn. 64bit ist gerade so eine Modeerscheinung wie Hyperthreading, mit der die Leute wuschig gemacht werden.
Ich kann zwar nicht mit Assembler-Code aufwarten, aber die Werte der laufenden Programme aus meinem Test sagen zumindest für mich schon einiges aus.
Also das mußt du mir jetzt erklären. Diese Aussage hat hinten und vorne keinen Halt.
Und wie 32bit-Anwendungen beim Speicherverbrauch vom OS profitieren verstehe ich auch nicht. Bitte um Erklärung.
Der 90nm Sempron hat einen K8-Kern, also auch x86-64 komplett in Hardware. (s. http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=192689)
Der Prescott = P4 und Celeron D ebenso.
Welche Gründe gibt es Mitte 2005 = 2 Jahre nach der 64 Bit Einführung für ein dauerhaftes Deaktivieren von x86-64
Gründe dafür, sieht man z.B. bei der aktuellen HP-Produktlinie.
Die gleiche PC-Reihe hat Sempron und Athlon XP heute.
Bald eben Sempron und Athlon 64 auf einer Plattform.
HP müßte ab Windows 64 XP jeweils zwei verscheiden Varianten vorhalten einmal 32 Bit Windows, einmal 64 Bit Windows.
Nur, damit der Athlon 64 der einzige mit 64 Bit bleibt ?
Sorry, hier komme ich nicht mehr mit.
Und hier schon gar nicht mehr. Inwiefern macht das 64bit auf dem Desktop sinnvoll?
dann ist doch das fazit für all diejenigen, die zur zeit mit einem athlon xp ab reichlich 2000 mhz realtakt zufriedenstellend schnell arbeiten: es ist unfug, jetzt auf 64 bit prozessoren aufzurüsten!?
denn: zu dem zeitpunkt, wenn die 64 bit anwendungen verfügbar sind, werden die jetzt aktuellen winchesters genauso giga-out sein, wie es derzeit die athlon xp-prozessoren sind.
denn dann, wenn man die 64 bit anwendungen real installiert hat, gibt es dual-core und andere, hoffentlich stromsparendere leckereien zum preis der derzeitigen winchesters.
es sei denn, man ist professioneller lame-encoder. bin ich z.b. aber nicht. ich lese genüsslich eure beiträge während meine non-64-bit-2100 mhz im hintergrund am anschlag mp3s erstellen.
wieviele stunden pro monat erstellt ihr so mp3s?
was der 3500 winchester wohl kosten wird, wenn das 64-bit-lame tatsächlich verfügbar ist? also, wieviel geld hätte ich bis dahin vernichtet, wenn ich heute schon einen kaufen würde?
fragen über fragen.
gruß, zoller
p.s. ich gönnen euch eure tollen winnis! ehrlich gesagt, hätte ich auch gerne einen.
denn: zu dem zeitpunkt, wenn die 64 bit anwendungen verfügbar sind, werden die jetzt aktuellen winchesters genauso giga-out sein, wie es derzeit die athlon xp-prozessoren sind.
denn dann, wenn man die 64 bit anwendungen real installiert hat, gibt es dual-core und andere, hoffentlich stromsparendere leckereien zum preis der derzeitigen winchesters.
es sei denn, man ist professioneller lame-encoder. bin ich z.b. aber nicht. ich lese genüsslich eure beiträge während meine non-64-bit-2100 mhz im hintergrund am anschlag mp3s erstellen.
wieviele stunden pro monat erstellt ihr so mp3s?
was der 3500 winchester wohl kosten wird, wenn das 64-bit-lame tatsächlich verfügbar ist? also, wieviel geld hätte ich bis dahin vernichtet, wenn ich heute schon einen kaufen würde?
fragen über fragen.
gruß, zoller
p.s. ich gönnen euch eure tollen winnis! ehrlich gesagt, hätte ich auch gerne einen.
rkinet
Grand Admiral Special
http://anandtech.com/cpuchipsets/showdoc.aspx?i=2256
Intel goes EM64T - Q1'05 - ab 3,0 GHz - Pentium 630 - wohl ab 165 EUR
Da freu ich mich mal für die Intel-Kundschaft.
Ab Q1'05 serienmässig mit 2M und 64 Bit, was wohl dafür sorgt, daß statt Preissenkung (typ. Mitte Februar'05) eben der Pentium 630 um Preis der heutigen Pentium 530J kommt = $218 Liste.
Der Winnie ist doch schon fast tot - s. aktuelle Roadmap. 8)
Er war eine solide Konstruktion und im Prinzip eine Mobil-CPU, die recht lahm war.
Aber als 'gestutzter' Palermo wird er uns erhalten bleiben, vielleicht auch absehbar bald in 64 Bit.
Intel goes EM64T - Q1'05 - ab 3,0 GHz - Pentium 630 - wohl ab 165 EUR
Da freu ich mich mal für die Intel-Kundschaft.
Ab Q1'05 serienmässig mit 2M und 64 Bit, was wohl dafür sorgt, daß statt Preissenkung (typ. Mitte Februar'05) eben der Pentium 630 um Preis der heutigen Pentium 530J kommt = $218 Liste.
Der Winnie ist doch schon fast tot - s. aktuelle Roadmap. 8)
Er war eine solide Konstruktion und im Prinzip eine Mobil-CPU, die recht lahm war.
Aber als 'gestutzter' Palermo wird er uns erhalten bleiben, vielleicht auch absehbar bald in 64 Bit.
@puckpoltergeist
also bei dem linux test hat povray unter em64t ebenfalls heftig zugelegt...
und von welchen größenordnungen sprichst du, wenn du meinst, 64bit code sei soviel größer? amd spricht doch m.w. so von 10-20% code-vergrößerung. ausnahmen mag es geben. kannst du das bitte nochmals näher ausführen?
also bei dem linux test hat povray unter em64t ebenfalls heftig zugelegt...
und von welchen größenordnungen sprichst du, wenn du meinst, 64bit code sei soviel größer? amd spricht doch m.w. so von 10-20% code-vergrößerung. ausnahmen mag es geben. kannst du das bitte nochmals näher ausführen?
I²K
Grand Admiral Special
Das sind aber die Pavilions oder wie die heissen. Die kommen nicht auf hohe Stückzahlen.
In der Businessreihe findet sich derzeit nur der 2800+ und der 3200+ (oder 3000+).
PuckPoltergeist
Grand Admiral Special
Das ist aber weniger Fazit aus diesem Thread, sondern gilt allgemein. Man sollte Hardware nur so kaufen, wie sie auch benötigt wird. Heute loszugehen und zu sagen, ich kaufe jetzt einen Rechner, der für die nächsten X Jahre reichen soll, haut meist eh nicht hin. Außerdem verbrennt man verdammt viel Geld, wenn man der oberen Leistungsgrenze kauft.
Wenn man jetzt natürlich aufrüsten will oder muss, kann man schlecht sagen, dass es Unfug ist, einen 64bit-Prozessor zu kaufen. AMD läßt einem da ja nicht unbedingt die Wahl. Die Frage ist dann nur, ob ich den auch im 64bit-Modus betreiben will (und den Rechner dann auch dementsprechend ausstatte), oder die 64bit halt nur auf dem Gehäuse hübsch aussehen sollen.
PuckPoltergeist
Grand Admiral Special
Nun ja, unter welchen Rahmenbedingungen? Ich kann halt nur sagen, wie es bei mir ausgesehen hat. Wenn ich die Zeit habe, werde ich die Tests die Tage mal wiederholen, nachdem ich jetzt den Speicher aufgerüstet habe.
Schau mal in den Link meines ersten Postings hier. Über den Daumen gepeilt verdoppelt sich der Speicherverbrauch durch den long-mode. Manche Programme (firefox z.B.) genehmigen sich bei 64bit auch schon 5x so viel Speicher, wie in der 32bit-Version.
Zuletzt bearbeitet:
rkinet
Grand Admiral Special
aha 2* 32 = 160 ...
Wer was mit welchem Compiler wie compiliert hat als Software-Beta oder erste Realease muß man nun wirklich nicht zerpflücken.
Und die 2M-L2 hat der Pentium 630 auch nicht wegen EM64T.
Der x64 Befehlsatz bewirkt bei einem einigermassen ordentlich arbeitenden Compiler kaum Codezuwachs, da in einer Software selten absolute Adresse zu laden sind. Schon eher Daten, nur die sind im Standard als 32 Bit definiert, mit Präfix dann die 64 Bit.
Die 5-fach sind eben misserabel compiliert.
Wie schon aufgeführt - Intel goes EM64T schon ab 3 GHz und Q1'05.
Windows 64 XP wird also nicht alleine bei AMD-CPUs zum Einsatz kommen,
sondern auch die Mittelklasse von Intel.
Mal abschätzen 2005 für 64 Bit:
AMD = ca. 10 Mill. St. A64 zzgl. wahrscheinlich Semprone
Intel = 25-40 Mill. St. EM64T
Da werden die Compilerbauer noch mal ein Entwicklungsbriket nachlegen
und ihre Designs optimieren.
@Puck, Du seltest vielleicht bald Mahnwachen vor Media Märkten
oder bei ALDI aufstellen und die Leute auffordern ihr 64 Bit Windows inside gegen ein 32 Bit auszutauschen.
Achso, gleich über die gefährlichen Nebenwirkungen von 'Saver SP2 Internet' informieren und sie auffordern, Firewall und Virenscanner zu deaktivieren. Nur Keuschheit im Internet verhindert Befall, nicht satanische Beigaben von Microsoft - ahmen !
@Puck, wie wärs mit einem Beitrag zum Mehrverbrauch von Energie durch 64 Bit ?
Sind bestimmt kW mehr durch 64 Bit, wenn allein der Byteverbrauch sich schon verfünffacht.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Offenbar bist du nicht an einer ernsthaften Diskussion interessiert, sondern willst nur flamen. Wenn doch, hättest du die Beiträge in meinem Link zumindest angesehen, und wärst auch den Beitrag von Dresdenboy gestolpert:
Du schreist doch immer nach den entsprechenden Links. Jetzt hab ich ihn dir schon direkt vor die Füße geworfen. Mehr fällt mir dann echt nicht mehr ein.
Shdow
Vice Admiral Special
natürlich ist 64 bit ersteinmal viel marketing aber es würde sowieso kommen müssen früher oder später und wenn die programme optimiert sind und das 5% mehr bringt ist ja super.
effektiv entstehen durch die 64 bit dem endkunden ja keine mehrkosten.
ich finde es ja lustig wie rkinet 50 prozent mehr leistung da rauspopeln will *g* aber so isser nun mal.. also rkinet auf gehts programmier uns mal etwas was mit dem selben code 50 prozent schneller läuft unter 64bit als 32bit ich leg hier schonmal nen 10er hin und wette du schaffst das nicht....
PS: ich glaube nicht das Puck beim speicherverbrauch die HDD gemeint hat!
effektiv entstehen durch die 64 bit dem endkunden ja keine mehrkosten.
ich finde es ja lustig wie rkinet 50 prozent mehr leistung da rauspopeln will *g* aber so isser nun mal.. also rkinet auf gehts programmier uns mal etwas was mit dem selben code 50 prozent schneller läuft unter 64bit als 32bit ich leg hier schonmal nen 10er hin und wette du schaffst das nicht....
PS: ich glaube nicht das Puck beim speicherverbrauch die HDD gemeint hat!
rkinet
Grand Admiral Special
64 Bit Panik wegen AMDs - Roadmap und Intels Pentium 630 ff ?
a) Softwareentwickler nehmen für ihr Produkt die richtigen Flags - die haben ja den Überblick, was sie programmiert haben
b) 'Running gag' vom verdoppelten Speicherbedarf. Man sieht, Du hast viel Ahnung von IT-Technik auf der oberen Ebene, aber (fast) Null bzgl. Assembler und dem realen Code, dem eine CPU erhält. Der ist und bleibt bei x86-64 äußerst kompakt und kann sogar unter der IA32 Version liegen, da einiges überflüssige entfällt.
c) Speicherverbrauch des OS = 'runnig gag'
Die Diskussion hatten wir schon einmal, daher ganz einfach:
Eine 32 Bit Anwendung übergibt an das OS oder DirectX Aufgaben. Ab dem Übergabepunkt werden die in 64 Bit und per 64 Bit Treiber abgearbeitet. Läuft Software bevorzugt durch Aufruf von solchen Routinen, wird sie eben schneller.
Die DirectX 64 und 64 Bit Hardwaretreiber wirken für ein 32 Bit Spiel wie ein Treiberupdate zzgl. leichtes OC der GraKa (vgl. nvidia-Bench von oben).
x86-64 ist ein Super-Design, daß sich schon in vielen Benchmarks auch so zeigt.
IA32 kannst Du in die Tonne schmeißen - war eine Zumutung für jede moderene CPU Silicium-Quälerei.
Allein, daß die schon recht gute Hardware in den CPUs nicht mehr durch den Dummfug IA32 gebremst wird, ist schon ein schöner Fortschritt. Der Normal-User bekommt nur kostenlos etwas mehr Speed --- wie immer bei Einführung neuer Techniken.
Ok, es wird jetzt keine Software-Schwemme für 64 Bit geben. Nur der Anwender bekommt für Teilaufgaben (wie encoding) deutlich mehr Leistung von seiner CPU geliefert, die alte Software wird meßbar oder leicht fühlbar zulegen.
PuckPoltergeist
Grand Admiral Special
Doch, durch die Notwendigkeit, mehr RAM für die gleichen Aufgaben zu installieren. Unter 32bit bin ich gut mit 512MB RAM ausgekommen, bei 64bit haben die ganz einfach nicht mehr gereicht. Du glaubst gar nicht, wie lahm Linux werden kann, wenn dem der Speicher ausgeht.
(Das ist auch offiziell bekannt und aus meiner Sicht ein wirklicher Kritikpunkt an diesem OS)
Es wäre da wesentlich schöner gewesen, wenn AMD den Hammer ähnlich MIPS designed hätte, so dass 32bit und 64bit Modus bis auf die Registerbreite vollkommen äquivalent sind. Inwiefern das ohne Bruch der Abwärtskompatibilität zu x86 überhaupt möglich gewesenwäre weiß ich jetzt nicht, aber so setzt AMD einen die Pistole auf die Brust.
PuckPoltergeist
Grand Admiral Special
Sprichst du hier von den Benchmarks? Was haben die Entwickler damit zu tun? Was haben die Leute von Anandtech mit der Entwicklung von lame oder POVRay zu tun?
Nun, dann erklär es mir doch! Wieso verringern sich bei AMD64 die Assembleranweisungen gegenüber IA32? Inwiefern wirkt sich das auf den Speicherverbrauch der laufenden Programme aus?
Und was hat das mit dem Speicherverbrauch der 32bit-Applikation zu tun?
AMD64 ist mit Sicherheit eine deutliche Verbesserung gegenüber IA32, nur gibt es deutlich bessere. Besonders im Bezug auf die Programmierung ist diese Architektur immer noch reichlich misserabel. Das hat aber alles nichts mit der Frage nach der Notwendigkeit von 64bit auf dem Desktop zu tun.
rkinet
Grand Admiral Special
Ich habe x86-64 und x86 Assembler-Code aus gleichem Sourcecode gesehen.
Und mir den Instruktionssatz angesehen.
Da ist nichts drin, was den Code aufbläht oder die CPU ausbremst,
wenn z.B. eben 64 Bit läuft, aber nur 8 Bit bearbeitet wird.
Ihr verbeißt euch in Beta-Software und seht Probleme, die es beim x86-64 Design prinzipbedingt nicht gibt.
Es gibt sogar Belege, daß Compiler ziemlich abenteuerlich den IA32-Code auf x86-64 verschlimmbessern.
Daher lehne ich das Wort 'flamen' ab.
Das herumdeuten an Benchmarks ist Esotherik und völlig unwissenschaftlich.
Schaut euch die Fachinfos zum x86-64 Code an - die Benchmarks könnt ihr euch schenken, reine Zeitverschwendung an sekundären Informationsquellen.
UND - der 64 Bit Desktop-Zug ist endgültig abgefahren !
Wir werden in wenigen Wochen die 64 Bit Intel-CPUs breit sehen (Intel verdient einfach mehr an diesen CPUs und sie haben auch begrenzte Stromsparfeatures) und Microsoft dürften seinen Win64 XP - Fahrplan synchron mit Intel laufen lassen.
Linux aktivier sogar automatisch 64 Bit, so mein Wissen dazu. Da wird keine 64 Bit CPU auf 32 Bit geschaltet, weil es keinerlei praktische Nachteile durch die 64 Bit gibt.
AMD hat nur Präfixe (REX) an Stellen vorgesehen, wenn Anweisungen verwendet werden, die nicht so in IA32 vorhanden sind.
Absolut gleichen Bytebedaf haben:
- Basis ALU Operationen (Boolean, ADD, SUB, ...)
- Relative Sprünge (praktisch alle üblichen)
- Indizierte Lade-/Speicheroperation
- Ladeoperationen von 32 Bit Konstanten (viel häufiger, als 64 Bit)
Erhöhten Bedarf haben:
- absolute Sprünge (kaum vorzufinden)
- absolute Ladevorgänge von Daten (kann PC-relativ ersetzt weredn)
- Unterprogramme (64 statt 32 Bit Adressen)
- PC-relative Sprünge (32 statt 16 Bit Adressen)
- Präfix 'REX'
- Taskwechsel
Verminderten Bedarf haben:
- wenn Daten nicht auf den Stack oder Speicher müssen, sondern in die Register passen
- einige Adressierungen auf lokale Datentabellen
Wird ungünstig ohne die neuen 'relativen' Befehle compiliert, steigt der Speichebedarf etwas an. Wird die Architektur richtig genutzt, gibt es leichte Schwankungen nach mehr oder weniger Byte. Ursache ist die wenigen CPU-Befehle, die wirklich durch 64 Bit direkt betroffen sind. Es ist ein Märchen und wilder Aberglaube, daß eine 64 Bit CPU permanent Anweisungen in 64 Bit von außen benötigt. Die 64 Bit spielen sich weitgehend innerhalb des Cores ab ohne Einfluß auf den Code der CPU.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Es gibt einen Unterschied zwischen Code sehen, und verstehen, was dieser Code macht. Letzteres spreche ich dir nach dem Blödsinn, den du hier verzapfst ab.
Ah ja, du weißt darüber also besser bescheid, als z.B. die Compilerentwickler.
Einerseits zeigst du immer wieder auf, wie toll Linux unter AMD64 doch ist, und was es nicht alles kann, und auf der anderen Seite ist es auf einmal alles wieder Beta-Software?
Du schmeißt die ganze Zeit mit Benchmarks (und Roadmaps) um dich, und sobald andere darauf verweisen, was deinen Thesen widerspricht, ist es Esoterik? Als ich damals versucht habe darzulegen, wieso der reine Umstieg auf 64bit keinen Geschwindigkeitsvorteil bringt, und dazu keine Benchmarks parat hatte, war das sowas von unseriös. Jetzt propagierst du das selber.
Ein klein wenig schizophren ist schon, oder?
Hm, vielleicht wäre für dich mal ein Streitgespräch mit Linuxnutzern oder Linuxentwicklern sinnvoll? Obwohl, gerade dieser Thread zeigt ja sehr deutlich, dass das offenbar sinnlos ist. Ich bezweifle, dass da noch mehr Linuxer helfen können.
PuckPoltergeist
Grand Admiral Special
Nun, das hatte ich ja auch schon angesprochen. Im Moment gibt es noch extrem viel Software, die wenn überhaupt auf IA32 (hand)optimiert wurde. Gegen die schneidet dann ein AMD64-Äquivalent bei weitem nicht so gut ab. Da ist durchaus noch viel Luft. Aber das ist generell so. Will man ein Maximum an Performance haben, muss man handoptimieren, insbesondere bei CISC-Architekturen.
Ähnliche Themen
