Executando uma simulação no Ubuntu puro vs no Ubuntu no Windows (WSL)

15

Gostaria de fazer uma pergunta sobre o teste de uma simulação grande de CAE no mesmo computador nas duas situações a seguir.

Sistema Ubuntu puro
Sistema Ubuntu no Windows 10 (WSL)

As velocidades de cálculo nos dois casos são quase as mesmas ou são diferentes?

windows windows-subsystem-for-linux benchmarks

— ABCDEMMM
fonte

4

Sem conhecer a natureza da simulação, isso é impossível de responder.

— 1377 muru

11

@muru: Não é que vaga. Uma "simulação" é presumivelmente um trabalho em segundo plano computacionalmente intensivo, o que o torna vinculado à CPU ou à memória. (A E / S de disco ou de rede também pode ser um gargalo, mas é algo que as pessoas que escrevem esses programas tendem a evitar, e algum código de simulação moderno pode até usar a GPU para computação paralela.) que testa todos esses 2 a 5 possíveis gargalos e verifica se há alguma diferença significativa entre a WSL e o Ubuntu nativo para qualquer um deles. Eu faria isso, mas não tenho o WSL (ou Windows 10) disponível.

— Ilmari Karonen

3

@IlmariKaronen "presumivelmente". Dependendo da trituração de dados, poderia ser muito intensivo em IO, mesmo que a CPU estivesse ligada. E o restante do seu comentário é uma boa razão para encerrar isso - não temos idéia de qual possível combinação de gargalos importa aqui.

— muru

11

Bem, eu postei uma resposta, pois verifica-se que benchmarks adequados já estão online . Obviamente, não posso dizer com certeza se o código de simulação específico do OP será mais lento na WSL ou não; mas, em qualquer caso, uma resposta a essa pergunta não serve para ninguém, a não ser o OP de qualquer maneira. O que posso responder, com base nos benchmarks, é que tipos de código de simulação podem ser razoavelmente esperados para ter diferenças de desempenho entre a WSL e o Linux nativo.

— Ilmari Karonen

@muru, é uma simulação CAE (Abaqus CAE).

— ABCDEMMM

18

O seu software de simulação provavelmente está ligado à CPU ou à memória . Para essas cargas de trabalho, não seria diferente ver a diferença significativa entre executar o código em "bare metal" ou dentro da WSL (ou qualquer outra camada de compatibilidade ou VM que use execução nativa), pois, em ambos os casos, o sistema operacional está apenas aguardando enquanto o código de simulação é executado diretamente na CPU.

No entanto, também é possível que sua simulação seja pelo menos parcialmente ligada à E / S e é aí que podem surgir diferenças. Aparentemente, o WSL (atualmente) possui uma camada de interface do sistema de arquivos bastante lenta que pode diminuir significativamente a E / S do disco. * Dito isso, enquanto a E / S do disco pode ser o principal gargalo para muitos tipos de tarefas de processamento de dados em massa, uma "simulação" geralmente não deve gastar a maior parte do tempo lendo e gravando arquivos. Se o seu for, considere executá-lo a partir de um disco RAM (por exemplo, tmpfs no Linux nativo **) para evitar o acesso desnecessário ao disco físico.

De qualquer forma, a única maneira de ter certeza é testar sua simulação nos ambientes e no tempo que leva para ser executado. Antes de fazer isso, no entanto, convém dar uma olhada nos benchmarks existentes, como este WSL vs. Docker vs. VirtualBox vs. Linux nativo da Phoronix, a partir de fevereiro de 2018 , e examinar os resultados para quaisquer testes que enfatizem os mesmos componentes do sistema como faz sua simulação.

(FWIW, os resultados do Phoronix parecem coincidir principalmente com os princípios gerais que descrevi acima, embora existam algumas curiosidades notáveis como o VirtualBox aparentemente superando o Linux nativo em alguns benchmarks de E / S, aparentemente devido ao seu disco virtual nem sempre sincronizar dados imediatamente Um problema potencialmente relevante que não observei acima é que os benchmarks mostram diferenças significativas no desempenho do OpenMP multiencadeado, tanto entre os diferentes ambientes host quanto entre as diferentes distribuições do Linux, mesmo quando executadas em hardware simples. isso não é muito surpreendente, já que o threading e o IPC são tratados pelo kernel. Eu acho que grande parte da diferença entre as distribuições pode se resumir a diferentes parâmetros de tempo de execução e / ou tempo de compilação do kernel.)

