von Java nach C++
-
Die Aussage zu 2b2) kommt mir komisch vor. Weiterhin, schaetze ich, ist schreiben von 4 Byte aehnlich schnell wie 1 Byte.
-
knivil schrieb:
Weiterhin, schaetze ich, ist schreiben von 4 Byte aehnlich schnell wie 1 Byte.
Mit anderen Worten: Wenn ich mit weniger als 4 Byte auskomme, kann ich in der selben Zeit mehr sinnvolle Daten schreiben...
-
Natuerlich, wenn du deine Schreiboperation in einen Block aus 4 zusammenhaengenden Bytes als "Transaktion" packen kannst. Aber bedenke: All das, auch andere Optimierungen wie Fuellbytes, bringen uns weit weg von std::string als Datenstruktur fuer UTF-8.
-
knivil schrieb:
Natuerlich, wenn du deine Schreiboperation in einen Block aus 4 zusammenhaengenden Bytes als "Transaktion" packen kannst.
Nicht nur schreiben, auch suchen geht auf 4 Bytes zusammengefasst (guck mal, wie strlen implementiert ist).
Aber bedenke: All das, auch andere Optimierungen wie Fuellbytes, bringen uns weit weg von std::string als Datenstruktur fuer UTF-8.
Ein std::string mit Füllbytes ist wie ein vector als priority_queue. Die Füllbyteoptimierung ist aber die gleiche wie für UTF-32.
Und ja, vielleicht ist 2b2) mit dem String komplett kopieren 10% langsamer, weil malloc aufgerufen wird, aber da sind keine Welten zu UTF-32.
-
knivil schrieb:
Natuerlich, wenn du deine Schreiboperation in einen Block aus 4 zusammenhaengenden Bytes als "Transaktion" packen kannst. Aber bedenke: All das, auch andere Optimierungen wie Fuellbytes, bringen uns weit weg von std::string als Datenstruktur fuer UTF-8.
Bedenke: Selbst wenn ich nichts davon mache und einfach nur std::string verwende, passen mit UTF-8 ca. doppelt so viele Code Points in eine Cache Line. Wenn wir mit Vektorisierung anfangen, schauts für UTF-32 sowieso düster aus...
-
Nicht nur schreiben, auch suchen geht auf 4 Bytes zusammengefasst (guck mal, wie strlen implementiert ist).
Ach, und ich dachte die Intel-Leute sind alles Narren mit ihrem MMX und SSE. Und zu strlen, es gibt Gruende warum es nicht auf mehreren Bytes arbeitet. Aber dazu muesste ich in der Tat nachsehen.
Wenn wir mit Vektorisierung anfangen, schauts für UTF-32 sowieso düster aus
Meine Erfahrung ist, dass variable Laenge echt scheisse ist, um mit SSE behandelt zu werden. Nun, die Erfahrung muss sich nicht auf UTF-8 uebertragen aber ich glaube kaum, dass UTF-8 mehr als alle anderen von Vektorisierung profitieren.
Um mal die Diskussion zusammenzufasen: Ich sage A. Darauf folgt: Gaube A nicht. Das gilt auch anders herum.
PS: Ich habe nachgesehen. Leider erzwingt die Implementation, dass das Ende von angefordertem Speicher genug Platz fuer 32/64-Bit bietet.
-
knivil schrieb:
Entschuldigung, ich habe mich wohl falsch ausgedrueckt: UTF ist totaler Bockmist.
+1
-
Wäre UTF-40 nicht optimal? Damit wäre es kein Problem jedes Zeichen als Codepoint zu codieren und man hätte den Mist mit den Grapheme-Clustern nicht.
-
Ethon schrieb:
Damit wäre es kein Problem jedes Zeichen als Codepoint zu codieren und man hätte den Mist mit den Grapheme-Clustern nicht.
Selbst unter der Annahme, dass 40 Bit dafür reichen würden (was ich mal bezweifle), würde das nix nützen, da man dann immer noch z.B. die Steuerzeichen für die verschiedensten Schreibsysteme braucht usw...
-
Gut, UTF-4000 + Locale-Codierung könnten das string.reverse()-Problem lösen.
Weitere Unicode-Knobelaufgaben:
- 2 Strings vergleichen (hint)
- In Array aus Wörtern splitten
- Zeilenumbruch durchführen
