c# - solido - ssd vs hdd

¿El paralelismo de E/S de C#aumenta el rendimiento con SSD?

Question

He leído algunas respuestas (por example ) aquí en SO donde algunos dicen que el paralelismo no va a aumentar el rendimiento (tal vez en lectura IO).

Pero he creado algunas pruebas que muestran que también las operaciones de ESCRITURA son mucho más rápidas.

- LEER PRUEBA:

He creado archivos 6000 aleatorios con datos ficticios:

Intentemos leerlos sin paralelismo:

var files =
    Directory.GetFiles("c://temp//2//", "*.*", SearchOption.TopDirectoryOnly).Take(1000).ToList();

    var sw = Stopwatch.StartNew();
    files.ForEach(f => ReadAllBytes(f).GetHashCode()); 
    sw.ElapsedMilliseconds.Dump("Run READ- Serial");
    sw.Stop(); 


    sw.Restart();
    files.AsParallel().ForAll(f => ReadAllBytes(f).GetHashCode()); 
    sw.ElapsedMilliseconds.Dump("Run READ- Parallel");
    sw.Stop();

Resultado 1:

Ejecutar LEER- Serial 595

Ejecutar LEER- Paralelo 193

Resultado2:

Ejecutar LEER- Serial 316

Ejecutar leer-paralelo 192

- PRUEBA DE ESCRITURA:

Vamos a crear 1000 archivos aleatorios donde cada archivo es de 300K. (He vaciado el directorio de la prueba anterior)

var bytes = new byte[300000];
Random r = new Random();
r.NextBytes(bytes);
var list = Enumerable.Range(1, 1000).ToList();

sw.Restart();
list.ForEach((f) => WriteAllBytes(@"c://temp//2//" + Path.GetRandomFileName(), bytes)); 
sw.ElapsedMilliseconds.Dump("Run WRITE serial");
sw.Stop();

sw.Restart();
list.AsParallel().ForAll((f) => WriteAllBytes(@"c://temp//2//" + 
Path.GetRandomFileName(), bytes)); 
sw.ElapsedMilliseconds.Dump("Run  WRITE Parallel");
sw.Stop();

Resultado 1:

Ejecutar WRITE serie 2028

Ejecutar WRITE Parallel 368

Resultado 2:

Ejecutar WRITE serie 784

Ejecutar WRITE Paralelo 426

Pregunta:

Los resultados me han sorprendido. Está claro que, en contra de todas las expectativas (especialmente con las operaciones WRITE), el rendimiento es mejor con el paralelismo, pero con las operaciones IO.

¿Cómo / por qué vienen los resultados del paralelismo mejor? Parece que el SSD puede funcionar con subprocesos y que no hay / hay menos cuello de botella cuando se ejecuta más de un trabajo a la vez en el dispositivo IO.

Nb No lo probé con HDD (me alegrará que uno que tenga HDD realice las pruebas).

Answer 1

¡Es un tema muy interesante! Lamento no poder explicar los detalles técnicos, pero hay algunas preocupaciones que deben plantearse. Es un poco largo, así que no puedo incluirlos en el comentario. Por favor, perdóname para publicarlo como una "respuesta".

Creo que debe pensar tanto en archivos grandes como pequeños, además, la prueba debe ejecutarse varias veces y obtener el tiempo promedio para asegurarse de que el resultado sea verificable. Una guía general es ejecutarlo 25 veces como sugiere un artículo en computación evolutiva.

Otra preocupación es sobre el almacenamiento en caché del sistema. Solo creó un búfer de bytes y siempre escribe lo mismo, no sé cómo el sistema maneja el búfer, pero para minimizar la diferencia, le sugiero que cree un búfer diferente para diferentes archivos.

(Actualización: tal vez GC también afecte el rendimiento, así que revisé nuevamente para dejar de lado GC tanto como pude).

Afortunadamente, tengo tanto SSD como HDD en mi computadora y revisé el código de prueba. Lo ejecuté con diferentes configuraciones y obtuve los siguientes resultados. Espero poder inspirar a alguien para una mejor explicación.

1KB, 256 Archivos

Avg Write Parallel SSD: 46.88
Avg Write Serial   SSD: 94.32
Avg Read  Parallel SSD: 4.28
Avg Read  Serial   SSD: 15.48
Avg Write Parallel HDD: 35.4
Avg Write Serial   HDD: 71.52
Avg Read  Parallel HDD: 4.52
Avg Read  Serial   HDD: 14.68

512KB, 256 Archivos