^{*) De acordo com esta postagem do blog do MSDN de 2016, na verdade existem dois componentes de interface do sistema de arquivos no WSL: VolFs, que emula de perto a semântica nativa do sistema de arquivos Linux sobre NTFS e é usado para montar eg /e /home, e DrvFs, que fornece semântica semelhante ao Windows e é usado para acessar as unidades host do Windows via /mnt/cetc. Se o seu software não exigir especificamente recursos nativos do sistema de arquivos Linux, como vários links físicos para o mesmo arquivo, configurá-lo para armazenar seus arquivos de dados em uma pasta DrvFs pode melhorar o desempenho do acesso a arquivos em WSL.}

^{**) De acordo com este thread do Reddit de maio de 2017, "o tmpfs está atualmente emulado usando o disco" no WSL. A menos que algo tenha mudado no ano passado, isso presumivelmente significa que o uso de tmpfs no WSL não oferece benefícios de desempenho em relação ao uso de um sistema de arquivos normal em disco.}

— Ilmari Karonen
fonte

Talvez não apenas parâmetros de ajuste, mas opções de compilador (por exemplo, -O3 -march=haswellou algo assim. Não sei o que o Clear Linux realmente usa para construir seus kernels, mas talvez o BMI2 / popcnt/ o que quer que possa fazer uma diferença mensurável no glibc e no kernel. (O kernel venceu 'benefício t da AVX, porém, porque o kernel evita registradores FPU tocar exceto em código específico como os 6 dados software-RAID5 / de correção de erros).

— Peter Cordes

12

O Ubuntu no Windows (WSL - Atualização de criadores de outono de 2017) é definitivamente mais lento que o Ubuntu "Puro" no ambiente Linux.

Por exemplo, a pintura da tela leva muito mais tempo no Windows 10 do que no Ubuntu 16.04, ou seja, você pode realmente ver o cursor se mover no Windows 10:

Demora cerca de 5 segundos para a tela inicial do WSL Bash pintar. Em comparação, são cerca de 1 1/2 segundos para a mesma tela inicial no Ubuntu 16.04:

Comparação de CPU

A primeira seção mostra o quão lenta a E / S da tela é, mas e o benchmarking da CPU?

Confira as perguntas e respostas sobre o Ubuntu: Utilitário de benchmarking de CPU para Linux , executei testes no Ubuntu 16.04 no Linux e Windows. No Linux, cerca de 24 segundos no Windows 10 versão 1709, cerca de 31 segundos. O Linux é 6 segundos mais rápido ou cerca de 25% mais rápido. No entanto, acabei de atualizar o Windows 10 para a versão 1803 (Redstone 4, também conhecida como Spring Creators April 2018 update) e levou 24 segundos, o mesmo que o Linux.

Ubuntu 16.04 no 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 no Windows 10 build 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 no Windows 10 build 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: A atualização de primavera do Windows 10 para 2018 (apelidada de Redstone 4 ) foi lançada em 9 de maio (há 4 dias) e eu a instalarei em breve para verificar as melhorias. Sem dúvida, existem muitos. Um que eu sei que me interessa é a capacidade de executarcron tarefas na inicialização. Eu preciso disso para backups diários automáticos para gmail.com.

NOTA 2: Acabei de instalar o Windows 10 Build 1803 (atualização de criadores de primavera de abril de 2018, AKA Redstone 4) e a pintura da tela é muito mais rápida. Agora são apenas 3 segundos em vez de 5 segundos para exibir a tela inicial do Bash. O benchmark da CPU está a par do Linux agora.

— WinEunuuchs2Unix
fonte

8

Observe que isso é enganoso - isso não distingue o desempenho de E / S e outro desempenho computacional. Sabe-se que a WSL é lenta para E / S (consulte, por exemplo, benchmarks do Phoronix). Isso não diz nada sobre se os cálculos do OP podem ser feitos com a mesma rapidez na WSL.

— 1300 muru

6

Estou sinceramente surpreso que desenhar a tela inicial não seja efetivamente instantâneo nos dois casos. Seu computador (presumivelmente) tem o prazer de fazer atualizações de tela muito mais complexas em alguns milissegundos, por exemplo, ao reproduzir vídeo. E a última vez que vi um terminal tão lento quanto em sua primeira gravação foi no início dos anos 90, ao discar um BBS no meu modem de 2400 bps.

— Ilmari Karonen

O que você quer dizer com "Ubuntu no Linux"?

— Jon Bentley

3

Honestamente, esse tipo de referência é completamente inútil para qualquer tipo de programa realista, como qualquer referência que mede essencialmente a velocidade de pintura do console. O gargalo do seu programa é a E / S do console (que é notoriamente lenta mesmo no Linux com a maioria dos emuladores de terminal) ou isso não é uma medida confiável de qualquer coisa útil.

— Matteo Italia

2

@ WinEunuuchs2Unix Pelo que posso ver, há pouca comparação. mas muita E / S: buscando o clima de algum lugar, lendo a data e a hora e imprimindo em um formato, lendo as informações do sistema etc. De qualquer forma, você já usou o Abaqus? Softwares de simulação como este, Ansys ou Simulink não são vinculados à E / S da tela ao executar a simulação real, a menos que você force a simulação. É perfeitamente possível que eles mostrem os resultados finais justos, dependendo da simulação feita.

— muru 13/05/19

7

Pense nisso - na WSL, seu computador está executando o sistema gráfico completo do Windows (que é um péssimo recurso em primeiro lugar) mais o subsistema Ubuntu. No Ubuntu nativo, ele está apenas executando o Ubuntu.

— JimDeadlock
fonte

11

@ JimDeadlock Eu realmente não acho que isso mata a área de trabalho, apenas não a exibe. Todo aplicativo de GUI ainda está sendo executado em segundo plano, não é?

— Eric Duminil

2

A GUI do Windows consome um pouco de memória, mas não usa muito a CPU quando não está fazendo nada. Não vejo por que isso teria algum impacto significativo?

— Vidarlo 13/05/19

11

Mudar o console para um VT diferente não mata nenhum processo; @EricDuminil está correto. Ele pode pausar coisas que estavam usando o tempo da CPU para fazer atualizações gráficas, porque o servidor X sabe que não está mais sendo exibido (e, portanto, pode não perder tempo com o processamento do OpenGL ou o que for). Mas se você executar pstreeou ps auxw, é óbvio que todos os processos ainda estão vivos. (Ou toppressione M para classificar por consumo de memória).

— Peter Cordes

2

@ MichaelEricOberlin: Mudar para outro VT não afeta o nível de execução! Só que os consoles de texto ainda estão disponíveis em um nível de execução que inicia o GDM. (E, BTW, os níveis de execução são basicamente uma coisa do passado; systemdnão funciona como o SysV init. A parte anterior deste comentário está fingindo que você estava executando uma distribuição Linux de 5 ou 10 anos com uma initconfiguração antiga .) Mas sim , sair da sua sessão X e interromper o X11 / GDM liberará recursos, especialmente se você não tiver espaço para troca, ou se a área de trabalho tiver uma porcaria que acorda com frequência mesmo quando "inativa".

— Peter Cordes

11

@ MichaelEricOberlin: Seu comentário é simplesmente errado. Você poderia excluí-lo?

— Eric Duminil

1

Não sei se isso afetará sua simulação em particular, mas pode:

O WSL NÃO usa RAM para memória compartilhada! Ele usa o disco!

Isso significa que, se a sua simulação usa memória compartilhada (pense /dev/shm), ela pode ser lenta e / ou desgastar o seu dispositivo de armazenamento! E a penalidade de desempenho vem de várias camadas:

O driver do sistema de arquivos
O driver de armazenamento
O meio de armazenamento

Mas se isso não acontecer, o desempenho deve ser semelhante ao do Ubuntu bare-metal (assumindo que não haja outra E / S, como outros já mencionaram).

— user541686
fonte

muito bom saber disso!

— ABCDEMMM