Ejecutar una simulación en Ubuntu puro vs en Ubuntu en Windows (WSL)

15

Me gustaría hacer una pregunta sobre cómo probar una simulación CAE grande en la misma computadora en las siguientes dos situaciones.

Sistema Ubuntu puro
Sistema Ubuntu en Windows 10 (WSL)

¿Las velocidades de cálculo en ambos casos son casi iguales o son diferentes?

windows windows-subsystem-for-linux benchmarks

— ABCDEMMM
fuente

44

Sin conocer la naturaleza de la simulación, esto es imposible de responder.

— muru

1

@muru: No es que vaga. Una "simulación" es presumiblemente un trabajo en segundo plano computacionalmente intensivo, lo que lo convierte en CPU o en memoria. (Las E / S de disco o red también pueden ser un cuello de botella, pero eso es algo que las personas que escriben tales programas tienden a evitar, y algunos códigos de simulación modernos incluso pueden usar la GPU para el cálculo en paralelo). Uno podría escribir (o descargar) fácilmente un punto de referencia que prueba todos estos 2 a 5 posibles cuellos de botella y verifica si hay alguna diferencia significativa entre WSL y Ubuntu nativo para alguno de ellos. Lo haría, pero no tengo WSL (o Windows 10) disponible.

— Ilmari Karonen

3

@IlmariKaronen "presumiblemente". Dependiendo de los datos traídos, podría ser muy intensivo en IO incluso si la CPU está vinculada. Y el resto de su comentario es una razón bastante buena para cerrar esto: no tenemos idea de qué combinación posible de cuellos de botella importa aquí.

— muru

1

Bueno, publiqué una respuesta, ya que resulta que los puntos de referencia adecuados ya están en línea . Obviamente, no puedo decir con certeza si el código de simulación específico del OP se ejecutará más lentamente en WSL o no; pero en cualquier caso, una respuesta a esa pregunta no sirve de nada a nadie más que al OP de todos modos. Lo que puedo responder, en función de los puntos de referencia, es qué tipos de código de simulación podrían esperarse razonablemente que tengan diferencias de rendimiento entre WSL y Linux nativo.

— Ilmari Karonen

@muru, es una simulación CAE (Abaqus CAE).

— ABCDEMMM

18

Es muy probable que su software de simulación esté vinculado a la CPU o a la memoria . Para tales cargas de trabajo, no se vería ninguna diferencia significativa entre ejecutar el código en "bare metal" o dentro de WSL (o cualquier otra capa de compatibilidad o VM que use ejecución nativa), ya que en cualquier caso el sistema operativo está en su mayoría en espera mientras que el código de simulación se ejecuta directamente en la CPU.

Sin embargo, también es posible que su simulación esté al menos parcialmente vinculada a E / S, y ahí es donde pueden surgir diferencias. Aparentemente, WSL (actualmente) tiene una capa de interfaz de sistema de archivos bastante lenta que puede ralentizar significativamente la E / S del disco. * Dicho esto, mientras que la E / S del disco puede ser el principal cuello de botella para muchos tipos de tareas de procesamiento de datos en masa, una "simulación" por lo general, no debería pasar la mayor parte de su tiempo leyendo y escribiendo archivos. Si lo es, puede considerar ejecutarlo desde un disco RAM (por ejemplo, tmpfs en Linux ** nativo) para evitar el acceso innecesario al disco físico.

En cualquier caso, la única forma de estar seguro es probar su simulación en ambos entornos y determinar el tiempo que tarda en ejecutarse. Sin embargo, antes de hacer eso, es posible que desee echar un vistazo a los puntos de referencia existentes, como este punto de referencia de rendimiento WSL vs.Docker vs.VirtualBox vs.Native Linux de Phoronix a partir de febrero de 2018 , y examinar los resultados para cualquier prueba que enfatice los mismos componentes. del sistema como lo hace tu simulación.

(FWIW, los resultados de Phoronix parecen coincidir en su mayoría con los principios generales que describí anteriormente, aunque hay algunas rarezas notables como VirtualBox que aparentemente superan al Linux nativo en algunos puntos de referencia vinculados de E / S, aparentemente debido a que su disco virtual no siempre sincroniza los datos de inmediato en el disco físico. Un problema potencialmente relevante que no pude notar anteriormente es que los puntos de referencia muestran diferencias significativas en el rendimiento de OpenMP de subprocesos múltiples entre los diferentes entornos host y también entre diferentes distribuciones de Linux, incluso cuando se ejecuta en hardware desnudo. eso no es demasiado sorprendente, ya que el kernel maneja el subprocesamiento y el IPC. Supongo que gran parte de la diferencia entre las distribuciones allí puede deberse a diferentes parámetros de ajuste del kernel en tiempo de ejecución y / o tiempo de compilación).