Avg Write Parallel SSD: 86.84
Avg Write Serial   SSD: 210.84
Avg Read  Parallel SSD: 65.64
Avg Read  Serial   SSD: 80.84
Avg Write Parallel HDD: 85.52
Avg Write Serial   HDD: 186.76
Avg Read  Parallel HDD: 63.24
Avg Read  Serial   HDD: 82.12
// Note: GC seems still kicked in the parallel reads on this test

Mi máquina es: i7-6820HQ / 32G / Windows 7 Enterprise x64 / VS2017 Professional / Target .NET 4.6 / Se ejecuta en modo de depuración.

Los dos discos duros son:

Unidad C: IDE / Crucial_CT275MX300SSD4 ___________________ M0CR021

Unidad D: IDE / ST2000LM003_HN-M201RAD __________________ 2BE10001

El código revisado es el siguiente:

Stopwatch sw = new Stopwatch();
string path;
int fileSize = 1024 * 1024 * 1024;
int numFiles = 2;

byte[] bytes = new byte[fileSize];
Random r = new Random(DateTimeOffset.UtcNow.Millisecond);
List<int> list = Enumerable.Range(0, numFiles).ToList();
List<List<byte>> allBytes = new List<List<byte>>(numFiles);

List<string> files;

int numTests = 1;

List<long> wss = new List<long>(numTests);
List<long> wps = new List<long>(numTests);
List<long> rss = new List<long>(numTests);
List<long> rps = new List<long>(numTests);

List<long> wsh = new List<long>(numTests);
List<long> wph = new List<long>(numTests);
List<long> rsh = new List<long>(numTests);
List<long> rph = new List<long>(numTests);

Enumerable.Range(1, numTests).ToList().ForEach((i) => {
    path = @"C:/SeqParTest/";

    allBytes.Clear();
    GC.Collect();
    GC.WaitForFullGCComplete();
    list.ForEach((x) => { r.NextBytes(bytes); allBytes.Add(new List<byte>(bytes)); });
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    list.AsParallel().ForAll((x) => File.WriteAllBytes(path + Path.GetRandomFileName(), allBytes[x].ToArray()));
    wps.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    Debug.Print($"Write parallel SSD #{i}: {wps[i - 1]}");

    allBytes.Clear();
    GC.Collect();
    GC.WaitForFullGCComplete();
    list.ForEach((x) => { r.NextBytes(bytes); allBytes.Add(new List<byte>(bytes)); });
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    list.ForEach((x) => File.WriteAllBytes(path + Path.GetRandomFileName(), allBytes[x].ToArray()));
    wss.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    Debug.Print($"Write serial   SSD #{i}: {wss[i - 1]}");

    files = Directory.GetFiles(path, "*.*", SearchOption.TopDirectoryOnly).Take(numFiles).ToList();
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    files.AsParallel().ForAll(f => File.ReadAllBytes(f).GetHashCode());
    rps.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    files.ForEach(f => File.Delete(f));
    Debug.Print($"Read  parallel SSD #{i}: {rps[i - 1]}");
    GC.Collect();
    GC.WaitForFullGCComplete();

    files = Directory.GetFiles(path, "*.*", SearchOption.TopDirectoryOnly).Take(numFiles).ToList();
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    files.ForEach(f => File.ReadAllBytes(f).GetHashCode());
    rss.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    files.ForEach(f => File.Delete(f));
    Debug.Print($"Read  serial   SSD #{i}: {rss[i - 1]}");
    GC.Collect();
    GC.WaitForFullGCComplete();

    path = @"D:/SeqParTest/";

    allBytes.Clear();
    GC.Collect();
    GC.WaitForFullGCComplete();
    list.ForEach((x) => { r.NextBytes(bytes); allBytes.Add(new List<byte>(bytes)); });
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    list.AsParallel().ForAll((x) => File.WriteAllBytes(path + Path.GetRandomFileName(), allBytes[x].ToArray()));
    wph.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    Debug.Print($"Write parallel HDD #{i}: {wph[i - 1]}");

    allBytes.Clear();
    GC.Collect();
    GC.WaitForFullGCComplete();
    list.ForEach((x) => { r.NextBytes(bytes); allBytes.Add(new List<byte>(bytes)); });
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    list.ForEach((x) => File.WriteAllBytes(path + Path.GetRandomFileName(), allBytes[x].ToArray()));
    wsh.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    Debug.Print($"Write serial   HDD #{i}: {wsh[i - 1]}");

    files = Directory.GetFiles(path, "*.*", SearchOption.TopDirectoryOnly).Take(numFiles).ToList();
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    files.AsParallel().ForAll(f => File.ReadAllBytes(f).GetHashCode());
    rph.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    files.ForEach(f => File.Delete(f));
    Debug.Print($"Read  parallel HDD #{i}: {rph[i - 1]}");
    GC.Collect();
    GC.WaitForFullGCComplete();

    files = Directory.GetFiles(path, "*.*", SearchOption.TopDirectoryOnly).Take(numFiles).ToList();
    try { GC.TryStartNoGCRegion(0, true); } catch (Exception) { }
    sw.Restart();
    files.ForEach(f => File.ReadAllBytes(f).GetHashCode());
    rsh.Add(sw.ElapsedMilliseconds);
    sw.Stop();
    try { GC.EndNoGCRegion(); } catch (Exception) { }
    files.ForEach(f => File.Delete(f));
    Debug.Print($"Read  serial   HDD #{i}: {rsh[i - 1]}");
    GC.Collect();
    GC.WaitForFullGCComplete();
});

