Schnellste Weg (performance-wise), um einen string in ein byte[] array in C# unter Verwendung der ASCII-Zeichen-Kodierung

Wenn alle Ihre Daten wirklich werde ASCII, dann können Sie in der Lage sein, es zu tun, etwas schneller als ASCIIEncoding, die mit verschiedenen (durchaus sinnvoll) bits des error-handling und vieles mehr. Sie können auch in der Lage sein, es zu beschleunigen, durch die Vermeidung der Schaffung neuer byte-arrays, die alle die Zeit. Vorausgesetzt, Sie haben eine Obere Schranke, die alle Ihre Nachrichten werden unter:

void QuickAndDirtyAsciiEncode(string chars, byte[] buffer)
{
    int length = chars.Length;
    for (int i = 0; i < length; i++)
    {
        buffer[i] = (byte) (chars[i] & 0x7f);
    }
}

Würden Sie dann so etwas machen:

readonly byte[] Buffer = new byte[8192]; //Reuse this repeatedly
...
QuickAndDirtyAsciiEncode(text, Buffer);
//We know ASCII takes one byte per character
socket.Send(Buffer, text.Length, SocketFlags.None);

Dies ist ziemlich verzweifelt Optimierung obwohl. Würd ich mich mit ASCIIEncoding bis ich würde bewährte, dass dies der Engpass (oder zumindest, dass diese Art von grotty hack hilft nicht).

Die performance-Charakteristik, die die Durchführung eines general-purpose-memcpy library-Funktion mit einem SIMD-register ist deutlich bunter als eine entsprechende Implementierung mit einem general-purpose-register...

  ^{- Die Intel 64-und IA-32 Architectures Optimization Reference Manual
(April 2018) §3.7.6.1}

Für Schreiende Geschwindigkeit, mit der Umwandlung mittlere bis grössere Datenblöcke zwischen 8-bit - byte[] - und "wide" (16 bit, Unicode) text, werden Sie wollen prüfen, Lösungen bereitstellen, die SIMD Anweisungen PUNPCKLBW+PUNPCKHBW (Erweiterung) und PACKUSWB (Verengung). In .NET, diese sind neu verfügbar als x64 JIT intrinstics, emittiert für die hardware-beschleunigte System.Numerics Arten Vector und Vector<T> (siehe hier für mehr info). Die generische version Vector<T> definiert wird, in der System.Numerik.Vektoren - Paket, das derzeit noch unter Recht aktiver Entwicklung. Wie unten dargestellt, werden Sie wahrscheinlich auch die System.- Laufzeit.CompilerServices.Unsicher Paket, da dies am günstigsten gelegene SIMD-load/store-Technik empfohlen von der Vector<T> Autoren.

Die entsprechenden SIMD-Beschleunigung ist nur verfügbar für fähige CPUs in x64-Modus, aber sonst .NET bietet einen transparenten fallback-emulation, code in der System.Numerics.Vectors Bibliothek, damit der code hier zeigt sich hat in der Tat zuverlässig-Funktion, über die große .NETTO-ökosystem, möglicherweise mit reduzierter Leistung. Testen Sie den code unten dargestellt habe ich eine console-app auf die volle .NET Framework 4.7.2 ("desktop") in x64 (SIMD) und x86 (emuliert) - Modi.

Da würde ich nicht vorenthalten möchte jemand die Gelegenheit zum erlernen der einschlägigen Techniken, die ich verwenden werde Vector.Widen zu veranschaulichen, die byte[] zu char[] Richtung, in C# 7. Aus diesem Beispiel, tun das Gegenteil--ich.e, mit Vector.Narrow zur Umsetzung der Verengung Richtung-ist unkompliziert und Links als eine übung für den Leser.

Warnung:
Die Methoden, die hier vorgeschlagen werden, sind völlig Codierung-nicht bewusst, Sie einfach Streifen/erweitern--oder enger/erweitern--raw-bytes zu/von der raw-bytes ohne Rücksicht auf Charakter-mapping, text-encoding oder anderen linguistischen Eigenschaften. Wenn Verbreiterung, werden überzählige bytes werden auf null gesetzt, und wenn die Verengung, überschüssige bytes verworfen werden.

