O seu software de simulação provavelmente está vinculado à CPU ou limite de memória . Para tais cargas de trabalho, não seria necessário ver qualquer diferença significativa entre a execução do código em "bare metal" ou dentro da WSL (ou qualquer outra compatibilidade camada ou VM que usa a execução nativa), já que em ambos os casos o sistema operacional está praticamente parado enquanto o código da simulação é executado diretamente na CPU.
No entanto, também é possível que sua simulação seja pelo menos parcialmente limitada por E / S, e é aí que as diferenças podem surgir. Aparentemente, a WSL (atualmente) tem uma camada de interface de sistema de arquivos bastante lenta que pode diminuir significativamente a E / S do disco. * Dito isso, embora a E / S de disco possa 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 escrevendo arquivos. Se o seu for, você pode considerar a possibilidade de executá-lo a partir de um disco RAM (por exemplo, tmpfs no Linux nativo **) para evitar o acesso desnecessário ao disco físico.
Em qualquer caso, a única maneira de ter certeza é testar sua simulação nos dois ambientes e o tempo de execução. Antes de fazer isso, no entanto, você pode querer dar uma olhada nos benchmarks existentes, como este WSL vs. Docker vs. VirtualBox vs. benchmark de desempenho nativo do Linux pela Phoronix a partir de fevereiro de 2018 , e examine os resultados para quaisquer testes que enfatizem os mesmos componentes do sistema que a sua simulação.
(FWIW, os resultados do Phoronix parecem coincidir com os princípios gerais que descrevi acima, embora existam algumas esquisitices notáveis como o VirtualBox aparentemente superando o Linux nativo em alguns benchmarks de I / O, aparentemente devido ao seu disco virtual nem sempre Sincronizando dados imediatamente com o disco físico.Um problema potencialmente relevante que eu não observei acima é que os benchmarks mostram diferenças significativas no desempenho do OpenMP multiencadeado tanto entre os diferentes ambientes host como também entre diferentes distribuições Linux mesmo quando rodando em hardware nu.Em retrospectiva, isso não é muito surpreendente, já que o threading e o IPC são manipulados pelo kernel.Eu acho que grande parte da diferença entre as distribuições pode vir a um kernel de tempo de execução e / ou compilação diferente parâmetros de ajuste.)
*) De acordo com este post do blog do MSDN a partir de 2016, existem, na verdade, dois componentes de interface de sistema de arquivos no WSL: VolFs, que emula de perto a semântica do sistema de arquivos Linux nativo sobre o NTFS e é usado para montar, por exemplo / e /home e DrvFs, que fornece basicamente semântica semelhante ao Windows e é usado para acessar as unidades do Windows host via /mnt/c etc. Se o seu software não requer especificamente recursos nativos do sistema de arquivos Linux, como vários links físicos para o mesmo arquivo, configurando-o para armazenar seus arquivos de dados em uma pasta DrvFs pode melhorar o desempenho de acesso a arquivos no WSL.
**) De acordo com este tópico do Reddit de maio de 2017, " O tmpfs é atualmente emulado usando o disco "no WSL. A menos que algo tenha mudado ao longo do último ano, isso significa que usar o tmpfs no WSL não oferece nenhum benefício em relação ao uso de um sistema de arquivos normal em disco.