Debug.Print($"Avg Write Parallel SSD: {wps.Average()}");
Debug.Print($"Avg Write Serial   SSD: {wss.Average()}");
Debug.Print($"Avg Read  Parallel SSD: {rps.Average()}");
Debug.Print($"Avg Read  Serial   SSD: {rss.Average()}");

Debug.Print($"Avg Write Parallel HDD: {wph.Average()}");
Debug.Print($"Avg Write Serial   HDD: {wsh.Average()}");
Debug.Print($"Avg Read  Parallel HDD: {rph.Average()}");
Debug.Print($"Avg Read  Serial   HDD: {rsh.Average()}");

Bueno, no he probado completamente el código, por lo que puede tener errores. Me di cuenta de que a veces se detiene en la lectura paralela. Supongo que se debió a que la eliminación de los archivos de la lectura secuencial se completó DESPUÉS de leer la lista de archivos existentes en el siguiente paso, por lo que se queja de que el archivo no encontró un error.

Otro problema es que usé los archivos recién creados para la prueba de lectura. Teóricamente, es mejor no hacerlo (incluso reiniciar la computadora / completar el espacio vacío en el SSD para evitar el almacenamiento en caché), pero no me molesté porque la comparación prevista es entre el rendimiento secuencial y el paralelo.

Actualizar:

No sé cómo explicar el motivo, pero creo que puede deberse a que el recurso de IO está bastante inactivo. Voy a intentar dos cosas la siguiente:

1. Archivos grandes (1GB) en serie / paralelo
2. Cuando otras actividades de fondo utilizan el disco IO.

Actualización 2:

Algunos resultados de archivos grandes (512M, 32 archivos):

Write parallel SSD #1: 140935
Write serial   SSD #1: 133656
Read  parallel SSD #1: 62150
Read  serial   SSD #1: 43355
Write parallel HDD #1: 172448
Write serial   HDD #1: 138381
Read  parallel HDD #1: 173436
Read  serial   HDD #1: 142248

Write parallel SSD #2: 122286
Write serial   SSD #2: 119564
Read  parallel SSD #2: 53227
Read  serial   SSD #2: 43022
Write parallel HDD #2: 175922
Write serial   HDD #2: 137572
Read  parallel HDD #2: 204972
Read  serial   HDD #2: 142174

Write parallel SSD #3: 121700
Write serial   SSD #3: 117730
Read  parallel SSD #3: 107546
Read  serial   SSD #3: 42872
Write parallel HDD #3: 171914
Write serial   HDD #3: 145923
Read  parallel HDD #3: 193097
Read  serial   HDD #3: 142211

Write parallel SSD #4: 125805
Write serial   SSD #4: 118252
Read  parallel SSD #4: 113385
Read  serial   SSD #4: 42951
Write parallel HDD #4: 176920
Write serial   HDD #4: 137520
Read  parallel HDD #4: 208123
Read  serial   HDD #4: 142273

Write parallel SSD #5: 116394
Write serial   SSD #5: 116592
Read  parallel SSD #5: 61273
Read  serial   SSD #5: 43315
Write parallel HDD #5: 172259
Write serial   HDD #5: 138554
Read  parallel HDD #5: 275791
Read  serial   HDD #5: 142311

Write parallel SSD #6: 107839
Write serial   SSD #6: 135071
Read  parallel SSD #6: 79846
Read  serial   SSD #6: 43328
Write parallel HDD #6: 176034
Write serial   HDD #6: 138671
Read  parallel HDD #6: 218533
Read  serial   HDD #6: 142481

Write parallel SSD #7: 120438
Write serial   SSD #7: 118032
Read  parallel SSD #7: 45375
Read  serial   SSD #7: 42978
Write parallel HDD #7: 173151
Write serial   HDD #7: 140579
Read  parallel HDD #7: 176492
Read  serial   HDD #7: 142153