Andere haben über die zahlreiche Gefahren mit dieser Praxis verbunden, die auf dieser Seite und anderswo, also bitte sorgfältig Lesen und verstehen die Natur dieser operation vor der Prüfung, ob es für Ihre situation geeignet ist. Für Klarheit, inline-Validierung erstellte aus dem code-Beispiel unten dargestellt, aber so könnte Hinzugefügt werden, um die innerste Schleife mit minimaler Auswirkung auf die SIMD profitieren.

Sie wurden gewarnt. Obwohl nicht-SIMD-beschleunigt, kanonische Techniken mit einem geeigneten Encoding Instanz empfohlen für fast alle realistischen app-Szenarien. Obwohl die OP macht ja anfordern, die maximale Leistung (oder mehr offensichtlich, als ein letzter verzweifelter Versuch, die impfen gegen downvotes von der Verunglimpfung der Polizei), als Nächstes habe ich ordnungsgemäß zusammenzufassen, ist die richtige, sanktioniert Techniken, dass die Regel verwendet werden soll.

Erweitern, um ein byte-array ein .NET String ist, rufen Sie den GetString() - Methode auf einem geeigneten byte-orientierten Codierung Beispiel:

String Encoding.ASCII.GetString(byte[] bytes)

Zu eng .NET String zu einem (z.B. Ascii) byte-array, rufen die GetBytes() - Methode auf einem geeigneten byte-orientierten Codierung Beispiel:

byte[] Encoding.ASCII.GetBytes(char[] chars)

Ok, jetzt zum lustigen Teil-der extrem schnellen SIMD-fähigen ("vektorisiert") C# - code für "dumme" die Erweiterung des ein byte-array. Als Erinnerung, hier sind einige Abhängigkeiten, die referenziert werden soll:

//... 
using System.Numerics;                  //nuget: System.Numerics.Vectors
using System.Runtime.CompilerServices;  //nuget: System.Runtime.CompilerServices.Unsafe
//... 

Hier ist die öffentliche Einstiegspunkt wrapper-Funktion. Wenn Sie lieber eine version, die gibt char[] statt String, es ist am Ende von diesem post.

///<summary>
///'Widen' each byte in 'bytes' to 16-bits with no consideration for
///character mapping or encoding.
///</summary>
public static unsafe String ByteArrayToString(byte[] bytes)
{
    //note: possible zeroing penalty; consider buffer pooling or 
    //other ways to allocate target?
    var s = new String('\0', bytes.Length);

    if (s.Length > 0)
        fixed (char* dst = s)
        fixed (byte* src = bytes)
            widen_bytes_simd(dst, src, s.Length);
    return s;
}

Nächsten ist die wichtigste Arbeit Schleife. Beachten Sie die Prolog-Schleife, richtet mit dem Ziel, eine 16-byte-Speicher-Grenze, falls erforderlich, durch eine Byte für Byte untersucht das kopieren von bis zu 15 Quell-Byte. Dies gewährleistet die effiziente Bedienung der wichtigsten "quad-quadwise" - Schleife mit einer einzigen Paarung von SIMD - PUNPCKLBW/PUNPCKHBW Anweisungen, schreibt die 32-bytes auf einmal (16 Quelle Byte abgerufen werden und dann gespeichert als 16 wide-chars besetzen, 32 bytes). Pre-Ausrichtung, plus die Auswahl der dst Ausrichtung (im Gegensatz zu src) sind die offiziellen Empfehlungen von der Intel-Handbuch, die oben zitiert werden. Ebenso, ausgerichtet auf den Betrieb mit sich bringt, dass, wenn die main-Schleife abgeschlossen ist, wird die Quelle kann bis zu 15 Rest-trailing-bytes; diese sind abgeschlossen, die von einem kurzen Epilog Schleife.

static unsafe void widen_bytes_simd(char* dst, byte* src, int c)
{
    for (; c > 0 && ((long)dst & 0xF) != 0; c--)
        *dst++ = (char)*src++;

    for (; (c -= 0x10) >= 0; src += 0x10, dst += 0x10)
        Vector.Widen(Unsafe.AsRef<Vector<byte>>(src),
                     out Unsafe.AsRef<Vector<ushort>>(dst + 0),
                     out Unsafe.AsRef<Vector<ushort>>(dst + 8));

    for (c += 0x10; c > 0; c--)
        *dst++ = (char)*src++;
}

Das ist eigentlich alles dort ist zu ihm! Es funktioniert wie ein Charme und, wie Sie unten sehen werden, es bedeutet 'Schreien' wie angekündigt.

