Votre logiciel de simulation est probablement lié au processeur ou à la mémoire . Pour de telles charges de travail, on ne ferait que constater une différence significative entre l'exécution du code sur du "bare metal" ou à l'intérieur de WSL (ou de toute autre couche de compatibilité ou machine virtuelle qui utilise l'exécution native), car dans les deux cas, le système d'exploitation est principalement en attente tandis que le code de simulation s'exécute directement sur le CPU.
Cependant, il est également possible que votre simulation soit au moins partiellement liée aux E / S, et c'est là que des différences peuvent apparaître. Apparemment, WSL (actuellement) possède une couche d'interface de système de fichiers assez lente qui peut ralentir considérablement les E / S de disque. * Cela dit, alors que les E / S de disque peuvent être le principal goulot d'étranglement pour de nombreux types de tâches de traitement de données en masse, une "simulation" ne devrait généralement pas passer la majorité de son temps à lire et à écrire des fichiers. Si c'est le cas, vous pouvez envisager de l'exécuter à partir d'un disque RAM (par exemple tmpfs sur Linux ** natif) pour éviter un accès inutile au disque physique.
Dans tous les cas, la seule façon d'être sûr est de tester votre simulation dans les deux environnements et de déterminer le temps d'exécution. Avant de faire cela, cependant, vous voudrez peut-être jeter un œil aux benchmarks existants, comme ce benchmark de performance WSL vs Docker vs VirtualBox vs Linux natif par Phoronix de février 2018 , et examiner les résultats de tous les tests qui mettent l'accent sur les mêmes composants du système comme le fait votre simulation.
(FWIW, les résultats de Phoronix semblent correspondre principalement aux principes généraux que j'ai décrits ci-dessus, bien qu'il y ait quelques bizarreries notables comme VirtualBox surpassant apparemment Linux natif dans quelques benchmarks liés aux E / S, apparemment en raison de son disque virtuel qui ne synchronise pas toujours immédiatement les données sur le disque physique. Un problème potentiellement pertinent que je n'ai pas noté ci-dessus est que les tests de performances montrent des différences significatives dans les performances OpenMP multithread à la fois entre les différents environnements hôtes et également entre les différentes distributions Linux, même lors de l'exécution sur du matériel nu. ce n'est pas trop surprenant, car le threading et l'IPC sont gérés par le noyau. Je suppose qu'une grande partie de la différence entre les distributions peut résulter de différents paramètres de réglage du noyau d'exécution et / ou de compilation.)
*) Selon ce billet de blog MSDN de 2016, il y a en fait deux composants d'interface du système de fichiers dans WSL: VolFs, qui émule étroitement la sémantique du système de fichiers Linux natif sur NTFS et est utilisé pour monter par exemple /
et /home
, et DrvFs, qui fournit principalement une sémantique de type Windows et est utilisé pour accéder aux lecteurs Windows hôtes via /mnt/c
etc. Si votre logiciel ne nécessite pas spécifiquement des fonctionnalités natives du système de fichiers Linux comme plusieurs liens durs vers le même fichier, sa configuration pour stocker ses fichiers de données dans un dossier DrvFs peut améliorer les performances d'accès aux fichiers sur WSL.
**) Selon ce fil Reddit de mai 2017, "tmpfs est actuellement émulé en utilisant le disque" sur WSL. À moins que quelque chose n'ait changé au cours de la dernière année, cela signifie probablement que l'utilisation de tmpfs sur WSL n'apporte aucun avantage en termes de performances par rapport à l'utilisation d'un système de fichiers sur disque normal.