Je voudrais poser une question sur le test d’une grande CAE simulation sur le même ordinateur dans les deux situations suivantes.
Les vitesses de calcul dans les deux cas sont-elles presque identiques ou sont-elles différentes?
Votre logiciel de simulation est probablement lié au processeur ou à la mémoire . Pour de telles charges de travail, on ne verrait pas de différence significative entre l'exécution du code sur "bare metal" ou à l'intérieur de WSL (ou tout autre couche de compatibilité ou VM qui utilise une exécution native ), car dans les deux cas, le système d’exploitation reste en veille, le code de simulation s’exécutant directement sur la CPU.
Cependant, il est également possible que votre simulation soit liée au moins partiellement aux entrées/sorties, et c'est là que des différences peuvent apparaître. Apparemment, WSL (actuellement) possède une couche d'interface système de fichiers plutôt lente qui peut ralentir considérablement les E/S de disque. * Cela dit, bien que les E/S de disque puissent constituer le principal goulot d'étranglement pour de nombreux types de tâches de traitement de données en bloc, une "simulation" normalement ne devrait pas passer la majorité de son temps à lire et à écrire des fichiers. Si le vôtre l’est, 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, le seul moyen de vous en assurer est de tester votre simulation dans les deux environnements et de déterminer le temps nécessaire à son exécution. Avant de faire cela, cependant, vous voudrez peut-être jeter un coup d’œil sur les tests existants, comme ceci WSL vs Docker vs VirtualBox vs test de performance natif pour Linux par Phoronix à partir de février 2018 , et examiner les résultats les tests qui sollicitent les mêmes composants du système que votre simulation.
(FWIW, les résultats de Phoronix semblent correspondre pour l’essentiel aux principes généraux que j’ai exposés ci-dessus, bien qu’il existe quelques particularités notables comme VirtualBox qui surperforme apparemment Linux natif dans quelques tests de performances liés à des entrées/sorties, apparemment à cause de son disque virtuel ne synchronisant pas toujours immédiatement les données Un problème potentiellement important que je n'ai pas remarqué plus haut est que les tests montrent des différences significatives dans les performances OpenMP multithreads à la fois entre les différents environnements hôte et entre différentes distributions Linux même avec du matériel nu. Ce n’est pas surprenant, vu que thread et IPC sont gérés par le noyau. Je suppose que la différence entre les deux Les distributions peuvent dépendre de différents paramètres d’ajustement du noyau lors de la compilation et de la compilation.)
*) Selon cet article de blog MSDN à partir de 2016, WSL compte deux composants d'interface de système de fichiers: VolFs, qui émule de près la sémantique native du système de fichiers Linux sur NTFS et est utilisé pour monter, par exemple. /
et /home
, et DrvFs, qui fournit principalement une sémantique semblable à Windows et sont utilisés pour accéder aux disques de l'hôte Windows via /mnt/c
, etc. Si votre logiciel n'exige pas de fonctionnalités de système de fichiers Linux natives, telles que plusieurs liens physiques vers le même fichier, pour le configurer. 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 de discussion Reddit à partir de mai 2017, "tmpfs est actuellement émulé à l'aide d'un disque" dans WSL. À moins que quelque chose 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 normal sur disque.
Ubuntu sous Windows (WSL - Mise à jour des créateurs d'automne 2017) est nettement plus lent que Ubuntu "pur" dans un environnement Linux.
Par exemple, la peinture d'écran prend beaucoup plus de temps sous Windows 10 que sous Ubuntu 16.04, autrement dit, vous pouvez voir le curseur bouger dans Windows 10:
Il faut environ 5 secondes à l'écran de démarrage WSL Bash pour Paint. Par comparaison, il faut environ 1 1/2 seconde pour le même écran de démarrage dans Ubuntu 16.04:
La première section montre la lenteur des E/S à l'écran, mais qu'en est-il de l'analyse comparative du processeur?
À partir de cette question à Ubuntu: tilitaire d'analyse comparative du processeur pour Linux , j'ai effectué des tests sur Ubuntu 16.04 sous Linux et Windows. Sous Linux, environ 24 secondes sous Windows 10 version 1709, environ 31 secondes. Linux est 6 secondes plus rapide ou environ 25% plus rapide. Cependant, je viens de mettre à niveau Windows 10 vers la version 1803 (mise à jour de Redstone 4, Spring Creators, avril 2018) et cela a pris 24 secondes, ce qui est identique à 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
$ 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
$ 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
REMARQUE: mise à jour printanière de Windows 10 pour 2018 (doublée Redstone 4 ) est arrivée le 9 mai (il y a 4 jours) et je l'installerai bientôt pour vérifier les améliorations. Sans doute il y en a beaucoup. Je sais que l’un des domaines qui m’intéresse est la possibilité d’exécuter des travaux cron
au démarrage. J'ai besoin de ça pour les sauvegardes quotidiennes automatiques sur gmail.com.
NOTE 2: Je viens d'installer Windows 10 Build 1803 (mise à jour de AKA Redstone 4 en avril 2018) et la peinture d'écran est beaucoup plus rapide. Il ne reste plus que 3 secondes au lieu de 5 secondes pour afficher l'écran de démarrage Bash. Le benchmark du processeur est à égalité avec Linux maintenant.
Pensez-y. Dans WSL, votre ordinateur exécute le système graphique complet de Windows (qui est une ressource épouvantable au départ) et le sous-système Ubuntu. Dans Ubuntu natif, il n’exécute que Ubuntu.
Je ne sais pas si cela affectera votre simulation en particulier, mais cela pourrait:
Cela signifie que si votre simulation utilise la mémoire partagée (pensez à /dev/shm
), elle risque d'être lente et/ou d'user votre périphérique de stockage! Et la pénalité de performance provient de plusieurs couches:
Le pilote du système de fichiers
Le pilote de stockage
Le support de stockage
Mais si cela ne se produit pas, les performances devraient être similaires à celles d’Ubuntu "nu-metal" (en supposant qu’aucune autre E/S, comme d’autres l’ont déjà mentionné).