|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Ich benutze seit dem PII nur noch AMD. Zuerst nur wegen des Preises, doch mittlerweile wuerd ich mir keinen Intel Prozessor zulegen.
Spaetestens wenn Intel DRM einbaut, und AMD nicht, werden noch ein paar Kunden mehr abspringen.
Ausserdem muessen sowieso alle *nix Benutzer bis 2038 einen 64bit Prozessor haben. Sonst sind springt die Zeit zurueck nach 1970 :)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
carma, dann laeuft auch gerade der automatische kalender meiner uhr ab. vielleicht gibts dann ja ein pc-mit-passender-armband-uhr-bundle :)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich hab vor 'ner Weile mal ein statement von Knuth bzgl. der Weiterentwicklung über 64-bit hinaus gehört. (War in Zusammenhang mit seiner 64-bit Maschine MMIX.) Er meinte dazu, daß das bzgl. Maschinencode, Speicher(-adressierung), etc. wohl niemals kommen wird, weil das seiner Meinung nach wenig Sinn macht. Ein recht rigoroser Standpunkt. Aber zunächstmal sagt gerade Knuth sowas sicher nicht unüberlegt. Ich find das Ganze insbesondere deshalb interessant, weil normalerweise so Abschätzungen nach dem Motto "da ist Schluß" ziemlich in die Hose gehen.
(Das was Knuth ansprach hat sicher nix mit Graphikchips oder Vektorrechnern zu tun, die irgendwas mit riesigen spezialisierten Registern tun ... nur damit das nicht falsch verstanden wird. Es ging mehr um ein prinzipielles Design einer Maschine. Seiner Meinung nach (so, wie ich ihn verstanden hab) ist 64-bit dafür die richtige Wahl.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Na ja, selbst der uebergang von 32 auf 64 ist im Moment ja eher noch fragwuerdig. Wirkliche technische Gruende gibt es nicht (gerade das ist einer der Gruende warum ich AMDs Ansatz gute Chancen gebe). 4 GB, der Addressraum eines 32 Bit Prozessors ist immer noch mehr als ausreichend wenn es um einzelne Anwendungen geht (Sprich virtueller Addressraum einer Anwendung). Und einem System beizubringen einen Realen Adressraum von mehr als 4 GB zu unterstuetzen ist kein Problem, und erstrecht kein Grund auf Anwendungsebene neue Befehlssaetze zu basteln, und alles neu zu machen.
Bestes Beispiel sind Grossrechner, als Intel mit dem 286er kam waren da 32 Bit schon seit 20 Jahren Standard, und Speicher von 512 MB nicht mehr ungewoehnlich - bei einem Addressraum von 2 GB (Also ungefaer der Faktor 500 groesser als bei damaligen PCs :). 10 Jahre spaeter waren reale Hauptspeicher bei Grossrechnern standardmaessig 4-64 GB, und die Architektur immer noch 32 Bit - Einzig die Speicherverwaltung (MMU) kuemmerte sich um die groessere Addressbreite.
Ab von einigen wenigen Apps, welche dann halt zusaetzliche Funktionen der Speicherverwaltung nuetzen (Memory Pools etc.) kuemmert das keinen. Und die Einfuehrung einer 64 Bit Erweiterung durch IBM ist zwar cool, bislang aber eher nur zur Befriedigung des Spieltriebs wenn man eine neue Maschiene bekommt.
Aber kucken wir uns mal 64 Bi an: 64 Bit Addressraum, das heisst 16 Exabytes. Mal sehen, als Halbleiterspeicher braeuchten wir 16 Milliarden 1 GB Module - oder ein ungefaer 100x100x100 Meter grosses Gebbaeude dafuer eher doppelt so gross, weil man muss ja auch noch an die Module rankommen :) - witzlos - vom Stromverbrauch garnicht zu reden - und bei 100 meter Leutingslaenge zur CPU kommt da nicht mehr viel an geschwindigkeit raus ... ok, vir koennen es ja per Virtueller Addressierung machen - also eine 16 Exabyte grosse Datei... hmm das gibt ein nettes Raid Array. Bei angenommenen 160 MB pro 3,5" Pladde (immerhin 40 mal dichter als die RAMs) brauchen wir noch 100 Millionen Laufwerke - auch wieder ein Gebaude von 80x80x80 Metern (plus wartungswegen) - die noetige Energie und Abwaegme mal aussen vor - und die Leitungsprobleme bleiben auch.
Schmarrn was ich rechne ? Nun, wo Intel mit 32 Bit rauskam war ein System das die Grenzen ausnutzte bereits machbar - 4 GB als Platte war nur ein SCSI Rack mit sieben 600 MB Laufwerken. Durchaus zu kriegen, und bei DB Servern damals schon im Einsatz. Das als Masstab genommen, ist heute sowas wie 48 Laufwerke a 160 GB so die Grenze des sinvollen - oder halt gerade mal 43 Bit Addressbreite (8 Laufwerke brauchen gerade mal 40). Selbst wenn es genausoschnell weitergeht wie jetzt (kaum glaubhaft) sind die 64 Bit erst in 40-60 Jahren nutzbar.
Mal davon ab, die naechste Stufe waere wohl 128 oder? Nun, wo 64 nichtmal reicht um alle Atome in meiner badewanne zu zaehlen, 128 Bit sind wenn ich mich nicht taeusche schon genug um jedes Atom im Sonnensystem durchzunummerieren, und es bleibt noch Nummernraum uebrig.
Zu guter letzt sollte man nicht vergessen, dass eine Verdoppelung der Bitanzahl ist mehr als nur Verdoppelung der darstellbaren Zahl ... das leistet schon ein einzelnes Bit zusaetzlich. Dieser Fakt wird viel zu leicht uebersehen. Expotentielles Denken ist dem Alltegasleben nunmal fremd.
Nun, man kann ja immer noch sagen das es sich nicht um die Adressbreite, sondern um die Daten handelt, aber dann haben wir zum schon 64 Bit Prozessoren (Pentium Bus ist 64 Bit breit, und viele Datentypen und Rechenwerke auch) im Einsatz. Einzig das man dies zum Standard macht ist neu.
Soll es sein. Aber 128 ? was gibt es da was sinn macht ? Floatingpoint ist idR bereits seit den 8 Bit Prozessoren 64 Bit - eine Erweiterung auf 128 hat bisher niemand wirklich fuer noetig gehalten - und sonnst ?
Nee, ich denke das 64 ist wahrscheinlich dauerhaft das Ende. Und selbst das ist bereits uebertrieben, und nur dank Primitivbetriebssystemen ala Windows und Unix, deren Speichermanagement eher simpel ist, sinvoll ... und genau da liegt m.E. der einzige Grund warum eine 128 Bit Architektur je kommen koennte - eben weil diese Systeme bestimmte Hardwareannahmen so fest in Ihrer Philosopie verankert haben das ein Vorteil/Zwang entstehen kann - aber wie gesagt, erst weit nach meinem dahinscheiden.
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
naja...
mit 4GB ist der Speicher heutzutage schon recht knapp bemessen
und dagegen können auch die Krücken für PCs nicht so recht helfen,
die die Grenze auf 64GB hochschieben. Das erinnert mich ein wenig an die
Programmiertricks und Pointerakrobatik zur Umgehung der 64KB Grenze
(wegen 16-bit offset) damals unter DOS... zum Glück muß die Unterstützung heute nur noch einmal
- nämlich im OS implementiert werden und nicht mehr in jeder Anwendung.
Und natürlich ist der Speicher auch kleiner und billiger geworden, seit Bill
Gates behauptete, daß nie ein Mensch 640KB brauchen wird. Ich kann mir durchaus
Anwendungen vorstellen, die 100GB gebrauchen könnten.
Mit 64 Bit dagegen, könnte man Zeit endlich so darstellen, wie Java es schon
seit Jahren tut... auch auf 32-Bit-Systemen. In C heißt der entsprechende Typ
dann eben long long oder int64_t.
als Millionstel Sekunden seit dem 1.1.1900 (oder dem Jahre 0?)
damit würden dann vielleicht auch spezielle Time::HiRes perl module überflüssig.
Gleitkommazahlen werden übrigens schon lange
mit 80 Bit (64 Bit Mantisse, 16 Bit Exponent) dargestellt, siehe etwa beim Bericht
über den Pentum FPU-Bug
in Turbo Pascal nannte sich der Datentyp dazu extended und brauchte folgerichtig 10 Byte.
Daß exponentielle Entwicklungen dem Denken fremd sind, kann ich dagegen nur bestätigen.
"Wo doch schon RSA 512 Bit geknackt wurde... da kann doch 1024 nicht mehr lange
sicher sein" höre ich von gebildeten Leuten. Dabei verdoppelt sich mit etwa 10
zusätzlichen Schlüsselbits der Aufwand zum Faktorisieren. Das macht also etwa
2^50=~10^15 als Faktor zum Zeitbedarf für 512 Bits.
ich habe seit drei Jahren auch nur noch AMD Prozessoren in meinen Rechnern...
und solange sie funktionieren, performant sind und weiterentwickelt werden,
bleibt es auch dabei... (naja, vielleicht doch mal ein Transmeta zwischendurch;-)
Bernhard M.
_______
es gibt immer pros und cons
|
|
|
|
|
|
|