Aber zunächst durch das ausschalten der vs2017 debugger-option "Disable JIT-Optimierungen," wir können prüfen, die native SIMD instruction stream, die x64 JIT generiert für das 'release' - bauen auf .NET 4.7.2. Hier ist der relevante Teil der wichtigsten inneren Schleife, die Blasten durch die Daten 32-Byte zu einem Zeitpunkt. Beachten Sie, dass der JIT hat es geschafft, zu emittieren, die theoretisch minimale fetch/store-Muster.

L_4223  mov         rax,rbx  
L_4226  movups      xmm0,xmmword ptr [rax] ; fetch 16 bytes
L_4229  mov         rax,rdi  
L_422C  lea         rdx,[rdi+10h]  
L_4230  movaps      xmm2,xmm0  
L_4233  pxor        xmm1,xmm1  
L_4237  punpcklbw   xmm2,xmm1               ; interleave 8-to-16 bits (lo)
L_423B  movups      xmmword ptr [rax],xmm2  ; store 8 bytes (lo) to 8 wide chars (16 bytes)
L_423E  pxor        xmm1,xmm1  
L_4242  punpckhbw   xmm0,xmm1               ; interleave 8-to-16 bits (hi)
L_4246  movups      xmmword ptr [rdx],xmm0  ; store 8 bytes (hi) to 8 wide chars (16 bytes)
L_4249  add         rbx,10h  
L_424D  add         rdi,20h  
L_4251  add         esi,0FFFFFFF0h  
L_4254  test        esi,esi  
L_4256  jge         L_4223  
L_4258  ...

Performance-test-Ergebnisse:

Getestet habe ich die SIMD-code gegen vier andere Techniken, die die gleiche Funktion erfüllen. Für die .NET-Encoder aufgelistet, dies war ein Aufruf an die GetChars(byte[], int, int) Methode.

• naive C# - Implementierung eines unsicheren Schleife Byte für Byte untersucht
• .NET-Codierung für die "Windows-1252" codepage
• .NET-Codierung für ASCII -
• .NET-Codierung für UTF-8 (no BOM, nicht werfen)
• SIMD-code in diesem Artikel gezeigt

Den Tests enthalten identische Arbeit für alle und Validierung identische Ergebnisse aller Prüflinge. Test-bytes wurden zufällig und nur ASCII-( [0x01 - 0x7F] ) um sicherzustellen, dass das identische Ergebnis aus allen test-Einheiten. Input size zufällig war, maximal 1 MB mit einem log₂ bias in Richtung zu den kleineren Größen, so dass die Durchschnittliche Größe war etwa 80K.

Für die Schönheit, die Reihenfolge der Ausführung wurde systematisch gedreht durch die 5 Einheiten, die für jede iteration. Für warmup, timings wurden verworfen, und auf null zurückgesetzt, sobald bei iteration 100. Die Testumgebung nicht durchführen, gehen alle Zuordnungen, die während der test-phase und eine volle GC ist gezwungen und erwartete jeder 10000 Iterationen.

 Relative Zecken, normiert auf bestes Ergebnis 
.NET Framework 4.7.3056.0 (x64-release) 
iter naiv win-1252-ascii-utf-8 simd 
------- ----------- ------------ ------------ ------------ ----------- 
10000 | 131.5 294.5 186.2 145.6 100.0 
20000 | 137.7 305.3 191.9 149.4 100.0 
30000 | 139.2 308.5 195.8 151.5 100.0 
40000 | 141.8 312.1 198.5 153.2 100.0 
50000 | 142.0 313.8 199.1 154.1 100.0 
60000 | 140.5 310.6 196.7 153.0 100.0 
70000 | 141.1 312.9 197.3 153.6 100.0 
80000 | 141.6 313.7 197.8 154.1 100.0 
90000 | 141.3 313.7 197.9 154.3 100.0 
100000 | 141.1 313.3 196.9 153.7 100.0 

gcServer=False; LatencyMode.Interactive; Vector.IsHardwareAccelerated=True 

Auf die bevorzugte x64 Plattform, wenn der JIT-Optimierung aktiviert ist und SIMD verfügbar ist, es war kein Wettbewerb. Die SIMD-code ausgeführt wird, der über 150% schneller als die nächsten Konkurrenten. Die Encoding.Default, die in der Regel "Windows-1252" codepage, durchgeführt besonders schlecht, etwa 3x langsamer als die SIMD-code.