^{*) De acuerdo con esta entrada del blog de MSDN a partir de 2016, en realidad hay dos componentes de la interfaz del sistema de ficheros en WSL: volfs, que emula la semántica del sistema de archivos nativo de Linux sobre NTFS y se utiliza para montar por ejemplo, /y /home, y DrvFs, que proporciona la mayoría de Windows-como la semántica y se usa para acceder a las unidades de Windows del host a través de /mnt/cetc. Si su software no requiere específicamente características nativas del sistema de archivos de Linux como múltiples enlaces duros al mismo archivo, configurarlo para almacenar sus archivos de datos en una carpeta DrvFs puede mejorar el rendimiento del acceso a archivos en WSL.}

^{**) Según este hilo de Reddit de mayo de 2017, "tmpfs se emula actualmente usando el disco" en WSL. A menos que algo haya cambiado en el último año, esto presumiblemente significa que el uso de tmpfs en WSL no ofrece ningún beneficio de rendimiento sobre el uso de un sistema de archivos normal en el disco.}

— Ilmari Karonen
fuente

Quizás no solo los parámetros de ajuste, sino también las opciones del compilador (por ejemplo, -O3 -march=haswello algo así. No sé qué Clear Linux realmente usa para construir sus núcleos, pero tal vez BMI2 / popcnt/ lo que sea podría hacer una diferencia medible en glibc y el núcleo. (El núcleo ganó Sin embargo, no se beneficie de AVX, porque el núcleo evita tocar registros de FPU excepto en un código específico como los datos de corrección de errores RAID5 / 6 del software.)

— Peter Cordes

12

Ubuntu en Windows (WSL - 2017 Fall Creators Update) es definitivamente más lento que Ubuntu "puro" en el entorno Linux.

Por ejemplo, la pintura de pantalla tarda muchas veces más en Windows 10 en comparación con Ubuntu 16.04, es decir, puede ver el movimiento del cursor en Windows 10:

La pantalla de inicio de WSL Bash tarda unos 5 segundos en pintarse. En comparación, es aproximadamente 1 1/2 segundos para la misma pantalla de inicio en Ubuntu 16.04:

Benchmarking de CPU

La primera sección muestra cuán lenta es la E / S de pantalla, pero ¿qué pasa con el benchmarking de CPU?

A partir de esta Pregunta y Preguntas de Ubuntu: Utilidad de evaluación comparativa de CPU para Linux , ejecuté pruebas en Ubuntu 16.04 en Linux y Windows. En Linux unos 24 segundos en Windows 10 versión 1709 unos 31 segundos. Linux es 6 segundos más rápido o aproximadamente un 25% más rápido. Sin embargo, acabo de actualizar Windows 10 a la versión 1803 (actualización de Redstone 4, también conocida como Spring Creators April 2018) y tardó 24 segundos, lo mismo que Linux.

Ubuntu 16.04 en Linux

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.5065s
    total number of events:              10000
    total time taken by event execution: 23.5049
    per-request statistics:
         min:                                  2.13ms
         avg:                                  2.35ms
         max:                                  8.52ms
         approx.  95 percentile:               2.76ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.5049/0.00

Ubuntu 16.04 en Windows 10 compilación 1709

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          30.5350s
    total number of events:              10000
    total time taken by event execution: 30.5231
    per-request statistics:
         min:                                  2.37ms
         avg:                                  3.05ms
         max:                                  6.21ms
         approx.  95 percentile:               4.01ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   30.5231/0.00

Ubuntu 16.04 en Windows 10 compilación 1803

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.7223s
    total number of events:              10000
    total time taken by event execution: 23.7155
    per-request statistics:
         min:                                  2.21ms
         avg:                                  2.37ms
         max:                                  4.53ms
         approx.  95 percentile:               2.73ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.7155/0.00

NOTA: La actualización de primavera de Windows 10 para 2018 (denominada Redstone 4 ) salió el 9 de mayo (hace 4 días) y la instalaré pronto para ver las mejoras. Sin duda hay muchos. Una de las que sé que me interesa es la capacidad de ejecutar crontrabajos en el inicio. Lo necesito para copias de seguridad diarias automáticas en gmail.com.

NOTA 2: Acabo de instalar Windows 10 Build 1803 (actualización de Spring Creators de abril de 2018 AKA Redstone 4) y la pintura de la pantalla es mucho más rápida. Ahora son solo 3 segundos en lugar de 5 segundos para mostrar la pantalla de bienvenida de Bash. El punto de referencia de la CPU está a la par con Linux ahora.

— WinEunuuchs2Unix
fuente

8

Tenga en cuenta que esto es engañoso: no distingue el rendimiento de E / S y otro rendimiento computacional. Se sabe que WSL es lento para E / S (consulte, por ejemplo, los puntos de referencia de Phoronix). Eso no dice nada acerca de si los cálculos de OP se pueden hacer igual de rápido en WSL.

— muru

66

Sinceramente, me sorprende que dibujar la pantalla de inicio no sea efectivamente instantáneo en ambos casos. Su computadora está (presumiblemente) feliz de hacer actualizaciones de pantalla mucho más complejas en unos pocos milisegundos, por ejemplo, cuando reproduce videos. Y la última vez que vi un terminal tan lento como en su primera grabación fue a principios de los 90, cuando marqué un BBS en mi módem de 2400 bps.

— Ilmari Karonen

¿Qué quieres decir con "Ubuntu en Linux"?

— Jon Bentley

3

Honestamente, este tipo de punto de referencia es completamente inútil para cualquier tipo de programa realista, como cualquier punto de referencia que esencialmente mida la velocidad de pintura de la consola. O el cuello de botella de su programa es la E / S de la consola (que es notoriamente lenta incluso en Linux con la mayoría de los emuladores de terminal), o esta no es una medida confiable de nada útil.

— Matteo Italia

2

@ WinEunuuchs2Unix Por lo que puedo ver, hay pocos cálculos. pero mucha E / S: buscar el clima desde algún lugar, leer la fecha y la hora e imprimirlo en un formato, leer la información del sistema, etc. De todos modos, ¿alguna vez has usado Abaqus? El software de simulación similar o Ansys o Simulink no están vinculados a la E / S de la pantalla al ejecutar la simulación real, a menos que fuerce la simulación a que sea así. Es perfectamente posible que estos muestren los resultados finales justos dependiendo de la simulación realizada.

— muru

7

Piénselo: en WSL su computadora está ejecutando el sistema gráfico completo de Windows (que en primer lugar es una fuente de recursos horrible) más el subsistema Ubuntu. En Ubuntu nativo solo ejecuta Ubuntu.

— JimDeadlock
fuente

1

@ JimDeadlock Realmente no creo que mate el escritorio, simplemente no lo muestra. Todas las aplicaciones gui todavía se ejecutan en segundo plano, ¿no?

— Eric Duminil

2

La GUI de Windows consume algo de memoria, pero no mucho uso de CPU cuando no hace nada. No veo por qué eso tendría un impacto significativo.

— vidarlo

1

Cambiar la consola a un VT diferente no mata ningún proceso; @EricDuminil es correcto. Puede pausar cosas que usaban el tiempo de la CPU para hacer actualizaciones gráficas, porque el servidor X sabe que ya no se muestra (y, por lo tanto, no puede perder tiempo en el procesamiento de OpenGL o lo que sea). Pero si ejecuta pstreeo ps auxw, es obvio que todos los procesos siguen vivos. (O topy presione M para ordenar por consumo de memoria).

— Peter Cordes

2

@MichaelEricOberlin: ¡Cambiar a otro VT no afecta el nivel de ejecución! Es solo que las consolas de texto todavía están disponibles en un nivel de ejecución que inicia GDM. (Y, por cierto, los niveles de ejecución son básicamente una cosa del pasado; systemdno funciona como SysV init. La parte anterior de este comentario es pretender que estabas ejecutando una distribución Linux de 5 o 10 años con una initconfiguración de la vieja escuela ). Pero sí , cerrar sesión en su sesión X y detener X11 / GDM liberará recursos, especialmente si no tiene espacio de intercambio, o si su escritorio tiene basura que se activa con frecuencia incluso cuando está "inactivo".

— Peter Cordes

1

@MichaelEricOberlin: Tu comentario es simplemente incorrecto. ¿Podría considerar eliminarlo?

— Eric Duminil

1

No sé si esto afectará su simulación en particular, pero podría:

¡WSL NO usa RAM para la memoria compartida! ¡Utiliza el disco!

Esto significa que si su simulación usa memoria compartida (piense /dev/shm), ¡puede ser lenta y / o desgastar su dispositivo de almacenamiento! Y la penalización de rendimiento proviene de varias capas:

El controlador del sistema de archivos
El controlador de almacenamiento
El medio de almacenamiento

Pero si no hace esto, entonces el rendimiento debería ser similar al de Ubuntu desnudo (suponiendo que no haya otras E / S, como han mencionado otros).

— usuario541686
fuente

realmente bueno saberlo!

— ABCDEMMM