Write parallel SSD #8: 108862
Write serial   SSD #8: 123556
Read  parallel SSD #8: 120162
Read  serial   SSD #8: 42983
Write parallel HDD #8: 174699
Write serial   HDD #8: 137619
Read  parallel HDD #8: 204069
Read  serial   HDD #8: 142480

Write parallel SSD #9: 111618
Write serial   SSD #9: 117854
Read  parallel SSD #9: 51224
Read  serial   SSD #9: 42970
Write parallel HDD #9: 173069
Write serial   HDD #9: 136936
Read  parallel HDD #9: 159978
Read  serial   HDD #9: 143401

Write parallel SSD #10: 115381
Write serial   SSD #10: 118545
Read  parallel SSD #10: 79509
Read  serial   SSD #10: 43818
Write parallel HDD #10: 179545
Write serial   HDD #10: 138556
Read  parallel HDD #10: 167978
Read  serial   HDD #10: 143033

Write parallel SSD #11: 113105
Write serial   SSD #11: 116849
Read  parallel SSD #11: 84309
Read  serial   SSD #11: 42620
Write parallel HDD #11: 179432
Write serial   HDD #11: 139014
Read  parallel HDD #11: 219161
Read  serial   HDD #11: 142515

Write parallel SSD #12: 124901
Write serial   SSD #12: 121769
Read  parallel SSD #12: 137192
Read  serial   SSD #12: 43144
Write parallel HDD #12: 176091
Write serial   HDD #12: 139042
Read  parallel HDD #12: 214205
Read  serial   HDD #12: 142576

Write parallel SSD #13: 110896
Write serial   SSD #13: 123152
Read  parallel SSD #13: 56633
Read  serial   SSD #13: 42665
Write parallel HDD #13: 173123
Write serial   HDD #13: 138514
Read  parallel HDD #13: 210003
Read  serial   HDD #13: 142215

Write parallel SSD #14: 117762
Write serial   SSD #14: 126865
Read  parallel SSD #14: 90005
Read  serial   SSD #14: 44089
Write parallel HDD #14: 172958
Write serial   HDD #14: 139908
Read  parallel HDD #14: 217826
Read  serial   HDD #14: 142216

Write parallel SSD #15: 109912
Write serial   SSD #15: 121276
Read  parallel SSD #15: 72285
Read  serial   SSD #15: 42827
Write parallel HDD #15: 176255
Write serial   HDD #15: 139084
Read  parallel HDD #15: 183926
Read  serial   HDD #15: 142111

Write parallel SSD #16: 122476
Write serial   SSD #16: 126283
Read  parallel SSD #16: 47875
Read  serial   SSD #16: 43799
Write parallel HDD #16: 173436
Write serial   HDD #16: 137203
Read  parallel HDD #16: 294374
Read  serial   HDD #16: 142387

Write parallel SSD #17: 112168
Write serial   SSD #17: 121079
Read  parallel SSD #17: 79001
Read  serial   SSD #17: 43207

Lamento no tener tiempo para completar las 25 ejecuciones, pero el resultado muestra en archivos grandes que el R / W secuencial podría ser más rápido que en paralelo si el uso del disco está completo. Creo que puede ser la razón de otras discusiones sobre SO.

Answer 2

La evaluación comparativa es un arte difícil, simplemente no estás midiendo lo que crees que eres. El hecho de que no sea realmente una sobrecarga de E / S es algo obvio en los resultados de la prueba, ¿por qué el código de un solo hilo es más rápido la segunda vez que lo ejecuta?

Lo que no está contando es el comportamiento de la caché del sistema de archivos . Mantiene una copia del contenido del disco en la memoria RAM. Esto tiene un impacto particularmente grande en la medición de código de subprocesos múltiples, ya que no utiliza ninguna E / S en absoluto . En una palabra:

• Las lecturas provienen de la memoria RAM si la memoria caché del sistema de archivos tiene una copia de los datos. Esto funciona a velocidades de bus de memoria, normalmente alrededor de 35 gigabytes / segundo. Si no tiene una copia, la lectura se retrasa hasta que el disco suministre los datos. No se limita a leer el clúster solicitado, sino una cantidad completa de datos del disco.

• Las escrituras van directamente a la memoria RAM, se completa muy rápidamente. Los datos se escriben perezosamente en el disco en segundo plano mientras el programa se sigue ejecutando, optimizado para minimizar el movimiento de la cabeza de escritura en el orden de los cilindros. Solo si no hay más RAM disponible, una escritura se detendrá alguna vez.