Ich habe bereits erwähnt, dass die Verteilung der Testdaten Größen stark war, log-in Richtung null. Ohne diesen Schritt-das bedeutet eine gleichmäßige Verteilung der Größen von 0 bis 1.048.576 bytes (Durchschnittliche test-Größe 512K)--SIMD weiterhin schneller als das pack mit allen anderen Geräten geht relativ schlimmer vs. den oben angezeigten code.

naiv 153.45% 
win-1252 358.84% 
ascii-221.38% 
utf-8 161.62% 
simd 100.00% 

Als für die nicht-SIMD - (emulation) Fall, UTF-8 und SIMD sind extrem nahe beieinander-in der Regel innerhalb von 3-4% jeder andere-und weit besser als der rest. Ich fand dieses Ergebnis ist doppelt verwunderlich: dass die Bei UTF8Encoding-source-code war so schnell (viele fast-path-Optimierung), und dann auch, dass der general-purpose-SIMD-Emulations-code war in der Lage, mit dazu abgestimmten code.

Nachtrag:

In dem obigen code, den ich erwähnte, eine mögliche O(n) Leistungseinbußen (im Zusammenhang mit überschuss-re-Nullung) von der Nutzung der new String(Char,int) Konstruktor eine Zuordnung der Ziel-string. Der Vollständigkeit halber, hier ist ein alternativer Einstiegspunkt, das könnte das problem vermeiden, indem anstelle der Rückgabe der verbreiterten Daten als ushort[]:

///<summary>
///'Widen' each byte in 'bytes' to 16-bits with no consideration for
///character mapping or encoding
///</summary>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static unsafe char[] WidenByteArray(byte[] bytes)
{
    var rgch = new char[bytes.Length];
    if (rgch.Length > 0)
        fixed (char* dst = rgch)
        fixed (byte* src = bytes)
            widen_bytes_simd(dst, src, rgch.Length);
    return rgch;
}

Stell ich mir die GetBytes () - Funktion ist schon gut optimiert ist für diese. Ich kann nicht glauben, Vorschläge zur Verbesserung der Geschwindigkeit Ihres bestehenden code.

BEARBEITEN -- wissen Sie, ich weiß nicht, ob das schneller ist oder nicht. Aber hier ist ein anderes Verfahren unter Verwendung der BinaryFormatter:

BinaryFormatter bf = new BinaryFormatter();
MemoryStream ms = new MemoryStream();
bf.Serialize(ms, someString);
byte[] bytes =  ms.ToArray();
ms.Close();
socket.Send(bytes);

Der Grund, warum ich denke, das könnte schneller ist, dass es überspringt die Codierung Schritt. Ich bin mir auch nicht ganz sicher, dass diese ordnungsgemäß funktionieren. Aber man könnte versuchen es und sehen. Natürlich, wenn Sie die ascii-Codierung, dann wird das nicht helfen.

Ich hatte gerade einen anderen Gedanken. Ich glaube, dieser code würde zurückgeben, die doppelte Anzahl von bytes als mit GetBytes mit ASCII-Codierung. Der Grund dafür ist, dass alle Zeichenfolgen in .NET use unicode-hinter den kulissen. Und natürlich Unicode 2 bytes pro Zeichen verwendet, in der Erwägung, dass ASCII verwendet nur 1. Also der BinaryFormatter ist wahrscheinlich nicht das, was zu verwenden, in diesem Fall, weil Sie würde eine Verdoppelung der Menge an Daten, die Sie senden über den socket.

Wie schon andere gesagt haben, die Encoding-Klasse ist bereits optimiert für diese Aufgabe, so wird es wahrscheinlich schwer sein, um es schneller zu machen. Es gibt eine Mikro-Optimierung, dass Sie tun können : verwenden Sie Encoding.ASCII eher als new ASCIIEncoding(). Aber wie jeder weiß, Mikro-Optimierungen sind schlecht 😉

Nur noch ein Tipp : ich weiß nicht, wie man erstellen Sie Ihre ersten Saiten, aber denken Sie daran, dass die Klasse StringBuilder.Append("irgendwas") ist wirklich schneller als so etwas wie myString += "etwas".

In den gesamten Prozess der Erstellung des strings, und sendet Sie über eine socket-Verbindung, ich wäre überrascht, wenn der Engpass war die Konvertierung von Strings in byte-arrays. Aber ich bin sehr daran interessiert, wenn jemand dies testen, mit einem profiler.

Ben