nicht angemeldet
JürgenB
Der Martin
Der Martin
Der Martin
dedlfix
dedlfix
Der Martin
dedlfix
dedlfix
dedlfix
liebe Söhne und Töchter, die Ihr da schlafwandelt im Tal des Unwissens, ich hab mal ne Frage:
Stimmt es, daß ein 64-Bit Windows für die gleiche Leistung doppelt soviel Speicher braucht, wie ein 32-Bit System? Und wenn: was soll das dann bringen? Wo ist der Zweck des breiteren Busses? Sollte man dann nicht bei 32-Bit bleiben?
Stimmt es, daß ein 64-Bit Windows für die gleiche Leistung doppelt soviel Speicher braucht, wie ein 32-Bit System? Und wenn: was soll das dann bringen? Wo ist der Zweck des breiteren Busses? Sollte man dann nicht bei 32-Bit bleiben?
Na klar, ein doppelt so breiter Bus braucht doppelt so breite Straßen und doppelt so breite Parkplätze. Aus dem Grund baut man doppelte Busse nicht in die Breite, sondern in die Höhe.
Das ist auch mit Windows so. Du kommst mit dem bisherigen Speicher aus und dennoch kann der Doppel-Bus mehr Daten in derselben Zeit befördern.
Gast.
ich verstehe immer noch nicht. Konkretes Beispiel: 32-Bit, 2GB Speicher (bei mir der Fall). Der kann jetzt pro Sekunde 1,8 GHz mal 32 Bit verarbeiten. Ein System mit 64 Bit könnte in der selben Sekunde 1,8 GHz mal 64 Bit verarbeiten. Selbt angenommen, es bräuchte dazu 4 GB Speicher. Ist die Leistung dann nicht die doppelte?
Und nochmal: was soll dann 64-Bit, wenn meine Rechnung nicht stimmt? Warum kehren wir nicht zu 8 Bit zurück?
Hallo,
breitere Busse haben zwei Vorteile:
1. Doppelte Datenrate
2. Größerer Adressraum
Meiner Meinung nach lohnt sich ein 64Bit-System erst bei einem Hauptspeicher größer 4 GByte.
Gruß, Jürgen
- Doppelte Datenrate
Jein :) wenn du von einem idealen 64-Bit-System ausgehest - der AMD64-Befehlssatz hat z.B. 64 Bit Register aber nur einen 48 Bit Adressbus (zuvor gar nur 40), dasselbe gilt für EM64T (bzw. Intel 64).
- Größerer Adressraum
Einen größeren direkt ansprechbaren Addressraum - aber auch hier ist bei aktuellen Implementierungen im Consumer-Bereich nicht 64 = 2x32.
Meiner Meinung nach lohnt sich ein 64Bit-System erst bei einem Hauptspeicher größer 4 GByte.
Kommt drauf an, was du machst :) aber der Preis sollte nicht der Faktor sein, 1 GiB kostet derzeit < 10 Euro.
Moin!
Meiner Meinung nach lohnt sich ein 64Bit-System erst bei einem Hauptspeicher größer 4 GByte.
32-Bit-Windows kann nur grob 3 GB adressieren, das eine GB bis 4 liegt im Prinzip nutzlos brach. Schon in diesem Szenario kriegt man mit 64Bit-OS mehr RAM.
Im übrigen lohnt es sich nicht, weniger als 8 GB zu installieren, und es lohnt nicht, noch ein 32-Bit-OS zu installieren.
Hinsichtlich der weiteren Software aber möglicherweise schon. Eine Textverarbeitung wird vermutlich selten mehr als 2 GB RAM benötigen, im Gegenzug profitiert man aber von den etwas schlankeren Programmdateien, die sich auch im Speicher nicht ganz so ausbreiten.
64-Bit-OS und 32-Bit-Usersoftware (sofern ohne riesigen RAM-Bedarf - Bildbearbeitung und Videoschnitt sind also explizit ausgenommen) ergänzen sich wunderbar.
- Sven Rautenberg
Hallo,
32-Bit-Windows kann nur grob 3 GB adressieren, das eine GB bis 4 liegt im Prinzip nutzlos brach.
das stimmt so nicht; ein 32bit-Windows kann 4GB adressieren. In der Standardkonfiguration ist aber von diesem Adressraum die Hälfte (also 2GB) für das OS selbst reserviert, es bleiben also 2GB für Anwendungen. Die Grenze lässt sich von 2:2 auf 3:1 zugunsten des Anwender-Speicherbereichs ändern, außerdem gilt durch geschicktes Speichermanagement (PAE) die 3GB-Grenze für jede Anwendung separat. Ein 32bit-Windows kann also -passende Hardware vorausgesetzt- bis zu 3GB pro Applikation verwalten.
Nach allem, was ich bisher gehört habe, soll PAE aber erst ab Windows 7 zufriedenstellend funktionieren; ein 64bit-XP ist/war also eher ein Problemkandidat als ein Fortschritt.
Im übrigen lohnt es sich nicht, weniger als 8 GB zu installieren, und es lohnt nicht, noch ein 32-Bit-OS zu installieren.
Das ist Ansichtssache, wir hatten das Thema erst kürzlich. PCs mit 32bit-Architektur sind sehr preiswert geworden (teils unter 200EU$), und für die Mehrheit der "Otto Normaluser" völlig ausreichend. Wenn man also nicht sehr spezielle Anforderungen hat, ist man mit derart preiswerten Lösungen immer noch sehr gut bedient.
64-Bit-OS und 32-Bit-Usersoftware (sofern ohne riesigen RAM-Bedarf - Bildbearbeitung und Videoschnitt sind also explizit ausgenommen) ergänzen sich wunderbar.
Das ist -zumindest für den sogenannten Power-User- sicher eine interessante Kombination, für schätzungsweise 95% der Anwender aber der schiere Overkill.
So long,
Martin
Moin!
32-Bit-Windows kann nur grob 3 GB adressieren, das eine GB bis 4 liegt im Prinzip nutzlos brach.
das stimmt so nicht; ein 32bit-Windows kann 4GB adressieren. In der Standardkonfiguration ist aber von diesem Adressraum die Hälfte (also 2GB) für das OS selbst reserviert, es bleiben also 2GB für Anwendungen. Die Grenze lässt sich von 2:2 auf 3:1 zugunsten des Anwender-Speicherbereichs ändern, außerdem gilt durch geschicktes Speichermanagement (PAE) die 3GB-Grenze für jede Anwendung separat. Ein 32bit-Windows kann also -passende Hardware vorausgesetzt- bis zu 3GB pro Applikation verwalten.
"Verwalten" - mag sein. Nutzen - nein. Je nach installierter Hardware blenden diese ihre eigenen Register im obersten Gigabyte des Adressraumes ein, das dort physikalisch installierte RAM wird davon überdeckt und bleibt ungenutzt.
Nach allem, was ich bisher gehört habe, soll PAE aber erst ab Windows 7 zufriedenstellend funktionieren; ein 64bit-XP ist/war also eher ein Problemkandidat als ein Fortschritt.
Ein 64-Bit-XP funktioniert super - was problematisch ist, ist ein 32-Bit-XP mit PAE. Wobei die Notwendigkeit für PAE nicht mehr existiert, die korrekte Lösung ist, ein 64-Bit-OS zu verwenden.
Im übrigen lohnt es sich nicht, weniger als 8 GB zu installieren, und es lohnt nicht, noch ein 32-Bit-OS zu installieren.
Das ist Ansichtssache, wir hatten das Thema erst kürzlich. PCs mit 32bit-Architektur sind sehr preiswert geworden (teils unter 200EU$), und für die Mehrheit der "Otto Normaluser" völlig ausreichend. Wenn man also nicht sehr spezielle Anforderungen hat, ist man mit derart preiswerten Lösungen immer noch sehr gut bedient.
Welche 32-Bit-Architektur meinst du da konkret?
64-Bit-OS und 32-Bit-Usersoftware (sofern ohne riesigen RAM-Bedarf - Bildbearbeitung und Videoschnitt sind also explizit ausgenommen) ergänzen sich wunderbar.
Das ist -zumindest für den sogenannten Power-User- sicher eine interessante Kombination, für schätzungsweise 95% der Anwender aber der schiere Overkill.
Sehe ich anders. Außer für Technikverweigerer haben 64-Bit-OS nur Vorteile.
Bei IP steigt man ja schließlich auch auf 128-Bit lange Adressen um, weil 32 Bit nicht reichen.
- Sven Rautenberg
Hallo,
Nach allem, was ich bisher gehört habe, soll PAE aber erst ab Windows 7 zufriedenstellend funktionieren; ein 64bit-XP ist/war also eher ein Problemkandidat als ein Fortschritt.
Ein 64-Bit-XP funktioniert super - was problematisch ist, ist ein 32-Bit-XP mit PAE.
das meinte ich auch eigentlich, danke für die Korrektur.
PCs mit 32bit-Architektur sind sehr preiswert geworden (teils unter 200EU$), und für die Mehrheit der "Otto Normaluser" völlig ausreichend. [...]
Welche 32-Bit-Architektur meinst du da konkret?
Beispielsweise die inzwischen vermehrt angebotenen Low-Power-Geräte auf Atom-Basis (auch wenn *dieses* Angebot momentan vergriffen ist); die immer noch in den Läden stehenden Celerons, die angeboten werden wie Sauerbier; oder die AMD Semprons der älteren Generation, die ich aber schon ein Weilchen nicht mehr im Handel gesehen habe.
Bei IP steigt man ja schließlich auch auf 128-Bit lange Adressen um, weil 32 Bit nicht reichen.
Global ja, lokal (innerhalb von Unternehmens- oder Privatnetzwerken) wohl noch lange nicht.
Ciao,
Martin
Beispielsweise die inzwischen vermehrt angebotenen Low-Power-Geräte auf Atom-Basis (auch wenn *dieses* Angebot momentan vergriffen ist); die immer noch in den Läden stehenden Celerons, die angeboten werden wie Sauerbier; oder die AMD Semprons der älteren Generation, die ich aber schon ein Weilchen nicht mehr im Handel gesehen habe.
Atom-CPUs hatten immer schon EM64T bzw. Intel 64, Celerons ab Anfang 2005 - auch die Semprons haben seit gut 7 Jahren AMD64-Support.
In Läden die sowas noch führen sollte man tunlichst nicht einkaufen :)
Hallo,
Atom-CPUs hatten immer schon EM64T bzw. Intel 64, Celerons ab Anfang 2005 - auch die Semprons haben seit gut 7 Jahren AMD64-Support.
oh, echt?? Ich dachte, das sei bei Intel erst mit den i3/i5/i7 eingeführt worden, und bei AMD mit den CPU-Typen, die auch lautstark mit der "64" im Namen Werbung gemacht haben (also etwa Athlon64).
Dann habe ich ja seit einigen Jahren auch überwiegend 64bit-taugliche Rechner, ohne es zu wissen. Nur bei der Büchse, an der ich momentan sitze, habe ich es gewusst, aber mangels Bedarf trotzdem kein 64bit-System installiert. Vielleicht irgendwann mal. :-)
So long,
Martin
Atom-CPUs hatten immer schon EM64T bzw. Intel 64, Celerons ab Anfang 2005 - auch die Semprons haben seit gut 7 Jahren AMD64-Support.
oh, echt?? Ich dachte, das sei bei Intel erst mit den i3/i5/i7 eingeführt worden, und bei AMD mit den CPU-Typen, die auch lautstark mit der "64" im Namen Werbung gemacht haben (also etwa Athlon64).
Die 2. bzw 3. Generation des Socket-754-Sempron (also kurz nach der Einführung des ersten Athlon 64) konnte das schon - sind ja im Endeffekt dieselben ICs nur mit ein paar deaktivieren Komponenten aufgrund von Ausbeuteoptimierungsprozessen.
Palermo Sempron = Oakville Athlon 64 mit 128 oder 256 KiB Cache, statt 512 KiB und ggf. 200 MHz weniger Takt.
Im übrigen lohnt es sich nicht, weniger als 8 GB zu installieren,
oh, wenn ich bedenke, daß vor kurzem noch 256 MB hatte (nachdem ich von 128 MB aufgestockt hatte, versteht sich...)
64-Bit-OS und 32-Bit-Usersoftware ... ergänzen sich wunderbar.
ach, und das geht? Ich meine so ohne Probleme?
64-Bit-OS und 32-Bit-Usersoftware ... ergänzen sich wunderbar.
ach, und das geht? Ich meine so ohne Probleme?
Sofern die Software anständig geschrieben ist, ja - was Probleme bereiten kann, ist wenn die Programme eigene Treiber mitbringen, die eben nicht für das OS geeignet sind.
32-Bit-Windows kann nur grob 3 GB adressieren, das eine GB bis 4 liegt im Prinzip nutzlos brach. Schon in diesem Szenario kriegt man mit 64Bit-OS mehr RAM.
Nicht ganz - 32-Bit-Windows kann 4 GiB direkt adressieren (PAE lassen wir jetzt mal außen vor) - 2 GiB für den User und 2 GiB für den Kernel, wobei sich dieses Verhältnis auf 3 und 1 GiB verschieben lässt (/3GB switch in der boot.ini)
Allerdings wird der zur Verfügung stehende Adressraum bereits durch andere Hardware wie z.B. der Grafikkarte belegt. Einfach formuliert belebt eine Grafikkarte mit 1 GiB eigenem Speicher auch diesen vom Hauptspeicher - allerdings tricksen die Grafikkarten hierbei, damit nicht gnadenlos im Hauptspeicher herumgesaut wird.
Je nach Hardware hat man unter Windows also bis zu 4 GiB zur Verfügung - mit einer bescheidenen Grafikkarte kommt man sehr Nahe an die 4 GiB ran.
Dabei liegt nichts "Brach" sondern wird nur bereits von "jemand anderem" genutzt.
Im übrigen lohnt es sich nicht, weniger als 8 GB zu installieren, und es lohnt nicht, noch ein 32-Bit-OS zu installieren.
Full ACK
Moin!
Nicht ganz - 32-Bit-Windows kann 4 GiB direkt adressieren (PAE lassen wir jetzt mal außen vor) - 2 GiB für den User und 2 GiB für den Kernel, wobei sich dieses Verhältnis auf 3 und 1 GiB verschieben lässt (/3GB switch in der boot.ini)
Das, was es adressieren kann, wird aber eben nicht nur als RAM genutzt, sondern als Kommunikationskanal mit eingebauter Hardware.
Allerdings wird der zur Verfügung stehende Adressraum bereits durch andere Hardware wie z.B. der Grafikkarte belegt. Einfach formuliert belebt eine Grafikkarte mit 1 GiB eigenem Speicher auch diesen vom Hauptspeicher - allerdings tricksen die Grafikkarten hierbei, damit nicht gnadenlos im Hauptspeicher herumgesaut wird.
Grafikkarten verbrauchen in der Regel nicht den RAM-Speicher, den sie selbst mitbringen, im CPU-Adressraum - eher im Gegenteil. Gewöhnlich sind allerdings noch weitere Hardwareelemente eingebaut, die ebenfalls Informationen haben wollen und dafür physikalisch Adressbereiche belegen.
Je nach Hardware hat man unter Windows also bis zu 4 GiB zur Verfügung - mit einer bescheidenen Grafikkarte kommt man sehr Nahe an die 4 GiB ran.
Wenn man Tests glauben kann, wird ein Standard-Windows ohne PAE höchstens 3,5 GB anbieten, eher jedoch nur 3,25 GB.
Dabei liegt nichts "Brach" sondern wird nur bereits von "jemand anderem" genutzt.
Doch, das RAM, dessen Adressen stattdessen von der Hardware genutzt werden, liegt brach. Es ist installiert, aber nicht nutzbar. Der einzige Vorteil, den man daraus ziehen kann, ist die Optimierung des RAM-Zugriffs insgesamt, der bei zwei identischen Riegeln gleicher Größe entsteht.
- Sven Rautenberg
Je nach Hardware hat man unter Windows also bis zu 4 GiB zur Verfügung - mit einer bescheidenen Grafikkarte kommt man sehr Nahe an die 4 GiB ran.
Wenn man Tests glauben kann, wird ein Standard-Windows ohne PAE höchstens 3,5 GB anbieten, eher jedoch nur 3,25 GB.
Das kommt auf die Hardware an - wenn du einen beliebigen Rechner aus dem "Regal" kaufst, werden diese Zahlen sicher hinkommen.
Dabei liegt nichts "Brach" sondern wird nur bereits von "jemand anderem" genutzt.
Doch, das RAM, dessen Adressen stattdessen von der Hardware genutzt werden, liegt brach. Es ist installiert, aber nicht nutzbar. Der einzige Vorteil, den man daraus ziehen kann, ist die Optimierung des RAM-Zugriffs insgesamt, der bei zwei identischen Riegeln gleicher Größe entsteht.
Ja du hast recht - wenn man davon ausgeht, dass keine Mehrkanal-Speicher genutzt werden, liegt der speicher tatsächlich brach und kann nicht genutzt werden, da der Adressraum bereits anderweitig vergeben ist.
Ich hab' in meinem Kommentar nicht genaug genug auf die Unterscheidung zwischen Adressraum und physisch vorhandenen Speicher geachtet.
ich verstehe immer noch nicht. Konkretes Beispiel: 32-Bit, 2GB Speicher (bei mir der Fall). Der kann jetzt pro Sekunde 1,8 GHz mal 32 Bit verarbeiten. Ein System mit 64 Bit könnte in der selben Sekunde 1,8 GHz mal 64 Bit verarbeiten. Selbt angenommen, es bräuchte dazu 4 GB Speicher. Ist die Leistung dann nicht die doppelte?
Ja, die Leistung des Prozessors wird erhöht. Wie die Personenzahl eines Doppeldecker-Busses. Aber die Speicherung des Buchstabens "A" benötigt deshalb nicht achtmal mehr Platz als bei einem 8-Bit-System.
Aber bei der Beförderung von Buchstaben aus einer Datei zum Bildschirm kann jetzt pro Takt "ABCDEFGH" statt früher nur "A" geleistet werden.
Und nochmal: was soll dann 64-Bit, wenn meine Rechnung nicht stimmt? Warum kehren wir nicht zu 8 Bit zurück?
Ich denke, weil farbige, grafische Oberflächen und bewegte Bilder (Videos, Spiele) ein Vielfaches an Leistung benötigen als die Darstellung auf früheren "Grün-auf-schwarz" Monitoren mit 80 x 25 Zeichen.
Wenn schon zurück zum 8-Bit-System, dann bitte auch zum 1200er Modem und Akustikkoppler. Da konnte man die Ankunft von Webseiten noch hören ;-)
Gast
Hello,
Aber bei der Beförderung von Buchstaben aus einer Datei zum Bildschirm kann jetzt pro Takt "ABCDEFGH" statt früher nur "A" geleistet werden.
Nee, den "Buchstaben" gibts dann ja auch bald nicht mehr, sondern nur noch den Codepoint in der UNI-Code-Tabelle. Und der benötigt dann 1 bis 4mal soviel Speicherplatz und, was viel schlimmer ist, bis zu 100mal soviel Rechenzeit (Ticks) um erkannt zu werden.
Das hat aber nicht direkt mit der Umstellung von 32 zu 64Bit, sondern mit ASCII zu Babylon zu tun.
Aber beides ergänzt sich sicherlich auch noch...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Nee, den "Buchstaben" gibts dann ja auch bald nicht mehr, sondern nur noch den Codepoint in der UNI-Code-Tabelle. Und der benötigt dann 1 bis 4mal soviel Speicherplatz und, was viel schlimmer ist, bis zu 100mal soviel Rechenzeit (Ticks) um erkannt zu werden.
Auch bei ASCII ist ein "Buchstabe" nichts anderes als ein Codepoint. Was meinst Du mit "erkennen"? Den passenden Glyphen in einer Schriftart finden?
Viele Grüße,
Alexander
Hi,
Nee, den "Buchstaben" gibts dann ja auch bald nicht mehr, sondern nur noch den Codepoint in der UNI-Code-Tabelle. Und der benötigt dann 1 bis 4mal soviel Speicherplatz und, was viel schlimmer ist, bis zu 100mal soviel Rechenzeit (Ticks) um erkannt zu werden.
Auch bei ASCII ist ein "Buchstabe" nichts anderes als ein Codepoint.
stimmt.
Was meinst Du mit "erkennen"? Den passenden Glyphen in einer Schriftart finden?
Vermeutlich meint er eher, beispielsweise aus einer UTF-8-Bytefolge zielsicher die Bytes bzw. Bytegruppen zu identifizieren, die jeweils ein Zeichen bilden. Das ist zwar AFAIK eindeutig, aber nicht immer ganz einfach.
Ciao,
Martin
Tach!
Nee, den "Buchstaben" gibts dann ja auch bald nicht mehr, sondern nur noch den Codepoint in der UNI-Code-Tabelle. Und der benötigt dann 1 bis 4mal soviel Speicherplatz und, was viel schlimmer ist, bis zu 100mal soviel Rechenzeit (Ticks) um erkannt zu werden.
Auch bei ASCII ist ein "Buchstabe" nichts anderes als ein Codepoint.
stimmt.
Mit anderen Worten: Buchstaben gab es sowieso noch nie in der auf Zahlen basierenden Rechentechnik.
Was meinst Du mit "erkennen"? Den passenden Glyphen in einer Schriftart finden?
Vermeutlich meint er eher, beispielsweise aus einer UTF-8-Bytefolge zielsicher die Bytes bzw. Bytegruppen zu identifizieren, die jeweils ein Zeichen bilden. Das ist zwar AFAIK eindeutig, aber nicht immer ganz einfach.
UTF-8 wird eher selten für die interne Verarbeitung verwendet, eben weil man sonst immer nur anhand der Sequenz die Zeichengrenzen bestimmen kann. Stattdessen nimmt man für Strings pro Zeichen 16 Bit (oder auch mal 32 Bit für die vergleichsweise selten verwendeten Zeichen oberhalb der BMP) und kann dann ähnlich effizient wie beim 1-Zeichen-gleich-1-Byte-Prinzip arbeiten.
dedlfix.
Hi dedlfix,
UTF-8 wird eher selten für die interne Verarbeitung verwendet, eben weil man sonst immer nur anhand der Sequenz die Zeichengrenzen bestimmen kann. Stattdessen nimmt man für Strings pro Zeichen 16 Bit (oder auch mal 32 Bit für die vergleichsweise selten verwendeten Zeichen oberhalb der BMP) und kann dann ähnlich effizient wie beim 1-Zeichen-gleich-1-Byte-Prinzip arbeiten.
könntest du mir das bitte etwas erklären? das hört sich sehr interessant an, nur verstehe ich es noch nicht so ganz.
Tach!
UTF-8 wird eher selten für die interne Verarbeitung verwendet, eben weil man sonst immer nur anhand der Sequenz die Zeichengrenzen bestimmen kann. Stattdessen nimmt man für Strings pro Zeichen 16 Bit (oder auch mal 32 Bit für die vergleichsweise selten verwendeten Zeichen oberhalb der BMP) und kann dann ähnlich effizient wie beim 1-Zeichen-gleich-1-Byte-Prinzip arbeiten.
könntest du mir das bitte etwas erklären? das hört sich sehr interessant an, nur verstehe ich es noch nicht so ganz.
UTF-8 ist ein Format, das eher als Kompromiss zu vorhandenen Texten mit ASCII-Zeichenumfang und zur Optimierung des Speicherbedarfs bei ASCII-lastigen Texten zu sehen ist.
Ich kenne nicht alle Stringverarbeitungssysteme, aber ich schließe mal kühn von ein paar mir bekannten Gegebenheiten und logischen Erwägungen auf die Allgemeinheit. Die Windows-String-Verarbeitung legt ihre Unicode-Strings in 16-Bit- oder auch 32-Bit-Strukturen ab, auf dass man wieder einen wahlfreien Zugriff auf Zeichen anhand einer Position mal Speicherbedarf eines Zeichens hat. Wenn man solche positionsorientierte Stringverarbeitung effizient machen möchte, kommt man kaum an einer solchen Speicherung mit festen Längen vorbei. Alternative wäre ein Index, der die Position jedes Zeichen speichert. Aber das nimmt am Ende mehr Speicher ein als der Overhead von ASCII-Zeichen in einer 16-Bit-Struktur.
Letzlich muss man sowieso die Praxis und konkrete Anwendungsfälle anschauen, als auf zu allgemeinem Niveau, abstrakte Nachteile zu suchen, die im Spezialfall vielleicht gar nicht relevant sind oder für die es eine akzeptable Kompromisslösung gibt.
Für die interne Verarbeitung ist es für einige Anwedungsfälle recht aufwendig, Texte mit Zeichenlängen von 1 bis 4 Bytes zu verwalten. (Das ist vergleichbar mit Arrays mit gleicher Datensatzlänge und Strukturen für unterschiedliche Daten(satz)größen. Bei ersteren kann man die Positionen der Felder anhand von n*Feldgröße berechnen, bei letzteren muss man anderweitig vorgehen.) In anderen Fällen kann es sein, dass diese unterschiedliche Länge nicht weiter ins Gewicht fällt, weil man keine exakte Positionen jedes einzelnen Zeichend berechnen können muss. In einem Editor muss beim Eingeben von Text vereinfacht gesehen nur eine Cursor-Position bekannt sein, die man immer nur vom bekannten Ort ein wenig nach vorn und hinten verschiebt, wobei man sich dann an den Zeichen entlanghangeln kann (so man vorwärts und rückwärts laufend die Zeichen-Grenzen erkennen kann, was zum Beispiel bei UTF-8 der Fall ist). Es kann aber auch sein, dass der Editor sich weniger an einer bestimmten Kodierung orientiert, sondern die vom Betriebssystem angebotenen Strukturen nutzt und den Text erst beim Speichern in eine bestimmte Kodierung umwandelt.
Im Allgemeinen sind diese Überlegungen, wie etwas intern abläuft (oder ablaufen könnte - es gibt ja oftmals mehrere Wege und mitunter sieht man nur eine Blackbox vor sich) einerseits zwar nicht uninteressant, andererseits aber auch müßig, weil man an den Gegebenheiten nichts ändern kann, wenn man sich nicht gerade beispielsweise eine Stringverarbeitungsbibliothek zu schreiben versucht.
dedlfix.
Tach!
UTF-8 wird eher selten für die interne Verarbeitung verwendet, eben weil man sonst immer nur anhand der Sequenz die Zeichengrenzen bestimmen kann. Stattdessen nimmt man für Strings pro Zeichen 16 Bit (oder auch mal 32 Bit für die vergleichsweise selten verwendeten Zeichen oberhalb der BMP) und kann dann ähnlich effizient wie beim 1-Zeichen-gleich-1-Byte-Prinzip arbeiten.
könntest du mir das bitte etwas erklären? das hört sich sehr interessant an, nur verstehe ich es noch nicht so ganz.
UTF-8 ist ein Format, das eher als Kompromiss zu vorhandenen Texten mit ASCII-Zeichenumfang und zur Optimierung des Speicherbedarfs bei ASCII-lastigen Texten zu sehen ist.
Ach, vielen Dank.Jetzt verstehe ich auch, warum Windows UTF-16 nutzt und nicht UTF-8. Alles klar, super, wieder mal was dazugelernt! Eine Frage noch: UTF-8 nutzt man dann genau, weil ...? Aus Platzgründen? Könnte man doch gleich UTF-16 nutzen!
Oder anders gefragt: macht es Sinn, Webseiten als UTF-16 auszuliefern? Oder spricht was dagegen?
Danke,
Dümmler
Hallo,
Eine Frage noch: UTF-8 nutzt man dann genau, weil ...? Aus Platzgründen?
genau deshalb.
Oder anders gefragt: macht es Sinn, Webseiten als UTF-16 auszuliefern? Oder spricht was dagegen?
Dagegen spricht das um fast den Faktor höhere Datenvolumen, da für *jedes* Zeichen 2 Bytes übertragen werden müssen. Texte in lateinischer Schrift (ohne die Varianten Kyrillisch und Griechisch) enthalten aber einen hohen Anteil Zeichen aus dem ASCII-Bereich, die bei Verwendung von UTF-8 mit nur einem Byte codiert werden.
Eine Verwendung von UTF-16 bei der Übermittlung wird erst interessant, wenn ein sehr hoher Anteil der Zeichen außerhalb des ASCII-Bereichs liegt - vor allem, wenn viele Zeichen vorkommen, die in UTF-8 sogar mit 3 Bytes dargestellt werden, wie etwa in vielen asiatischen Schriften.
Ciao,
Martin
Moin!
Eine Verwendung von UTF-16 bei der Übermittlung wird erst interessant, wenn ein sehr hoher Anteil der Zeichen außerhalb des ASCII-Bereichs liegt - vor allem, wenn viele Zeichen vorkommen, die in UTF-8 sogar mit 3 Bytes dargestellt werden, wie etwa in vielen asiatischen Schriften.
Selbst dort nicht wirklich, sofern man ihn z.B. in HTML packt. Die paar 3-Byte-Zeichen sind im Verhältnis zu den notwendigen 1-Byte-Zeichen, insbesondere auch beim Whitespace, nicht so häufig, dass man mit UTF-16 Vorteile hätte.
- Sven Rautenberg
Tach!
Eine Frage noch: UTF-8 nutzt man dann genau, weil ...? Aus Platzgründen? Könnte man doch gleich UTF-16 nutzen!
Sagte ich ja schon, aus Platz- und Kompatibilitätsgründen. Die ersten 128 UTF-8-Zeichen sind zu ASCII kompatibel und benötigen nur 1 Byte pro Zeichen.
Oder anders gefragt: macht es Sinn, Webseiten als UTF-16 auszuliefern? Oder spricht was dagegen?
Eine absolute Antwort kann ich nicht geben, nur eine mit Wenns und Abers.
Wenn du überwiegend (inklusive dem ganzen HTML-Markup und eingebetteten CSS/JS/...-Codes) Zeichen aus dem ASCII-Bereich hast, dann lohnt sich was anderes als UTF-8 nicht aus Platzgründen. Die Rechnung kippt allerdings stärker zugunsten von UTF-16, wenn du sehr viele drei- und vierbytige UTF-8-Sequenzen benötigst. Weiter musst du in die Betrachtung mit einbeziehen, dass dich vielleicht der Speicherplatz auf dem Server nicht juckt, weil mehr als genügend vorhanden ist, dir jedoch die Übertragung Traffickosten beschert. Das lässt sich jedoch mit einer Komprimierung kompensieren (Transfer-Encoding).
dedlfix.
Tach,
Ach, vielen Dank.Jetzt verstehe ich auch, warum Windows UTF-16 nutzt und nicht UTF-8. Alles klar, super, wieder mal was dazugelernt! Eine Frage noch: UTF-8 nutzt man dann genau, weil ...? Aus Platzgründen? Könnte man doch gleich UTF-16 nutzen!
ja, aus Platzgründen, hier im europäischen Sprachraum sind die meisten Zeichen in UTF-8 mit weniger als zwei Bytes kodiert (darunter quasi alles am Quelltext, was kein Nutztext ist), am Beispiel deines Postings: in UTF-8 belegt es bei mir 35904 Bytes, nach der Umwandlung in UTF-16 71740. Je nach Menge an Nicht-Ascii-Zeichen, wird das Verhältnis weiter von 50% entfernt sein, aber vermutlich immer besser bleiben.
Oder anders gefragt: macht es Sinn, Webseiten als UTF-16 auszuliefern? Oder spricht was dagegen?
Es ergibt Sinn, wenn man z.B. in ostasiatischen Sprachen geschriebene Inhalte hat; hier kann es sein, dass die einzelnen Zeichen in UTF-8 drei Bytes belegen, während sie in UTF-16 nur zwei brauchen.
mfg
Woodfighter
Hello,
UTF-8 wird eher selten für die interne Verarbeitung verwendet, eben weil man sonst immer nur anhand der Sequenz die Zeichengrenzen bestimmen kann. Stattdessen nimmt man für Strings pro Zeichen 16 Bit (oder auch mal 32 Bit für die vergleichsweise selten verwendeten Zeichen oberhalb der BMP) und kann dann ähnlich effizient wie beim 1-Zeichen-gleich-1-Byte-Prinzip arbeiten.
Das bedeutet aber Rechenzeit und Speicherplatz für die Umwandlung aus der (komprimierten, persistenten) Datenhaltung in die Arbeitsdatenhaltung.
Wenn man das 15.000ste Zeichen sucht (warum auch immer), muss man die Datei (als persistente Datenhaltung) von Anfang an bis mindestens zu diesem Zeichen einlesen und auswerten. Das können dann auch schon mal 60.000 Bytes sein :-O
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Tach!
Wenn man das 15.000ste Zeichen sucht (warum auch immer), muss man die Datei (als persistente Datenhaltung) von Anfang an bis mindestens zu diesem Zeichen einlesen und auswerten. Das können dann auch schon mal 60.000 Bytes sein :-O
Wann genau suchst du denn Zeichen anhand ihrer Position, und noch dazu in diesen Größenordnungen? Ich suche eher die Vorkommen bestimmter Textstellen. Und dafür muss man auch bei "Ein-Zeichen-gleich-eine-Speichereinheit"-Systemen den Text von vorn an durchsuchen.
Positionsorientierte Stringverarbeitung findet nach meinem Dafürhalten eher bei überschaubar kurzen Strings statt. In dem Fall ist der Mehrbedarf an Zeit vernachlässigbar gering. Bei ständig zu verarbeitenden größeren Datenmengen (z.B. vielen kleinen Datensätzen) muss man sowieso individuell nach Optimierungspotential suchen, sei es 16/32-Bit-pro-Zeichen-Speicherung oder was ganz anderes.
dedlfix.
Hello,
Nee, den "Buchstaben" gibts dann ja auch bald nicht mehr, sondern nur noch den Codepoint in der UNI-Code-Tabelle. Und der benötigt dann 1 bis 4mal soviel Speicherplatz und, was viel schlimmer ist, bis zu 100mal soviel Rechenzeit (Ticks) um erkannt zu werden.
Auch bei ASCII ist ein "Buchstabe" nichts anderes als ein Codepoint. Was meinst Du mit "erkennen"? Den passenden Glyphen in einer Schriftart finden?
Bei ASCII (oder anderen In-Byte-Codes) wird die Codetabelle vorher geladen und dann kann die Darstellung des Zeichens einfach per Dereferenzierung adressiert werden.
Bei UTF muss leider der gesamte Text gestreamt werden, bevor die Zeichnauflösung stattfinden kann. Da ist also nix mehr mit Wahlfreiem Zugriff. Je länger nun so eine Textsequenz ist, desto mehr Ticks verschluckt sie, bevor sie in "Zeichen" zerlegt worden ist.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Moin!
Hello,
Nee, den "Buchstaben" gibts dann ja auch bald nicht mehr, sondern nur noch den Codepoint in der UNI-Code-Tabelle. Und der benötigt dann 1 bis 4mal soviel Speicherplatz und, was viel schlimmer ist, bis zu 100mal soviel Rechenzeit (Ticks) um erkannt zu werden.
Auch bei ASCII ist ein "Buchstabe" nichts anderes als ein Codepoint. Was meinst Du mit "erkennen"? Den passenden Glyphen in einer Schriftart finden?
Bei ASCII (oder anderen In-Byte-Codes) wird die Codetabelle vorher geladen und dann kann die Darstellung des Zeichens einfach per Dereferenzierung adressiert werden.
Mit den bekannten Problemen.
Abgesehen davon ist das Ausgeben eines Zeichens durchaus nicht unaufwendig. Und Unicode ermöglicht es erst, dies für alle menschlichen Sprachen auch korrekt zu tun - die Rechenpower ist locker vorhanden.
Bei UTF muss leider der gesamte Text gestreamt werden, bevor die Zeichnauflösung stattfinden kann. Da ist also nix mehr mit Wahlfreiem Zugriff. Je länger nun so eine Textsequenz ist, desto mehr Ticks verschluckt sie, bevor sie in "Zeichen" zerlegt worden ist.
Falsch. Du kannst anhand jedes einzelnen Bytes erkennen, welche der bis zu vier vorausliegenden oder nachfolgenden Bytes dich auch interessieren sollten - ein Zugriff auf den Gesamttext ist nicht erforderlich.
- Sven Rautenberg
Hello,
Falsch. Du kannst anhand jedes einzelnen Bytes erkennen, welche der bis zu vier vorausliegenden oder nachfolgenden Bytes dich auch interessieren sollten - ein Zugriff auf den Gesamttext ist nicht erforderlich.
Ach Sven...
Ich dachte, Du hättest auch mal in den niederen Schichten Programmieren gelernt :-O
Wie soll ich denn eine in UTF-8 codierte Zeichenkette durch Random-Acces und zugehörige Codetabelle direkt in eine Darstellung überführt? An der wievielten Byteposition im Text beginnt denn das x-te Zeichen?
Bei UTF-8 (o.ä.) muss der Zeichenstrom muss erst sequentiell durchgearbeitet werden, um das x-te Zeichen zu finden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Tach!
Wie soll ich denn eine in UTF-8 codierte Zeichenkette durch Random-Acces und zugehörige Codetabelle direkt in eine Darstellung überführt? An der wievielten Byteposition im Text beginnt denn das x-te Zeichen?
Wenn du Random Access haben willst, warum arbeitest du dann mit UTF-8 und nicht mit UTF-16 (falls BMP ausreicht, ansonsten mit UTF-32)?
dedlfix.
Moin!
Falsch. Du kannst anhand jedes einzelnen Bytes erkennen, welche der bis zu vier vorausliegenden oder nachfolgenden Bytes dich auch interessieren sollten - ein Zugriff auf den Gesamttext ist nicht erforderlich.
Ach Sven...
Ich dachte, Du hättest auch mal in den niederen Schichten Programmieren gelernt :-OWie soll ich denn eine in UTF-8 codierte Zeichenkette durch Random-Acces und zugehörige Codetabelle direkt in eine Darstellung überführt? An der wievielten Byteposition im Text beginnt denn das x-te Zeichen?
UTF-32 nutzen für die interne Speicherung, wenn sowas gewünscht ist. Wie häufig brauchst du "das dreihundertste Zeichen im Text", so dass du bei ASCII auf das 300. Byte zugreifen kannst, und bei UTF-8 alle 299 vorherigen Zeichen zu überspringen hast?
- Sven Rautenberg
Hello,
Wie soll ich denn eine in UTF-8 codierte Zeichenkette durch Random-Acces und zugehörige Codetabelle direkt in eine Darstellung überführt? An der wievielten Byteposition im Text beginnt denn das x-te Zeichen?
UTF-32 nutzen für die interne Speicherung, wenn sowas gewünscht ist. Wie häufig brauchst du "das dreihundertste Zeichen im Text", so dass du bei ASCII auf das 300. Byte zugreifen kannst, und bei UTF-8 alle 299 vorherigen Zeichen zu überspringen hast?
Ach, und das braucht dann nicht mehr Speicher und mehr Traffic?
Da habe ich wohl einen Trick verpasst.
Alternativ kostet es eben Rechenzeit...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Wie soll ich denn eine in UTF-8 codierte Zeichenkette durch Random-Acces und zugehörige Codetabelle direkt in eine Darstellung überführt? An der wievielten Byteposition im Text beginnt denn das x-te Zeichen?
UTF-32 nutzen für die interne Speicherung, wenn sowas gewünscht ist. Wie häufig brauchst du "das dreihundertste Zeichen im Text", so dass du bei ASCII auf das 300. Byte zugreifen kannst, und bei UTF-8 alle 299 vorherigen Zeichen zu überspringen hast?
Ach, und das braucht dann nicht mehr Speicher und mehr Traffic?
Da habe ich wohl einen Trick verpasst.
Du hattest geschrieben, es bräuchte mehr Speicherplatz UND mehr Rechenzeit, und hast jeweils mit dem Worst Case (also quasi der Rechenzeit bei UTF-8 und dem Speicherverbrauch bei UTF-32) gerechnet. Das stimmt so nicht; eins von beiden fällt immer etwas günstiger aus, je nach Wahl. Und Random-Access braucht man wirklich fast nie.
Dass die Unicode-Stringverarbeitung ein bisschen aufwendiger ist als die von Single-Byte-Strings, bestreitet ja auch niemand. Der Punkt ist nur: Das ist es wert. Oder möchtest Du ca. 3 Milliarden Menschen erklären, dass sie ihre jeweilige Muttersprache abschaffen* sollen, nur weil wir ein paar Ticks sparen wollen?
Der Computer dient immer dem Benutzer. Wir lassen ihn aufwendige Grafiken etc. pp. rendern, nur damit die Oberfläche ein bisschen schöner aussieht (obwohl man ja auch mit einfachsten Schwarz-Weiß-Kästen arbeiten und damit viel, viel mehr Ticks sparen könnte). Dann kann ordentliche Textverarbeitung in mehreren Sprachen ja wohl nicht zu viel verlangt sein.
Viele Grüße,
Alexander
* Inklusive des Nicht-Abspeicherns aller vorhandenen und historischen Texte
Hello,
Dass die Unicode-Stringverarbeitung ein bisschen aufwendiger ist als die von Single-Byte-Strings, bestreitet ja auch niemand. Der Punkt ist nur: Das ist es wert. Oder möchtest Du ca. 3 Milliarden Menschen erklären, dass sie ihre jeweilige Muttersprache abschaffen* sollen, nur weil wir ein paar Ticks sparen wollen?
Das müssen sie ja gar nicht.
ERST die Codepage wählen, dann schreiben.
Das ist doch genauso, wie im wahren Leben. Da entscheide ich mich für eine saubere Kommunikation auch immer _erst_ für eine Sprache, und dann fange ich an zu sprechen, oder?
Die berühmten Regeln werden selbstverständlich durchbrochen durch die Ausnahmen...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Dass die Unicode-Stringverarbeitung ein bisschen aufwendiger ist als die von Single-Byte-Strings, bestreitet ja auch niemand. Der Punkt ist nur: Das ist es wert. Oder möchtest Du ca. 3 Milliarden Menschen erklären, dass sie ihre jeweilige Muttersprache abschaffen* sollen, nur weil wir ein paar Ticks sparen wollen?
Das müssen sie ja gar nicht.
ERST die Codepage wählen, dann schreiben.
Genau das funktioniert eben nicht. Eine 1-Byte-Codepage erlaubt maximal 256 Zeichen, und das ist verdammt wenig. Chinesisch, Japanisch, Koreanisch, Vietnamesisch, Vai, Amharisch, Inuktitut und viele andere Sprachen lassen sich damit nicht kodieren. Bei den ca. 3 Milliarden Betroffenen habe ich auch nur diese Sprachen mitgezählt. Mit reinem ASCII hätten rund 6,7 Milliarden Menschen ein Problem.
Außerdem ist es auch problematisch, Zeichen verschiedener Sprachen nicht mischen zu können. Beispielsweise könnte man niemals einen deutschen Text über den polnischen Autor Stanisław Jerzy Lec schreiben - zumindest nicht mit korrekter Orthografie. Und die Wikipedia könnte bei einem Artikel über eine beliebige Stadt im Ausland weder die Originalschreibweise noch die Aussprache in Lautschrift angeben. Usw. usf.
Und dann die Problematik, dass Sender und Empfänger einer Nachricht immer beide dieselbe Codepage einstellen müssen, während bei einem Unicode-Text einfach alles gleich richtig angezeigt wird. Wieviele Ticks muss man einsparen, um je eine Einstellung durch zwei User auszugleichen?
Mal ehrlich, wenn Du Dich mit dem Thema Stringverarbeitung beschäftigt hast, wie kann es dann sein, dass Dir so ziemlich alle Anwendungsfälle außer rein englischem Text entgangen sind?
Viele Grüße,
Alexander
Moin Tom,
Das müssen sie ja gar nicht.
ERST die Codepage wählen, dann schreiben.
Weil das die vergangenen 30 Jahre ja auch so super toll funktioniert hat <ironie/>
LG,
CK
Hallo Tom,
ich würde utf-8 nicht als "aufgeblähtes" ASCII sehen, sondern als komprimiertes UTF-16 oder UTF-32.
Gruß, Jürgen
Hello Jürgen,
ich würde utf-8 nicht als "aufgeblähtes" ASCII sehen, sondern als komprimiertes UTF-16 oder UTF-32.
Genau darum ging es. Entweder man nimmt einen direktgestreuten Code (ASCII, UTF-16, UTF-32), oder man benutzt Rechenzeit für die Serialisierung, Deserialisierung.
Auf jeden Fall explodiert der Aufwand mächtig gegenüber dem guten alten Ein-Byte-Code.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo Tom,
Auf jeden Fall explodiert der Aufwand mächtig gegenüber dem guten alten Ein-Byte-Code.
aber der Zeichenumfang auch.
Gruß, Jürgen
Tach!
Stimmt es, daß ein 64-Bit Windows für die gleiche Leistung doppelt soviel Speicher braucht, wie ein 32-Bit System?
Nein. Nicht alle Datenstrukturen sind nun doppelt so groß. Das ergäbe zum Beispiel bei Text keinen Sinn. Speicheradressen müssen bei 64-Bit-fähigen Programmen jedoch doppelt so groß sein.
Und wenn: was soll das dann bringen? Wo ist der Zweck des breiteren Busses? Sollte man dann nicht bei 32-Bit bleiben?
Eigentlich gelten ja diese Fragen nach dem Nein nun nicht mehr. Aber: Der Umstieg auf 64 Bit macht sich erforderlich, weil irgendwann die mit 32-Bit-Systemen beschränkte (direkte) Adressierbarkeit von 4GB nicht mehr ausreicht. Für RAM jenseits der 4GB kommst du praktisch nicht um ein 64-Bit-System herum.
dedlfix.
Stimmt es, daß ein 64-Bit Windows für die gleiche Leistung doppelt soviel Speicher braucht, wie ein 32-Bit System?
Nein (mit einem ganz kleinen Ja).
Bei sehr kleinen Daten ist der Overhead natürlich recht groß, es wird unnötig viel Speicher "verbraucht".
Und wenn: was soll das dann bringen? Wo ist der Zweck des breiteren Busses? Sollte man dann nicht bei 32-Bit bleiben?
Der Nutzen durch den breiten Bus ist wesentlich größer als der Nachteil durch den Overhead.
Ein einfaches Auto-Beispiel:
Wenn du immer nur 2 Personen von A nach B transportierst, benötigst du keinen 4-Sitzer.
Wenn du hingegen oft mal 3 oder 4 Leute transportierst, müsstest du mit denen 2-Sitzern doppelt so oft fahren bzw. bräuchtest doppelt so viele Fahrzeuge.
Wenn du hingegen einen 4-Sitzer besitzt, musst du damit leben, dass du beim Transport von 1 oder 2 Personen ein paar Plätze leer "mitnimmst", dafür aber kein zweites Fahrzeug benötigst.
Der Kosten-Nutzen-Faktor ist ausschlaggebend - und fakt ist, dass Speicher und Busbreite so billig sind, dass es völlig wurst ist - darum 64 bit.
Sämtlich gegenargumente aus der "Übergangszeit" (keine Optimierung, keine Treiber) gehören bereits seit ein paar Jahren der Vergangenheit an.