El tamaño real de la memoria caché depende de la cantidad de RAM instalada y de la necesidad de RAM impuesta por los procesos en ejecución. Una guía muy aproximada es que puede contar con 1 GB en una máquina con 4 GB de RAM, 3 GB en una máquina con 8 GB de RAM. Es visible en el Monitor de recursos, en la pestaña Memoria, se muestra como el valor "En caché". Tenga en cuenta que es altamente variable.

Lo suficiente para dar sentido a lo que ve, los beneficios de la prueba paralela en gran medida de la prueba en serie ya han leído todos los datos. Si hubiera escrito la prueba para que la prueba paralela se ejecutara primero, entonces habría obtenido resultados muy diferentes. Solo si el caché está frío podría ver la pérdida de rendimiento debido a los subprocesos. Tendrías que reiniciar tu máquina para asegurar esa condición. O lea otro archivo muy grande primero, lo suficientemente grande como para expulsar datos útiles de la memoria caché.

Solo si tiene un conocimiento a priori de su programa que solo haya leído datos recién escritos, podrá usar los hilos de forma segura sin riesgo de pérdida de rendimiento. Esa garantía es normalmente bastante difícil de conseguir. Sí existe, un buen ejemplo es que Visual Studio está construyendo tu proyecto. El compilador escribe el resultado de la compilación en el directorio obj / Debug, luego MSBuild lo copia en bin / Debug. Parece muy inútil, pero no lo es, esa copia siempre se completará muy rápidamente ya que el archivo está caliente en la caché. La memoria caché también explica la diferencia entre un inicio en frío y un inicio en caliente de un programa .NET y por qué no siempre es mejor usar NGen.

Answer 3

La razón de este comportamiento se llama File Caching, que es una característica de Windows para mejorar el rendimiento de las operaciones de archivos. Echemos un vistazo a una breve explicación en el Centro de desarrollo de Windows :

De forma predeterminada, Windows almacena en caché los datos de archivos que se leen de los discos y se escriben en ellos. Esto implica que las operaciones de lectura leen datos de archivos de un área en la memoria del sistema conocida como el caché de archivos del sistema, en lugar de hacerlo desde el disco físico.

Esto significa que el disco duro (normalmente) nunca se utiliza durante sus pruebas.

Podemos evitar este comportamiento creando un FileStream usando el indicador FILE_FLAG_NO_BUFFERING , documentado en el MSDN . Echemos un vistazo a nuestra nueva función ReadUnBuffered usando este indicador:

private static object ReadUnbuffered(string f)
{
    //Unbuffered read and write operations can only
    //be performed with blocks having a multiple
    //size of the hard drive sector size
    byte[] buffer = new byte[4096 * 10];
    const ulong FILE_FLAG_NO_BUFFERING = 0x20000000;
    using (FileStream fs = new FileStream(
        f,
        FileMode.Open,
        FileAccess.Read,
        FileShare.None,
        8,
        (FileOptions)FILE_FLAG_NO_BUFFERING))
    {
        return fs.Read(buffer, 0, buffer.Length);
    }
}

El resultado: la lectura en serie es mucho más rápida. En mi caso, incluso casi el doble de rápido.

La lectura de un archivo utilizando el caché estándar de Windows solo tiene que realizar operaciones de CPU y RAM para administrar el chaching de archivos, lidiar con FileStream , ... porque los archivos ya están almacenados en caché. Claro, no requiere mucha CPU pero no es despreciable. Como los archivos ya están en la memoria caché del sistema, el enfoque paralelo (sin modificación de la memoria caché) muestra exactamente el tiempo de estas operaciones generales .

Este comportamiento también se puede transferir a operaciones de escritura.

Answer 4

Primero, la prueba debe excluir cualquier operación de CPU / RAM (GetHashCode) ya que el código de serie puede estar esperando a la CPU antes de realizar la siguiente operación de disco.

Internamente, un SSD siempre está tratando de paralizar las operaciones entre sus diferentes chips internos. Su capacidad para hacerlo depende del modelo, de la cantidad de espacio libre (TRIMmed) que tiene, etc. Hasta hace un tiempo, esto debería comportarse igual en paralelo y en serie, porque la cola entre el SO y el SSD es en serie de todos modos ... A menos que el SSD sea compatible con NCQ (cola de comandos nativos), que permite al SSD seleccionar qué operación de la cola realizar a continuación, para maximizar el uso de todos sus chips. Entonces, lo que está viendo podría ser los beneficios de NCQ. (Tenga en cuenta que NCQ también funciona para unidades de disco duro).

Debido a las diferencias entre los SSD (estrategia del controlador, número de chips internos, espacio libre, etc.) los beneficios de la paralelización probablemente varíen mucho.